Bridging Development Realities
Denis over at One Brike At a Time recently expressed frustration at having to use low trust practices:
It used to be that I did not care much for defensive programming outside of a system’s boundaries. It used to be that I did not really care or believed in strict source control (as in authorise only some people to touch a particular file). It used to be that I did not really believe in code reviews.
I now care for these and it is not a good thing. I care about these things because I do not trust the developers I work with to do the right thing, whether it is making the code better, improving their style, teaching me new things, or even write decent unit tests.
The frustrations are real. Teams are often at many different levels of skill and experience. Even minimal unit testing is not a common practice in many shops. You can still find developers who look surprised when you ask where their code is checked in.
Lower trust practices can be a bridge:
- Source control is a given. Developers who check in bad code you might force you to lock things down for now. Continuous integration is a way to grow out of this. If all of your projects are being built with any change, you can quickly discover if someone’s injected some issues. This might mean setting up notifications for even successful builds for non-active projects.
- Code reviews don’t have to be a negative. I’ve used them and still use them more for mentoring than as an audit of bad code. Code reviews are easy to get wrong, but used safely they can improve the code base and improve your coders through sharing. And I always leave the easy out–no code reviews if you’re pair programming.
I whole heartedly agree with your remarks. Thanks for the positive spin on it
The level of mistrust I am facing is that developers will go as far as removing tests to avoid breaking the build or put obviously weak ones to ensure the coverage level is preserved…
I have put forth a proposal to change our development process to address these issues. I hope to write on this soon and I would love to have your opinion on it when I do !
I definitely wouldn’t treat unit tests, code review or strict source control as thigs which help you deal with colleagues who you don’t trust. That’s wicked.
I think one should treat those as tools to help fresh faces to join team standards or to coach people who don’t deliver top quality code or to exchange knowledge or to rise quality of team’s work.
Of course if code review (to take first example) is implemented poorly it won’t do any good. However if you assume you implement code review because you don’t trust your developers that will most likely suck. If motivation to implement any technique is negative you’ll see people omitting the technique (vide removed or weak unit tests).
I’ve seen the poor unit test strategy where the tests are anemic, but they meet the code coverage targets. This is the sort of thing code reviews or pairing helps resolve. At first though I don’t get to worried about seeing this sort of thing. My experience is people adjusting to TDD style or at least writing a reasonable number of good unit tests takes time.
Thanks for the feedback though and I’ll be on the lookout for your posting.