There is a whole class of rhetorically attractive analogies comparing programming to the building of physical things like furniture, bridges, and buildings. They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs. Modification of software requires no physical resources and can be executed at scale (e.g. package managers), while modifying the design of a chair once it has shipped is impractical. Software errors can certainly be consequential, but I'd much rather encounter a bug in a messaging queue than a defect in the chair I'm sitting on or the bridge I'm driving over.
> They usually overlook that software requirements vary greatly and can be quite complex, while the physical requirements of a chair are not going to vary much across chair designs.
I feel as though that's somewhat addressed in the essay:
Yes, I hear you claiming that your project is special and
cannot be made functionally complete because, you know,
circumstances X, Y and Z.
And here's the trick: If it can't be made functionally
complete it's too big. You've tried to bite off a piece
that's bigger than you can swallow. Just get back to the
drawing board and split off a piece that can be made
functionally complete. And that's the component you want
to implement.
Software engineering is an offshoot of systems engineering, which is often described as "managing complexity". I don't think it's at all unreasonable for people to look at the methodologies actual systems engineers use and learn from them. One of those things is decomposition of tasks, what this article is about. If you're making a message queue system, divide it into subsystems that are each more feasible. Your over-the-wire data format protocol is one thing (asn.1, protobufs, etc.), your concurrency library and patterns in your systems are another (go's channels, erlang's processes, libmill from the article), your database is another. Once you have your system decomposed in this fashion you can do each part, and actually finish them, and assemble your complete system by combining them.
Once they're small enough the Unix philosophy applies. Write components that do one thing and do it well, and design them in a way to communicate with each other.
> If it can't be made functionally complete it's too big.
Too big for whom? Most people on HN aren't building systems software or embedded software with a strictly-defined purpose; they're building an app business or a service business, where the "purpose" is "to make money" and adding additional features or "checkboxes" are how you attract more customers to make that money.
A program can be done. A product usually can't be, as long as its authors want to continue to rely on it to put food on the table.
I think the problem with those analogies is much simpler and more fundamental - they assume writing software is the "building" part. It's not. Construction is what compilers do for us. What we do is design. Architecture, if you must. And we can release a new version of a software every day instead of every year like other industries, because compilers do their work fast and effectively for free.
I think the article does address that to some degree. My interpretation is that if your requirements change so much and are so complex that you are not able to complete the solutions, then you should step back from coding and work more on the requirements.
Of course that also means slowing down, and obviously that won't do in silicon valley. Gotta go fast, even if you are running around like headless chicken.
If you're designing for yourself, sure, work on the requirements.
If you're designing for the marketplace, the market decides the requirements, and expecting everyone to fall in line behind one thing is a mugg's game.
> They usually overlook that software requirements vary greatly and can be quite complex
Or change after it's built. "Oh yeah, I guess we'll also need a floor to set our chair on. And perhaps a foundation for that floor." Later: "I know I said I wanted a chair, but what we really wanted was a glider."
