“Build” as metaphor for software development

I think there are parallels between software engineering and say, fine furniture building.  There is the relentless aesthetic of quality, the sense of craftsmanship versus hack, and often (given a taste for things of this nature) a sense of the intrinsic beauty of the finished product.

The place that this metaphor begins to break down though is that while a fine mahogany table might need lemon oil every so often, software often requires extensive modification and maintenance on a routine basis.  We have a language for this, the versioning system that is so often applied to software – “Alpha” “Beta” or “Version 1″, “release candidate” and “release”…etc.

To the extent that Frank LLoyd Wright constantly added additions and modified his own property (Taleisin West was nearly burnt down and completely rebuilt) there are parallels to fine traditional craftsmanship.  However, particularly with respect to web applications, there are few other industries where the product, requiring craftsmanship, aesthetic and creativity, also requires this level of constant modification.

Now, there are survival strategies for dealing with this stuff.  The ‘Head First’ series title on Design Patterns reinforces the idea that software should be open for extension, but closed for modification. I can tell you from personal experience that there are few things (again, if you have a taste for such things) more fun than constructing a program from scratch.  There are few things less fun than having to figure out how 3000 or 30,000 or 300,000 lines of dubiously written subroutines is put together, and hack in some modifications.

It’s often a house of cards (or Jenga) problem.  Someone once said that the number of bugs in any software system is constant.  By fixing one problem you inevitably cause some other unforeseen issue.  Again, even if it’s just a matter of adding another run-mode to an existing web application, this is far preferable to endlessly modifying some existing structure.

This begs the question though: When do you throw out a system entirely and start from scratch with a new version?   I think that the answer to this is that if there is time and there are resources, whenever possible.  What is needed though are microscopic techniques that constitute survival strategies for existing in this world of changing client demands and evolving software ecosystems.

I’m about to embark on a journey of Engineering Discovery in the form of a distance learning Software Engineering program.  I have many doubts about this path, ranging from a sense of loss over a carreer I could of had in design or graphics, to a sense of doubt about whether the curriculum of a software engineering masters, as different from a MS in computer science, suits my particular talents and goals.  All that being said however, I am looking forward in the extreme to learning about processes and techniques like open for extension and closed for modification that will make what decidedly tenuous coding ability I do have go even further.