Software is a craft (except when it's not)

The first time I saw in detail the way a fully automatic weapon worked - using the power generated by the energy of the last round to expel the spent cartridge, re-cock the hammer and fire off another round - I was absolutely enthralled. It seemed like such an amazing combination of engineering and ingenuity that the idea that someone could "invent" something like that was incredible bordering on magical.

The truth of course is that no one person did invent everything that went into creating an automatic weapon. Mankind's need to kill things as efficiently as possible worked over time as incredibly strong market force pushing invention and innovation forward in the field. The reason that a fully automatic weapon seemed so amazing to me is that it most likely incorporated a couple dozen or more "Aha!" moments by the greatest thinkers in the field, combined with a significant amount of engineering and trial and error to get everything to work just so (and most likely more than a couple of exploded barrels). But the fact of the matter is that no amount of rote engineering would get you there. You need individuals with the right amount of knowledge and experience applying themselves to difficult problems to get innovate solutions that advance the field.

Because of the term "Software Engineering" - many people often assume that software development is simply the application of a set of principles and code patterns to a problem to come up with a working solution, like doing the calculations to build a road. In a nutshell, a common belief is that the smart, higher paid software architects generate some UML diagrams and then pass those off to the code monkeys to bash their fingers against the keyboard and output the necessary code. Throw in some unit and integration testing at the end and there you have it - freshly engineered software.

I'd love to say that belief and method of operating is a lie, but it's not. It's definitely possible to develop software this way and lots of company's do it. Lots of them also fail horribly   There is a reason that despite the proliferation of code generation tools and the buzz about off-shoring there is a still a very strong market for us code monkeys.

As it turns out - implementation matters, and it can matter a lot. In cases where software is going to grow, change hands and live a life of it's own after the first deployment there are significant benefits to having well written code: it's easier to understand what's happening, it's easier to change, it's easier not to completely bork some other system down the line. Something designed by the world's greatest "Software Architect" , providing UML diagrams that look like works of art, can still quite easily end up being a dud when it's implemented.

Two carpenters each building a cabinet based on the same design can end up with products of widely varying quality. While at the most basic level (sure, they both hold dishes), it's quite possible one cabinet might feel like a rock-solid heirloom piece of furniture and one that seems like it might be ready to fly apart from a cross-breeze.

Anyone who's been in the software industry for a couple years has most likely seen the same thing. One piece of custom software in the company is rock solid, it's easy to add bits to and take parts away from without worrying about the whole thing falling to pieces. Other custom software is less stable, however, and programmers try to whisper magical incantations over it in the hope that the two line change they just made won't end up frying the mainframe.

To cast a sad aspersion against the software industry - I'd bet that in down times good programmers are more likely to get laid off than bad ones simply because the bad ones have such left such a destructive wake of spaghetti code behind them that no one but them knows what to do with it. Think about that - the worse you are the better your job security. What other industry has that depressing feature?

To go back to the cabinets from a few of paragraphs previous - the reason we call finish carpentry a craft and carpenters craftsmen is because the good ones, those that have the knowledge, experience and commitment to do good work do it a heck of a lot better than those who don't. Software developers, at least those who live, eat and breathe software development are the same - by some accounts well over an order of magnitude better than their less skillful and engaged peers.

Of course on the flip side, you don't always need a craftsman - if you run a cheap chair factory the last thing you want is someone who cares too much about what's coming off of the assembly line.

The software your company is developing might be the same thing, and it might just not be worth spending the money to do it right. A couple of off-shore programmers fed with a few pages of UML diagrams might do just the trick, and that's fine. Just like IKEA is making buckets of money selling cabinets that aren't heirlooms, your company can probably do the same with some barely passable software and save a few bucks. A word of warning though - when that project is months behind schedule and looks like it might not get done because things that worked last week are no longer working, that savings might not look quite as good.

The temptation from the MBA set is to believe that all it takes is itheir great idea and a quick-and-dirty implementation by the lowest bidder and the $$$ will start rolling in. The reality is that no one gets it right the first time, and if, when it's time to implement all those small tweaks that take the great idea and turn it into a great product, your codebase is falling apart - the value of having paid for or not having paid for a solid implementation will be pretty clear.