More Haste, Less Speed
For a long time, I’ve been convinced that it takes much longer to fix the mistakes that were caused by rushing than it does to do slow down and do the job properly. The trouble is that sometimes it takes longer to explain that to a project manager, especially if they’re inexperienced, or if they’re getting grief from clients about delivery dates.
It’s the kind of thing that got me thinking about anti-patterns in team leadership. This sort of mentality leads to endless crisis meetings, so that developers spend longer talking about why the project has problems and defending their own competence than they do working on the problems that the project is there to solve. Besides, most developers are better at solving problems than they are at talking.
I’ve previously written about my own opinion on the value of code review, and as my colleague Tom Phethean put it, “effective code review is directly linked to quality of the code which reaches production, so don’t give in to time or management pressures and skip reviews”.
Most managers won’t want to hear this, but very often when there is a problem, the thing that developers should do is slow down. Rather than jumping straight into writing code and finding solutions for problems, spend some time thinking about the problems themselves. Why do those problems exist? What are the underlying causes? Are they just symptoms of some deeper problem? Are they worth solving? Developers love trying to solve problems, but sometimes they need someone to stop them trying to fix everything.