Interview for Joel on Software Live
Michael Smith: This time we are talking with Joel Spolsky about his CFUNITED-05 talk "Project Management the /Joel on Software/ way". So why should a developer come to your session Joel?
Joel Spolsky: Most people who have to manage software projects are software developers, not project managers, and nothing about writing code has trained them to put together large projects and ensure that they actually deliver a quality product on time. I’ll use this session to introduce my own simple philosophy of project management: running a team, picking the features to do first and the bugs to fix first, and deciding when to ship.
MS: So what kinds of things can happen when an untrained project manager runs a software project?
JS: All kinds of things. A common mistake is to hope, against all evidence, that the team members are smart and will be able to organize themselves, so the newly promoted programmer decides he or she can afford to spend 80% of their time writing code and only 20% of their time managing. The trouble is that without any kind of system in place to decide what to do and in what order, chaos ensues and you either get a death march project that’s never done, or an inadequate product that nobody wants. A typical manifestation of this is that team members work on the fun things first, not the important things, so when the schedule is running late and you have to cut features all the features left to do are important features that can’t possibly be
cut.
MS: Ouch that sounds painful! So how do you think the team should be run?
JS: I would never have the chutzpa to say that I have the answer for all teams. However, in most cases, the key thing is to have a constantly-updated, real-time, highly detailed list of features and tasks, with priorities and estimates for each item. Then at any time everybody knows what they should be working on and in what order, and if you have good estimates, you should be able to say "if we do all priority 1 features, we’ll finish on date X, and if we also do priority 2 features, we’ll finish on date Y." Now it’s a simple matter of setting a date that gets the optimal balance of features and shipping (shipping is a very valuable feature).
MS: What about bugs – software always seems to ship with bugs – can that be stopped?
JS: For the purpose of project management, a bug and a feature are the same thing: something somebody has to spend some amount of time on with some priority. If you can store feature requests and development tasks in your bug tracking system, all the better, because now every morning every developer knows exactly what to work on first.
MS: Doesn’t tracking bugs and tasks add a lot of overhead to the project?
JS: Yeah, and hiring an architect adds a lot of overhead to your kitchen renovation, but they both save you a lot of time and money, in the short run and in the long run! You’re going to be tracking bugs and tasks anyway, it’s just a question of whether you do it in an organized fashion where everyone can be on the same page, or on a whiteboard in one person’s office, where it’s apt to be erased by the cleaning lady.
MS: What about dependencies between tasks – especially things the client is delivering to the team. Any comments on how you handle that?
JS: My experience is that when building software you don’t have as many dependencies as you might think. In house building, you really have to build the walls before you can put in furniture, or it will rain and ruin the furniture. But in software the furniture programmer can just write "int wall(){return 43;}" as a placeholder and get all his furniture in place long before the wall guy has delivered his piece. Its so easy to move things around that you hardly have any dependencies, and those you do have are so clear and obvious it’s almost not worth tracking them formally.
MS: How do you estimate when the project will be completed?
JS: Begging forgiveness in advance for a glib answer, you don’t! What you do is set the date when the project has to be completed and then pick the optimal set of features to meet that date. Your schedule should have line items and estimate for every task, bug fix, and big line items for debugging, integration, buffer for new features that you forgot to mention, even line items for vacations and holidays. Then you can add up the number of hours you have for each person on the team, take the maximum of that, add it to today’s date, and get your scheduled completion date, which, inevitably, will be two years too late. So then you start prioritizing and re-prioritizing until you can reach the date you have to ship on with only the top priority features.
MS: Sounds good. See you at CFUNITED.