[jaimebuelta]

I see some of this, from the point of view that it's going to be cheaper to create bespoke solutions for problems. And perhaps a "neoSaaS" company is one that, from a very bare bones idea, can create your own implementation.

But, at the same time, there are two issues:

- Companies can be really complex. The "create a system and parametrise it" idea has been done before, and those parametrisation processes are pretty intensive and expensive. And the resulting project is not always to be guaranteed to be correct. Software development is a discovery process. The expensive part is way more in the discovery than in the writing the code.

- The best software around is the one that's opinionated. It doesn't fit all the use cases, but it presents you a way to operate that's consistent and forces you to think and operate in certain way. It guides you how to work and, once going downstream, they are a joy to work with. This requires a consistent product view and enforcing, knowing when to say "no" and what use cases not to cover, as they'll be detrimental from the experience. It's very difficult to create software like that, and trying to fit your use case I'll guarantee it won't happen.

These two things tension any creation of software, and I don't think they'll go away just because we have a magical tool that can code fast.

[tikhonj]

The best software around is Emacs. Does that count as "opinionated" in your view?

In some ways it is—Emacs does a lot of things its own way, completely unbothered by mainstream conventions—but, at the same time, it's also totally malleable in the sense of this article. What makes Emacs great is a consistent and coherent conceptual foundation coupled with remarkably flexible code, letting you adjust Emacs to your needs rather than adjusting your needs to Emacs.

Or maybe the best software around is situated software. Software that's built by and for a specific set of people in a specific social context. Situated software is qualitatively different from product software, and it works so well because, again, it gives its users real agency and control. Instead of trying to create software that knows better than its users, we can create software that supports its users in whatever ways works for me. The result is still opinionated, but it's opinionated in a categorically different way from what you're describing.

So perhaps the best mainstream software is Excel.

And, while I don't think they're there now, it seems like LLMs are likely to be the foundation for the next Excel.

[skydhash]

You can either go with simple primitives and a way to combine them (emacs, excel, unix) or simple program that just works (notepad, sumatra,…). Anything else is going to be restrictive in one way or another.

[godelski]

As a vim user I agree with all this. Same is true about why I am terminally terminal. I'm able to adapt the tools to me so that I may get the most use out of them. Sane defaults are great, but there are no settings which are universal. The only solution to this is to let people adjust as needed.

[osigurdson]

I think the article presents a bit of an odd premise - I can make a mini app in ChatGPT today so by 2035 I can create an entire suite of software needed for a given business. What is the requisite change between what I can do now and in 2035? Presumably it is AGI.

OK, so we are in a digital super intelligence world in 2035. The HR department can now just have a conversation with a chatbot and create software to make them more productive. No more configuring SAP widgets or whatever they do today. The chatbot will be like "hey bro, the process that you want to automate doesn't make any sense: here is a better way. And, by the way, I'm terminating your entire department. I'll take care of it from now on". I mean, get real, in a post DGI world there will be exactly zero office jobs and no SaaS software at all.

[ozim]

Odd premise is that AGI will have infinite bandwidth to deal with petty stuff like taking over menial stuff of HR departments.

Current AI barely keeps up with generating funny images people ask from it :)

[glitchc]

It doesn't need to be AGI to build complex software. A human software developer can build a complex software system and perform other complex tasks with the same body (play an instrument, fly an aircraft, etc.). Doing all of that with the same resources is what AGI is needed for. Just software, well I'm sure an LLM can eventually become an expert just like it learnt how to play Go.

[ethbr1]

> The best software around is the one that's opinionated.

This. And it isn't going to change.

The post avoids trying to answer "Why are opinionated tools popular and effective?"

The answer is that a standardized process that they encourage is often more efficient than whatever bullshit {random company} came up with in-house.

Malleable software needs to produce two equivalently good outcomes to beat opinionated:

1. Improve the underlying process at the customer's business (in terms of effectiveness)

2. Avoid a customization maintenance burden

The seductiveness of "just for you" bespoke solutions is they avoid (1) by telling the customer what they want to hear: you're so brilliant, your process is actually better, our product is a custom fit for your exact process, etc. That's bullshit -- a lot of customer processes are half-baked dumpster fires, and their companies would be better served by following standards.

To (2), I am incredibly skeptical on the long-term tech debt that malleable solutions will impose. What happens when there's a bug in the version only you use? Is that going to be the vendor's priority? Oh, you're supposed to fix it yourself? Congrats... we've just added a requirement that these tools are capable of making random mid-level in-house practitioners as competent as focused dev teams. That's a tall order.

Exhibit A that I'd want a follow-up post to address: SAP.

The above are the reason they realized they were trending in the wrong direction and have been dragging their customer base back to Clean Core.

Walk me through how malleable software would work better for SAP as a product, and I'll begin to believe...

[ch4s3]

Highly customizable configuration causes all kinds of problems in healthcare, and EHR customizations have actually killed people.

[BinaryIgor]

100%; customization maintenance burden is underrated - it simply costs a lot of time and energy to customize things; often there are better uses of this time, especially in the business context

[tablet]

Your arguments are totally valid, niche tools will be alive and well. I think my take is that even in niche tools we will see a lot of generalization and more flexible niche tools will eventually win.

[crote]

The problem is that software can be too flexible. A great example is companies ending up using Excel as a load-bearing database, relying on a bunch of incomprehensible macros to execute critical business logic.

Sure, it's flexible, but are they really better off than a competitor using properly-engineered one-off software? In the end, is there really a difference between software development and flexible-tool-configuration?

[godelski]

  > Companies can be really complex

I think this is a great argument for flexible code, though it was unclear to me that the author of that post was talking about that.

  > The best software around is the one that's opinionated.

I think I might be on the same page as you but I would say that the best software is written to be an environment more than a specific tool. You're absolutely right that you can't solve all problems.

tikhonj jokingly suggests emacs but even as a vim user I fully agree. Like they say, the beauty of it is that the complexity draws from simpler foundations. It is written as an environment rather than just as a text editor. Being written that way lets it adapt to many different situations and is what has kept both vim and emacs alive and popular after all these years. There's a constant in software development: requirements change with time. The point of writing an environment is that you're able to adapt to these changes. So any time you write a tool that tool is built out of that environment. Anything short of that means the tool won't be able to adapt as time marches on.

I definitely agree that writing software like this is hard but I'm not sure if it is harder. It takes more work up front but I'd argue it takes less work in the long run. It's just that in the long run many efforts are distributed across different people and time. But hey, good flexible code also tends to be much easier to read and that's big short term benefit to anyone coming into a mature project.