Smart Software Development on Impossible Schedules

Andrew Stellman writes "Jennifer Greene and I have an article in the new issue of Dr. Dobb's Journal called "Quick-Kill Project Management: How to do smart software development even when facing impossible schedules." We got a lot of great feedback from our last article on open source development, but there were a bunch of people who wanted to know whether it was really feasible to do planning and reviews on a tight schedule. That's a fair question, and this article is meant to be an answer to it. We pulled out bare-bones project management practices that will help you protect your project from the most common and serious problems, and gave instructions and advice for implementing them that should work in a real-life, high-pressure programming situation."

Comments

Re:Code reviews

[Bodrius]

Although I think pair programming can be great in many contexts, I think they really have mostly complementary advantages:

a) An in-depth code review (formal or not) has a big difference from pair programming: the analysis is done by a fresh pair of eyes. Pair programming can result in two people who are too close to the code to detect flaws in their underlying assumptions.

In my experience, code reviews are not that useful to detect syntax or style errors, nor do I think they're meant to be. That's the kind of thing you can automate with a tool anyway. If you're spending all your time looking for that, I agree most people will feel it is a waste of time.

But code reviews can be extremely useful at a higher level: to detect design gaps and flaws in the implementation, or just get improvement suggestions that a fresh set of eyes ban provide, once you see the whole solution.

Often the very process of explaining the whole solution top-down after implementation allows you to detect issues. Other times you can identify common patterns and needs in different features that we're not visible before ('hey, I had to do the same thing elsewhere and we have a common utility class/method for this that avoids this obscure bug here').

b) I don't see how it should be that different regarding the attitude problems you are describing.

If people get so easily offended by a code review, it seems to me it'd be because of team problems bigger than a code review process: either the programmer thinks their code is perfect (which is something to fear) or they don't trust their peer enough to have honest conversations about code.

I guess this is the one advantage of pair programming, it forces people to work closely and practically guarantees that trust. But I do not think you need to lock two people in a room and do everything together for them to trust each other professionally in a healthy work environment.

Heck, code reviews should be fun.

They're peer conversations about code, and if you enjoy programming it should be fun to argue techniques and solutions with your colleagues, even (specially?) when there are strong disagreements. Both sides typically learn something from it; even if a lot of times it is not something you want or need to change in the current code, it will be useful knowledge elsewhere in the future. Just like college or academia, for that matter, back when coding was done for fun.

Re:Tried and true

[Lonewolf666]

Only that it does not really work. Overworked programmers are tired programmers who make more mistakes. Long ago, research has shown that the best productivity is reached with a 40 hour week.

For details, see http://www.igda.org/articles/erobinson_crunch.php