Comment by ebiester

This feels like someone who hasn't been in the industry long enough to know what it is like to try and design software before implementing it with groups larger than 3, and yearns for problems that aren't as complex as the ones they are dealing with.

It is easy to build "home cooked" (by his definition) software when you are building for a small number of people by a small number of people. Old Visual Basic programs built for a single version of Linux will do just fine - and that will work well for some use cases. But if you are building software that has to work on thousands to millions of machines, and fulfill their needs, you will need to build a factory to build that software.

The factory, in this case, is the infrastructure necessary to turn the R&D (you and me) into the repeatable product (that is, your app.) The factories need a lot of maintenance. If nobody is buying your product, you need to change the factory to produce outputs that people are buying. If people have bought your product (let's say... on subscription) then you need to keep the factory maintained well enough to produce the product that people are happy to buy.

Some things will be like tarsnap and change relatively little. That's great. A small shop will need less maintenance. A bigger shop that is a factory for more users with wider needs will need more complicated products and that will mean more maintenance.

But yes, if you don't need to have a return on investment, you don't need to react to customers' needs and therefore you can build a spec first and let it change little. (Or, you build something as niche and as good as Tarsnap!)