Technical Debt
More On Accidental Technical Debt

Feedback on my post about accidental technical debt, including a great comment from Brian Willis has highlighted two additional mitigation techniques that I omitted from the original post - Code Reviews and Interactive Development.

Commenter Brian Willis writes about the use of code reviews to accidental technical debt:

I’d add that mandatory peer review of code before it gets pushed makes for a world of difference with this kind of technical debt. When I was getting started as a developer, mentorship from senior devs prevented me from committing mistakes like the XML parsing example you gave.

Brian makes a good point - if you can establish a team culture of regular code reviews, the rate of knowledge flow amongst your team will be greatly accelerated. Such regular transfer of knowledge between developers is just one of the benefits of such an environment.

A major challenge for some when introducing code reviews comes from the common practice of developers personally identifying with their code and thus interpreting any critique as a personal attack. As a group we tend to pride ourselves on our intellectual and problem solving abilities, making it really easy to fall into this trap. One way to break out is to realize that the goal is to maximize the business value we deliver, not our own mana.

Unfortunately, you can’t break someone out of this mindset, no matter how persuasive or tenacious your argument. You can only change your own.

Code reviews are one example of the broader approach of interactive development. When we work interactively, when we collaborate on a continual basis, we open up the communication paths for sharing information and knowledge, both technical and domain specific.

It is all too easy for us to fall into the trap - the anti-pattern - of working solo, even when nominally working as a part of a team. We can spend all our time concentrating on delivery of code, never actually working together, never sharing what we know and never learning what our colleagues have to teach - and we all have something to teach.

How much does your work environment suffer from developer isolation? Do you share what you know - do you actively work to share what you know, and to learn from others?