Last September, ZeroTurnaround released analysis of a survey focussed on tools and practices of developers. They reported on how these affected the quality of code and how predictable delivery dates were. The Developer Productivity Report 2013 is a long read with lots of details. In the end, the data support what most developers already know. If you’re a programmer like me, does any of this surprise you?
- Pair up with another coder sometimes
- Automate unit tests and keep on top of failing tests
- Minimize meetings
- Use source code control
- Use an issue tracker
- Use an IDE and a debugger
- Do code reviews of new code
- Estimate as a group, but exclude the managers
I accept all of this with the except that I have not found IDEs to be a significant improvement to my productivity. Sometimes I wonder if exposing all the prototypes through popups doesn’t prevent developers from mastering a system and internalizing it. On the other hand, having memorized all the random parameters to PHP’s function might have been a waste of brain space. I’ll probably be fine for now with Geany and grep.
There’s a remarkable nugget about testing (slide 7):
Automated tests showed the largest overall improvements both in the predictability and quality of software deliveries. Quality goes up most when Developers are testing the code (also discussed in Sven Peter’s talk “How to do Kickass Software Development” at GeekOut 2013), which means that you shouldn’t just leave testing to QA team, but bake it into the development process as well. The rest of the measurements were more or less insignificant, although we don’t recommend letting yourcustomers/users test your software for you.
If you can convince your developers to do testing, there’s a big advantage for quality.