Developing Programmers .com

In my dream job, I would have a manager that takes care of how code is turned into money for me and is able to manage projects in a way that never results in “crunch time” or having to compromise.

In practice, people who can manage programmers well are rare. You’re most likely either to find career managers, who did a management course and don’t know an awful lot about programming, or to find programmers managing. These programmers-managing would love to be in there coding with you but instead have to manage a group of people, which sounded like a promotion at some point but is really quite a different role.

My boss is the second type, although a researcher managing rather than a programmer managing.

Sometimes our managers need a helping hand. For example, I recently changed the direction of our current project, possibly steering it from a deadline overrun, just by writing up a Gantt Chart.

If you’re not familiar with Gantt charts, they’re basically a to-do list that shows on a graph the time it’ll take for each task and which tasks can be done in parallel. You could get much the same effect for a small project by writing out tasks in a spreadsheet with the estimated time beside each task. A good Gantt chart breaks the task down into small enough tasks that a time estimate for them is reasonable. For example, you might estimate a week to write a module but if you break it down into UI (2 days), database connections (2 days), logic (2 days), debugging (3 days) then you’ve just shown it’ll take almost two work-weeks. The latter estimate is more likely to be accurate because we have a tendancy to “forget” trivial tasks but they still take up our time.

Time estimates are difficult but if even your estimates run past the deadline at least there’s time to change something! This is roughly what happened at work: I collaborated in estimating the time for each component with the person I’m doing the project with, and we ended up agreeing on a time-line/Gantt chart for the task we’d been set that ran well past our deadline. We took this to our boss early enough that we could make a new plan. We still don’t know if the new plan will result in another difficult “crunch time” or not, as estimates are notoriously unreliable, but at least we changed things early enough and the estimates predict that an on-time project is plausible.

Looking around on the web I found another amusing anecdote about programmers helping their boss out with time management: At a company called BigBook a deadline was slipping so the manager wanted to hire more help. The programmers failed to convince him that the tasks required were sequential and more help really wouldn’t speed up the project. They tried to persuade their manager to read Brook’s book, “The Mythical Man Month”. The book is often boiled down to Brooks’ Law: “Adding manpower to a late software project makes it later”, but it does offer a lot more insight than that. According to O’Reilly Radar:

After failing to win several arguments on this point, the engineers became exasperated and decided to hold an intervention with the CEO. They each bought a copy of Brooks’ book, brought the CEO into a conference room, and stacked up the copies of the book, telling him, It is extremely urgent that you read this book. We’ve bought you many copies so that you might read it faster. They made their point.