Daniel Irvine on building software
Reinventing the wheel, and the beginning of a feud
15 June 2012
In my last post I talked about the importance of using documentation to solidify the design of a feature. One thought that lingered with me was this:
As an agile team we should be heading towards less system documentation and instead using the source code to document itself.Believe me, we tried doing this. But we failed, and since then I’ve been trying to figure out why we failed. My theory is this: a lot of our original code base was documented through its tests and has little or no accompanying written documentation. That was fine, until our team grew in number. As the team grew we inherited people who didn’t have the same “agile code mentality”. Here’s an example:
Developer A: This code is rubbish, I’m going to refactor it and make it better.
Me: What? The code is fine: it’s in production use, it does the job. Why do you want to change it?
Developer A: Because the design is rubbish. I can make it better.
Me: The design is fine.
Developer A: There is no design! Show me the design document.
Me: There isn’t one...
Developer A: So it’s rubbish. I’m refactoring it.
Me: That’s not refactoring. That’s reinventing the wheel.At the time, my decision was upheld and the code was kept in place. But then the issue came up again with a different piece of code. And then again. And again, until we reached the point where my authority as team lead had been undermined and people stopped listening to me because they thought I was wrong.
Herein started a period of stagnating development that was only alleviated when we introduced written documentation that acted as a “roadblock” to these reinventions.
It takes a certain ability to see the value in someone else’s code, and to believe that other people’s code can be just as good as your own. Junior programmer’s have this ability but it’s based on fear of their elders and not on respect. Over time this fear is lost, but if they don’t replace it with respect then the senior developer will have often lost this ability entirely.
For it to happen between teammates is a very demoralising thing for the team and it must be kept in check. We’re all capable of it, and I know I’ve been guilty of this at times. That’s been the big lesson for me as a team lead: you absolutely cannot afford to fall for anti-patterns. Let your team do it, and try to correct them, but always make sure you aren’t doing it yourself.
Maybe one day we won’t be wasting energy on building roadblocks.