And the fact that projects are rarely "done", you just stop working on them at some point (hopefully a "good enough" point)
Mismatches include near total lack of reusability/composability, solo vs group effort, etc.
All analogies are flawed, some are useful.
Stories can evolve, plots get interwoven and some cut, its never finished until publishing maybe, and even then there can always be sequels.
Anyway, we could do this all day.
IoT will change all of that ;)
* (0.1) - Can sit on chair
* (0.1.1) - Chair holds person who sits on it
* (0.2) - Can detect person sits in chair
* (0.2.1-hotfix) - Reject fake 'sits'
* (0.3) - Determine weight of person sitting on chair!
> Not every concept needs an analogy to be understood if we
> can explain things using correct and simple language.
The analogy makes no sense. There's so many fundamental differences between physical objects and software that my eyes glazed over as soon as he started the carpenter rant.
Edit: That brings me back to the article. "Finishing software" just means we should act more like authors. Very hard to achieve when you think of the differences above.
Apparently not, but the analogy is completely valid for what is being compared. A chair is designed for a specific purpose, so imagine if it kept changing in ways which were out of your control and either unrelated to, or made it less fit for, that purpose.
The problem I have is with how the article is using the term 'finished' to mean 'functionally complete', which is causing unnecessary confusion. Porting to new platforms and fixing security issues should not alter how functionally complete an app is, only address problems which either interfere with that purpose, or with the purpose of other apps running on the same system.
Even then, the article still isn't about functional completeness, but feature creep, and perhaps in the process the dangers of not using the right words for what you mean.