Hacker News Reader

Comment by netcraft | Hacker News Reader

Am I the only one that really hates the carpenter analogy? As someone who does woodworking on the side of my programming, there's a million reasons why it's a terrible way to think about software development. The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair. Someone else isn't going to have to come along later to maintain the chair and have to be knowledgeable about the specific tools that the chair was built with.

View on HN

(Oil) Painting is a better analogy in some ways, as each project is unique, may have evolving requirements, rework, etc.

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.

I think creative writing can also be a good analogy, for the reasons you state and also it seems closer to me since we are authors of the code we write.

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.

>The chair doesn't have supported platforms, new security issues, or the need to be updated so that people keep buying the same chair.

IoT will change all of that ;)

Chair Change Log

  * (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!
  ...

Taking this to the next level: I come across people all the time that put tremendous effort into building similes for... everything. Not every concept needs an analogy to be understood if we can explain things using correct and simple language.

Analogizing computing actions has become something of a trope. Doing so poorly has become a running gag.

    > Not every concept needs an analogy to be understood if we
    > can explain things using correct and simple language.

That's a pretty big linguistic 'if', actually... how do you come to understand the 'correct and simple language' in the first place?

https://xkcd.com/895/

I think something like an airplane is a much better analogy, as it is a complex system in a constant state of flux. It requires constant maintenance and has to comply with ever-changing FAA rules and regulations. It has to adapt to changing routes and distances -- it might be retrofitted to hold more fuel, or redesigned to burn less. During its lifetime, it will undergo several cabin reconfigurations, and will likely be completely rebranded more than once as it changes ownership. It will live through various versions of seat-back cell phones, overhead entertainment systems, seat-back entertainment systems, WiFi, foot rests, tray tables, and power outlets. And after decades of constant changes, it will be forcibly retired. Like software, it won't be retired because it no longer works -- it will just be EOLed because it's old, and something newer and shinier has come along.

And airplane building is one of the more relatable pastimes.

Building model airplanes and drones is certainly popular.

Also, there's no versioning. It's not possible for anyone to create a copy of a chair at any point in its history, virtually for free.

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.

Carpenter analogy is as bad as the "book author" analogy. You write a book and let it go. Nothing to support, all updates are to be paid by customers in a new release.

"Book author" is at least closer to the truth. There are editions and old copies floating out there, it's hard to estimate completion dates, and authors have many of the same copyright problems. The difference is that software must live in a dynamic and shifting 'house' where everything gets rearranged by vendors, probed for weaknesses by attackers, and new features are constantly demanded by the users. Solutions to all of this are tacked on as an endless stream of appendices. Throw in patents for extra insanity. Both analogies strain to fit this reality.

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.

Some books do have versions (textbooks et al), some books are out-of-date as soon as they are published (statistics, science). Many would benefit from a reduction in lines and becoming more concise. Some are a jumbled mess that's basically useless, but nobody wants to update them.

The analogy is perfectly valid for the point he's making. You seem to be confused about what the author is saying. "Finish your stuff" does not mean "Never Improve". Security issues or additional features have nothing to do with finishing a project.

> Am I the only one that really hates the carpenter analogy?

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.

Don't forget that a programmer's work is not really like making three of the same chair either. Maybe if every single thing the carpenter made was a highly customized bespoke piece.

Reply on news.ycombinator.com