Re: Programming is not a craft

Al Chou <hotfusionman-/[email protected]> Thu, 13 Jan 2011 10:27:47 -0800 (PST)
Newsgroups gmane.comp.programming.language-of-the-year
Message-ID <[email protected]>
I confess I haven't read Dan's article nor am I likely to have time to today, 
but the remarks in this thread have been sparking thoughts similar to Robert's: 
 bad code (or work of any kind) may be acceptable -- even sufficiently so -- in 
the short run.  But in many cases the length of time during which low quality is 
sufficiently good is extremely short.  In other cases (PVC plumbing around my 
house always comes to mind), it's an acceptable tradeoff for speed (those pipes 
don't break frequently enough to rise above the threshold of investing in more 
durable pipe material).

Most software development whose scope is larger than a short command line script 
falls into the former category, IMO.


Al-- 
Albert Davidson Chou


Get answers to Mac questions at http://www.Mac-Mgrs.org/ .




________________________________
From: Robert Williams <[email protected]>
To: [email protected]
Sent: Thu, January 13, 2011 9:31:51 AM
Subject: Re: [pragprog] 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