Re: Programming is not a craft

Dan's article talked a lot about how code is all about delivering business
value; the code has no value in and of itself.  And that much is true - we
are not ultimately paid to code, but to deliver value - to automate a
process, move information around, etc.  But it seems naieve to me not to
notice that the ability to provide business value over the longer term is
very closely linked to the internal structure of the code (which he
dismisses as "aesthetics").

I guess if you view software as "entirely disposable" that might make sense
- if the lifespan of this app (or this contract!) is just a couple of years,
you can probably keep adding features with no concern for the internal
quality.  But if your code (or job) is of longer duration - my background
includes a decade in an IT department for a semiconductor manufacturer, and
now I'm at a product company - it matters a bit more.  He writes that we
should "focus on the outcome rather than the code or the process" but I
think those are, in most cases, very closely linked.

He also compared programming to plumbing.  I think this is a fairly ironic
comparison.  For one thing, becoming a plumber is a bit more involved than
going to your local home improvement store and purchasing the necessary
supplies.  They actually have a program by which one becomes a licensed
plumber, which includes both a lengthy apprenticeship and formal exam.  And
the plumbers I've interacted with take plumbing very seriously, and grumble
and complain about incompetent plumbers doing sloppy work.

Robert