Have you ever worked on a really successful project, one of the rare on time and on budget ones? Did you get a reward and a lot of praise in the end? Yeah I didn’t think so. Now think back to a project where everything went wrong but through super-human efforts you were still able to get the beast into production. Any accolades for this one? My guess is you probably got a few and if not you personally, than someone on or around your team did. This seems to be a really common scenario with software projects; people who are associated with highly successful projects are forgotten while people on “death marches” (that are too expensive to cancel) are praised and hailed as heroes.
The Well-Run Project
Really successful projects are few and far between but when they do happen they are a joy to work on. Not only that, but the software delivered is higher quality and meets expectations. Budgets and deadlines are adhered to and everyone associated with the project is happy (more or less :)). Most of us dream of working on such a project. So when a project like that finishes, how does the business show it’s appreciation and express it’s desire to see more projects of the same caliber (i.e. what kind of positive reinforcement is used)? Well, everyone gets a pat on the back and then moves on to the next thing. A little anti-climactic wouldn’t you agree? You see, everyone expected the project to go well and when it did, noone was surprised, everything went according to plan, why would anyone reward or even acknowledge it when things go according to plan. That my friends is what I call negative reinforcement.
The Crappy Project
Crappy, death-march projects are routine in software development. Projects begin with unrealistic expectations, concrete commitments are made based on estimates and information that is far from concrete. And when things inevitably go pear-shaped developers cop the brunt of the fallout. We are forced to shortcut our process and compromise on quality and when that is not enough, well we just work longer and longer to make up the shortfall. At the end everybody is stressed and tired, but sometimes the gargantuan efforts are enough to get the project (or what’s left of it) into production. When that happens, we crack open the champagne and hail the project as a miracle of modern software development. Everyone shakes their heads and marvels at how the team was able to do the impossible. Awards and praises are handed out and everyone is too happy to notice that the project was actually a year late and millions of dollars over budget. I lie, everybody is well aware of the fact that the project was a complete debacle, but with so many people patting each other on the back, it just doesn’t seem politic to say anything. You would agree that this is the ultimate in positive reinforcement.
It Is A Bizarro Universe
The above scenarios strike me as being completely cuckoo. We acknowledge and praise people who try (and sometimes succeed) to pull projects out of the jaws of failure but don’t do the same for people who push project into the ‘jaws of success’.
Have you ever tried to train a dog? Next time you do, try the following. Every time a dog does something you like (such as fetching a stick or rolling over), a positive behavior – just ignore it. But every time the dog does something ‘bad’ (like peeing on the carpet), a negative behavior – give it a treat. My guess is you will quickly end up with one confused and badly behaved dog, and yet we do this on an industry-wide level. It is truly bizarre.
This Culture Needs To Change
In an industry where project going pear-shaped is the norm, it really behooves us to look more closely at the ones that don’t. I for one would love to see a little bit more appreciation from everyone for projects where things go according to plan and especially for the people on those projects. It might sound crazy but I do believe that delivering a year-long project on time while having all developers work at a sustainable pace (oh I dunno, let’s say 40 hours a week :)) deserves at least an honorable mention for the people involved.
The other side of the coin is rather than celebrating the belated delivery of the latest death-march, how about digging into it and trying to figure out why it was 6 months late and why people had to work 80 hour weeks to keep it from complete disaster. And when we do figure out what the problems were it may be worth it actually learning something and trying not to repeat the same mistakes rather than just writing it all up in a report and putting it on the wiki or in the document repository. Because wikis and repositories are just some of the places where lessons go to die.
__
For more tips and opinions on software development, teams, process and people subscribe to skorks.com today.
__Image by salimfadhley