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