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!)

> Fast Food > Here, we develop in "agile" sprints. Working software is developed at the fastest pace possible, and all bugs are to be fixed later.

> Home Cooked > Here, things are slower, more thoughtful. More waterfall-y.

While Sprints is a term that sounds like fastest pace possible, that is not what the term means; and a key part about waterfall vs agile is that waterfall IS NOT more thoughtful, but all planned up front.

Both methodologies can create bugs, or deliver features faster than scale can be thought of and deliver features faster than can be tested.

If we remove the quotes from "agile" we actually get slower and thoughtful. A key part of that is measuring (training, interviewing, analyzing). An agile process should build a feature, release that feature, interview users, analyze system behavior, iterate by improving user's goal, adding appropriate scale, iterating by removing unexpected errors or behavior.

This is often how a functional safety project works - specification is everything, no point writing any code until you know exactly what you plan to build.

Due to traceability requirements it becomes a very waterfall approach.

However one way of improving methodology and outcomes is an executable specification that can be converted to code and documenting at the very last minute, meaning you can be specifying right up until you need to deploy.

Executable specification concept comes from IEC 61499.