Software development -- Engineering or Art
“Both views of the world resonate with me and I can clearly see how they are both right. I have spent sometime recently thinking about this in more depth, and I think I know how to rationalize their views, but I’d like to get your take… Is software development a discipline of engineering or a discipline of arts?” - from Brad Abrams' blog on Tuesday
Software development should be construction work. Technical design should be more like architecture, which contains both art and engineering. The fuzziness is due to the fact that I.T. roles too often overlap, and most people in the industry have done design and construction at once (or still do) under the illusion that a) the roles belong as one, and b) skill at one implies skill at the other. To understand where all this is headed, we can learn from the way builders build buildings, starting with the architect.
Architectural firms provide a few roles that map to I.T. The firm acts as Business Analyst with the client to figure out what to build and for how much, Architect and Technical Designer during the design phase, and then Project Manager to keep the general contractor on track. The physical construction is handled by another company -- the general contractor. The trend in the software industry is towards this separation of roles, but we're in a different state today.
Software construction today is a little like building a medieval cathedral. At least that's the way the smart companies do it, given the mix in the talent pool. I'll explain. Once upon a time you had the unskilled labourers (“grunts”), plus a large number of highly skilled and specialized artisans. The grunts were hired to flatten the ground, put up some basic structure and do the heavy lifting, but knowledgeable, skilled craftsmen -- artists really -- did the bulk of the work (or at least that's how I remember the PBS special).
And each was specialized. One knew how to make perfectly domed or vaulted ceilings, another spent a few years carving wood trim, another would be known for stained glass or gargoyles or whatever. It was these artisans who spent from months to years making the cathedral function in a soaring, spiritual, "holy crap that's beautiful" kinda way. They were the ones who applied both creativity and centuries of accumulated knowledge to their appointed task.
The I.T. talent pool is sharing and accumulating knowledge at a pace on WebTime. Roles are being stratified into ever more concise specialties. Artisans are prevalent, and in demand. Maybe my perception is skewed, but I don't know of anyone who practised design patterns or refactoring ten years ago. Development in those days was like building a clock with a hammer and some nails. Today we've got this awesome pool of educated talent. There might still be a vast force of grunts out there slapping together sandboxes and tie racks, but those aren't the folks I meet at user group meetings, and I bet they don't read Brad's blog either. I really believe we're living in the days of cathedrals. And there's a giant one just over there. . .
The .NET Framework is an abstract, modular, old-school cathedral. And it's a cathedral that acts as a tool to build other cathedrals. All the pieces are there, and even most grunts can shape or colour them for most any application or function. Put the tool in the hands of a competent architectural firm, and you can use those pieces to build your own Library of Congress or Taj Ma Hall of Pancakes (whatever strikes your fancy), faster than you can say “Amish barn-raising.”
Back to Brad's question. Yes, therefore software development is art. Today.
But our newfangled abstract power tools will dilute the value of the software artisan, and not everyone can be the master builder or architectural engineer. Remember when the word “webmaster” carried connotations of arcane knowledge? The same will happen to “software developer.” Let's have some fun with it while it lasts. Be an artisan. That's enough mixed thoughts and metaphors for one blog, until the next shipment.