This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Programmers don't make projects fail
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
The other day I was talking to a friend of mine who is a software project manager. We were talking shop when he told me about his team, and how they saved the project. As he related the story it became clear that the team nearly killed themselves saving this project - working 6, sometimes 7 days a week at over 12 hours a day over a 2 month period. This could be just another anecdote for the Chaos report, but I wanted to give my spin on this all too common scenario. Whenever I recruit somebody, on their first day I explain to them my project philosophy: Programmers don't make projects fail, even if they don't work overtime. If you look at the Chaos report published yearly, I doubt you'll ever see the lack of overtime on the top-ten list of reasons projects fail. So why is it that whenever a project looks like its getting into trouble to managers pull the overtime card? Could it just be a case of "well, what else could I do?" God, I hope not. My philosophy is followed with an operative task: If you ever have to do more than 2 hours of overtime in a week, let me know. Programmers are on the front line. They're the first to feel that things are beginning to get off track. Even without talking to their manager, they usually try to get things back on track by working more hours. Overtime is a symptom of much larger problems. It could be that requirements that appeared simple to implement are much more complex (the most insidious kind of scope-creep). It could be that interfaces to external systems we need to interact with aren't stabilizing in time. It could be anything. Once you see overtime on your radar, it means that you need to start looking for exactly that "anything". I've been through several such projects where all the pressure was put on the programmers to bring the project to completion. In each case, they did not have the power to do so simply because the problems that needed to be dealt with weren't technical. The classic saying of "people trump process, and politics trumps them both" rings so true. If you're the manager, you need to step up and handle the politics or the project's doomed. Don't take the cowardly path - "I pushed the team as hard as I could, literally 24x7, what else could I do?" Unfortunately, many programmers-turned-managers really don't know any other way - this is what their managers did when projects got into trouble, so they do the same. Not to end on a doom-and-gloom note, you'd be surprised how quickly you can identify real issues by checking overtime. Of course, the faster you identify these issues, the sooner you can resolve them....
Previous Topic
