There is a classic American Western movie cliché where the sheriff, in an attempt to catch an outlaw, calls for the organization of a ‘posse’. By western movie definition, a posse seems to be a band of people that have just stumbled out of the saloon and with much enthusiasm, whiskey, bad teeth and various weapons charge out of the town on horseback at night (where the dramatic effect of torches is needed) to hunt the outlaw down. Based on my childhood recollection only, it seems that posses were easily outsmarted by the sharp shootin’ outlaw (and his horse) and were generally ineffectual – which is to be expected when trying to get a hastily organized ragtag bunch on untrained drunk gamblers to take on the central hero of the movie.
In software development we have all come across developer posses, where a bunch of developers are assembled with a low quality bar and thrown at a problem and their inability to deliver overshadows their enthusiasm. But this post is not about drawing out that analogy – I’ve set the ball rolling, you can discuss it amongst yourselves. What I am interested in exploring is whether or not you can differentiate between the developer posse and the developer ninjas.
Until recently the ninjas could differentiate themselves from the posses by talking about agile and *DD, but it would seem that the agile and TDD terminology has become familiar to the posses. Any posse can buy a book on agile from Amazon and immediately become an expert. So the ninjas have moved on to other engineering practices and have essentially gone beyond agile and TDD. The problem is that the business is still barely able to understand the agile and TDD pitch, never mind the techniques that we may be using today. I challenge any developer to sit down in front of business and explain that we make better software because we apply the Liskov Subsitiution Principle – business will run screaming and immediately round up a posse. So the posses are stealing the lingo and running rampant, so how do you describe a development team of ninjas to business that makes them understand the value?
Assuming that the value that we add is producing software of high quality that works, is performant, maintainable and extensible, how do we illustrate this to the business (our customers)? Unfortunately we (individually, collectively and our principals) suck at the metrics of software quality – whether that is from apathy or because it is virtually impossible to do. We can’t point to a figure and say ‘Our maintainability index is X and that posses maintainability index is Y, therefore the costs are better with us over n years’. We may be able to talk about it in theory or generally, but not for our particular team of ninjas.
On a project that I was on a few years ago the project manager asserted that we had a good architecture and in an important meeting she was challenged on her opinion – after all how can a non technical person make such a statement about architecture? She replied that she knew that the architecture was good because as the requirements changed and evolved, they were easily accommodated which meant that the bits underneath were flexible, adaptive and maintainable. So how do we measure, objectively, the ability of a system to handle change? On my current project I have to maintain code from a developer that has moved on to another bit of work and I have to babysit his code as we go through testing. I have found that his code is both of high quality and surprisingly easy to make small little changes without breaking anything. So do we bother to measure the turnaround rate of defects as a measure of quality?
It would seem that the natural reaction for development ninjas is simply to move on to the next thing and recently a group of us were urged to become more specialized – I suppose as a means of technical differentiation. Of course we can specialise further, learn a new language or framework or whatever, but by the time business understands what we are talking about the posse has caught up and we need to move on to something else. While I encourage learning new things as part of the software development craft, appearing to specialize as a means of value differentiation detracts from the real value that good software development teams can provide.
The people that I work with are specialists – not in some particular stack, framework or technique but rather specializing in building flippin’ good software. I am sure that someone would find value in that – we just need to figure out how to sell that value to the business. I don’t really know how that can be achieved and am probably not qualified... I would wear a t-shirt with ‘Back off posse, we’re ninja’s!’ but while I may get away with it in this blog it is open to being misheard and mistranslated somewhere down the line.
So what are the business digestible ways of describing why we deliver good software?
Simon Munro
@simonmunro
If you get something useful or interesting out of my blog posts, please sponsor me in my attempt to cycle from London to Paris for a good cause.