|
|
|
Sponsored Link •
|
Summary
Two radically different philosophies to the management of software developers. Which one do you favour?
|
Advertisement
|
Recently my wife and I were discussing the next few years, including what kinds of work I'd be taking on after my current stint: I'm currently splitting my time between helping a client's team redevelop a successful, but aging, data manipulation product to be able to handle data sets up to 4 orders of magnitude larger that it can currently manage, and working on my next book(s). Both activities are highly demanding, very rewarding, and probably going to complete early next year. Lucky me! ;-)
After that, my current (modest) plan is to do some hard-core consulting to the banking and finance industry here in Aus, hopefully helping them to boost the performance of their trading systems by substantial amounts. (Working on high-performance high-robustness networking systems is what most whets my development appetite.)
But after that, perhaps towards the end of next year, I said I'd like to take on a new development team, but do so on my terms. (These terms will be explained in a moment.) Having just come out of a position of being involved in the management of a development team in a struggling organisation, with all the stresses that that entails, my wife naturally enquired as to why I'd consider going back to that. She makes a good point, because it was a hell of a cat-herding, management-juggling, technology-obviating 18 months. (Helping developers to learn and improve is what most whets my managerial appetite.)
The question of why I'd like to try it again - after my product redesigning, book writing, bank optimising, library releasing fun in between - boils down to what I have lamely termed down the years (in conversational rants on the subject with anyone who'd listen): the Equine Management question. A friend recently suggested that I put it down on electrons somewhere, so here goes. Please come along for the gallop ...
In The Mythical Man-Month, Fred Brooks comments on studies showing that within groups of experienced, competent developers there can be productivity differences of up to 1000%. Furthermore, the quality of the produced software can have similar disparities. Brooks comments that software produced by experienced, competent developers can have performance differences of up to 500%.
From personal experience, I can certainly say that I've experienced groups of developers with productity and quality - not that software performance is the only, or even the most important, measure of quality - ranges at least as large as this. Where I would demur - again, based on personal experience - is in stipulating that the large ranges encompassed "experienced, competent developers". (Again, more of this in a moment.)
Being keenly drawn to simplicity in managing life, I am given to applying deductive reasonsing from facts to reach conclusions regarding human behaviour. In this case, I believe that the critical role of any software development manager is to ensure that his/her development team is populated with individuals who are towards the upper end of the performance range. This may be achieved by a variety of means including, but not limited to, recruitment, education, and mentoring. But that's just the tip of the ice-berg. Crucially, having a team populated with high-performing individuals is no more permanent than the optimal conditioning range of the musculature/brain/aerobic-system/etc. of an elite athlete. As soon as you allow it to, it will erode. Being a developer who is capable of inhabiting the upper bands of these metrics, I am all too aware from experience how easy it is to fall down the ratings, through fatigue, bad management, lack of appreciation (more often peer approval, though money is a factor) and boredom.
What I call the Racehorse Model of Development Management recognises the wide range of possible performance of software developers and the concomitant opportunity for an organisation to prosper, and attempts to give them the best possible circumstances within which to produce at their best. Given that software costs are a significant factor in (almost?) all software development organisations, dramatic increases of the order of 100-1000% are to be sought, and valued, most highly.
Racehorses get the best hay, they get to come in at night, they get the best medical care, they are brushed, massaged, trimmed, cosseted in all manner of ways. But on race day they have to run. Very, very fast. And when they're old and past-in they're sent off to stud, where they can "pass on" their abilities so that the next generation can go even faster.
The converse approach I call the Carthorse Model of Development Management. Carthorses are (comparatively) big lumbering beasts tasked with pulling big loads on slow carts. They aren't cosseted, groomed, massaged, and they don't get to eat Marks & Spencers imported New Zealand carrots peeled by albino virgins with diamond knives. And, worst of all, nobody expects them to get their job done with any speed or grace.
Carthorse managers don't bother too much about the working conditions of their developers. They fuss about a developer being in the office between the hours and 9 and 5, and yet won't provide these developers with extended periods protected from interruptions (and that includes meetings!) during their day that would allow them to actually be productive, as opposed to just being present. They wouldn't dream of offering the developers a day at home to research a new technology/language, just in case it "might look bad". They don't battle for better conditions for their developers because they simply don't understand that better conditions will lead to productivity increases orders-of-magnitude greater than preventing them from having access to the internet just to stop the occasional email to their friends
I've encountered Carthorse managers many times in my consulting career - in my earlier, salaried career, I didn't identify them as such; they were just people whose inexplicably arbitrary interference I detested - and in my experience they fall into two camps. Either they're people who've never been software developers, and simply don't get it: it's kind of like putting an accountant in charge of a school or hospital (or a software developer in charge of a football team). Alternatively, they're software developers who, by dint of personality or immaturity, have poor social skills and are often paranoid about subordinates outshining them. In both cases, one wonders why they have been put in that position. Like as not, it's a manifestation of the Peter Principle, whereby (usually) smart, talented people are promoted one step beyond their competence. And once there, there's no going back.
The best thing one can do for such people is to buy them a copies of The Mythical Man-Month and PeopleWare and cross one's fingers. The best thing for any racehorses that find themselves being managed in such a way is to find another position, before you find yourself wearing a harness pulling a big cart!
Before I (briefly) outline the characteristics of racehorse management, I would observe that there's a third, accidental, school of development management: Wild-horse Management of Software Development (a term recently confected). Such teams tend to be subject to ad-hoc management, often under managers that have other responsibilities. Some may be geographically diverse. Some I've encountered had developed within companies whose main activities are outside software development; others where the founding software developer has become CEO, CIO and chief cook and bottle-washer, leaving the team to fend for themselves.
Where racehorse management (if done well) will tend to produce outstanding results, and carthorse management will tend to produce very average results, companies utilising wild-horse management may vary wildly in how well they produce software. I suspect this is due to the differences between potentially highly productive developers when left to their own devices: some will perform highly in isolation, others may flounder for lack of contact, intellectual exchange, and recognition/affirmation.
In my personal opinion, wild-horse teams need to evolve - hopefully to racehorse teams - to really achieve. If you fail to start their evolution in that direction, you may find that they dissipate entirely or, equally undesirable, someone else in the organisation will force-evolve them into carthorse.
So what exactly is Racehorse Management. Well, I'm not sure exactly. Since this is as yet a personal model, and this is the first time it's been given any kind of write-up, it's more of a case that I know it when I see it. However, there are some defining characteristics that can be stipulated now:
All the foregoing might seem relatively obvious for any modern team. However, there's one final aspect that we've not covered, and which you may be wondering about. It's one that I deem as essential to the model. If a developer is consistently, and irretrievably, under-performing, you have to be able to expel them from the organisation. And not with months of "performance management" and all that (mutually) soul-destroying rigmarole. Of course, this should not be done without consideration or compassion, but it has to be done. Slow race horses win no races, but they still eat hay.
In summary, I shall defer to far greater experts than I, the authors of PeopleWare, Marco and Lister, who say (from PeopleWare, of course): "a manager's job is not to make people work, but to make it possible for people to work".
Well, I'm a realist. I know that there are precious few organisations here in Australia with the foresight, the scale and the finances to create truly world-class teams on the basis outlined in this article (and that includes the ability to easily get rid of irretrievably underperforming developers). However, if any come knocking on my door next year wanting to build world-beating software, I'll let you know how it goes.
Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Matthew Wilson adds a new entry to his weblog, subscribe to his RSS feed.
 | Matthew Wilson is a software development consultant and creator of the FastFormat, Pantheios and STLSoft libraries. He is author of the books Imperfect C++ (Addison-Wesley, October 2004) and Extended STL, volume 1 (Addison-Wesley, 2007), and is currently working on his third, Breaking Up The Monolith: Advanced C++ Design Without Compromise. He has published over 60 articles on C++ and other topics, and has served as columnist and contributing editor for C/C++ Users Journal. Matthew believes that code should be discoverable and largely self-documenting, and lives up to that by being a hopeless documentor. He can be contacted via http://www.imperfectcplusplus.com/ or stlsoft@gmail.com. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit