The Software Craftsmanship Furor

I haven’t posted here for a while but with the current debate raging across the interwebs about how Software Craftsmanship is full-of-awesome\the-end-of-life-as-we-know-it\meh-for-the-whole-family with misunderstandings on all sides, I couldn’t help but put my own two cents in.

For those of you who have missed the shouting, here is a good place to start:

http://cleancoder.posterous.com/individuals-and-interactions and

http://martinfowler.com/bliki/CraftmanshipAndTheCrevasse.html

The second of these has lots of other links to people chiming in on the subject.

These are big names, make no mistake. There are very few in the enterprise software industry that don’t have a fowler book on their shelf (Enterprise Application Patterns anyone?) and anyone who pays attention to infoQ and the conferences has likely heard about the clean code and software craftsmanship movement. Let me start off by identifying which side of the fence I am sitting on in this debate:

I am a green-band wearing signatory of the Software Craftsmanship manifesto and am proud to be so.

That said, lets get to the meat of this current discussion.  I read the posts from Dan North and his supporters with alternating disappointment (when they spoke about how fearful they we might backslide) to alarm rapidly approaching on disgust (when one spoke that the very existence of the movement upset her.)

What I can’t understand is how anyone who has endured the trenches could be anything but inspired? Is it just the wording of the manifesto? Have they not watched Uncle Bob’s fantastic presentation at Q-Con perhaps? Not spoke to the adherents about why they like it?

I think in the end that it comes down to a difference of opinion; and the truth is, the world needs both of us.

I never liked agile. I wasn’t alone there but it seems a strange thing to say these days as its popularity has grown in leaps and bounds. To be clear, its not that I disliked the techniques of agile; I use many myself in my day to day job, particularly short iteration time, constant customer feedback and backlog-scheduling. These three things alone justify the existence of Agile as a philosophy and we should all be thankful.

What I disliked was the attitude of many agile practitioners; the exclusive focus on the customer’s desires above all else.

I’ll wait for the “but but but” to calm down, yes, I am aware that as members of a service industry it is our job to satisfy the client’s needs, but if you think that job is simply saying ‘yes’ all the time to whatever they say you are doing yourself and your industry a disservice. It is important to discover the underlying requirements, the real needs the client don’t know exist yet, the domain problem that needs to be solved.  It is important to not only listen to the client, but to engage with them, to challenge their ideas and conceptions, to offer your own technical advice and to utilise the report so fostered to deliver a solution that meets the customer’s needs.

These needs are many and often conflict. How many people have, in effect, been handed project where the client wants perfect work, in record speed, for very little cash?  The old saying goes Speed, Quality and Price, choose two.

These are personal pet peeves I know and I am not trying to demonise anyone in the agile movement, it is a problem that existed long before them.  Fowler in particular has very real and well reasoned worries and concerns, but I feel they might be misplaced.  You see, what Software Craftsmanship is about, as Uncle Bob points out, is about programmers being tired of being ashamed of their work.

We’ve all been there.  Deadlines loom, the client doesn’t understand why there are delays and the project manager doesn’t want to have to tell them that the latest release is going to have to slip.  Something has to give and its going to land squarely on the programmers shoulders.  Get It Done is the name of the game.

Good, strong work takes time, and time you don’t have, so you cut a few corners.  Skip a few unit tests, throw in a few small hacks to get the functionality working quickly.  It’s still fairly robust and you’ll go back and fix it after the release date.

Yeah right.  It never happens, and years later the huge application that is now in maintenance mode, where it will spend the bulk of its life, is making a bunch of programmers miserable for all the hacks and quick-fixes that were never repaired. The ‘technical debt’ as it has been called was never repaid and the interest can be crippling.

I have worked on many of these projects, and have been responsible for a few in my time too. They may be “successful” projects, that made a crapload of money and delivered on time, but their legacy is unhappiness.  The coders are unhappy, those that take pride in their work, because they know how bad much of it is.  The support programmers are unhappy, they have the maintain the mess.  The customer is unhappy; a quickly written software has far more places for bugs to hide, performs worse and has less stability.  They might be “happy” to sign off, and reasonably satisfied with the work, but they could be happier; much happier; if the work was done properly in the first place.

A few of the critics talk about “under the hood” code and how it doesn’t matter if its “beautiful”, only the functionality matters.  The client wont see if, why care?  These people seem to think that when we say “Craftsman” we mean that we want to build ourselves a sistine chapel of each and every project, complete with ornamentation and a gigantic mural.  To them, my answer is quite simple. Bookcases.

Have you have compared a custom built bookcase to a flat-pack from ikea or somewhere similar?  Which one would you trust your favorite books to?  A flatpack bookshelf serves its function, to hold books, but its shelves are held on by simple screws – or worse, just resting on tiny plastic holders.  The frame is supported only at the four corners by the screws you wrestled into place and the whole thing feels a little tottery.  Over time, the weight of the books cause the shelves to sag and eventually break away from the frame altogether.  It serves its function, but only if not too much pressure is ever put on it.

On the other hand, a custom built bookshelf has dovetailed shelves made of hardwood, with several supporting rests to prevent bowing under weight. If its made by a competent carpenter, you will be passing it on to your children.

That is the difference we are talking about. We don’t (necessarily) want to be the builders of massively complicated beautiful structures that serve no purpose but to satisfy our own egos.  We want to meet our customer’s goals and needs as quickly and cheaply as possible while still delivering a product that we can be proud of. A product that will last and cause its users to exclaim “Damn i’m glad we chose that company!” rather than “Glad this piece of shit is finally done”.

We don’t want to ignore the customer, indeed we want a proper report even more desperately than most Agile adherents. We want them to love quality work as we do and understand that to produce the best result takes both time and money, but less of both if we start out well and continue in the same vein, working together.

Uncle Bob sums up this idea here: http://cleancoder.posterous.com/software-craftsmanship-things-wars-commandmen

He also has come to the conclusion that this fear and panic amongst agile adherents must be caused by a misunderstanding; the claims that we are returning to a worship of development above all is misguided at best, and flat out wrong at worst.

All of this is secondary to the reason I first became inspired by the Software Craftsmanship movement. I have spent a lot of time working on projects plagued by these very problems over my career. Projects in support where previously happy clients have become worn down and bitter by the never ending stream of fixes, bugs and performance issues which are the legacy of a timeline that was too tight, and corners that were cut. Watching Bob Martin’s talk on Info Q about clean code, he said one thing which resonated with me. He said, very simply, follow the boy scout rule and leave the code cleaner than you found it each time you fix a bug.

It was simply amazing to me how much of a difference this made to my outlook. I went from miserable and burned out to excited and once again proud of my work. I couldn’t fix the entire project, it took thousands of man hours, hundreds and hundreds of thousands of lines of code, and many deadline panics to get it in the state it was in. But each day I could fix a little part of it, and walk away understanding that I had not only done my best to satisfy the client in the immediate term; by fixing the bug; but that I had made a small improvement to the system -as a whole- that, in the long term, will lead to a far more satisfactory system for everyone.

Making a difference matters. Having pride in your work matters.  Doing the best you can each time you sit down to work matters. Knowing, when you have to make trade offs and create something less than it could have been, that the situation really requires it, and its not just because you lacked the courage to stand up for your work; that matters too.

The end result matters, and it takes more than just great client engagement.  It takes great client engagement -AND- great development work. And that is why I am a signatory of the Software Craftsmanship Manifesto.