I have recently came to the frightening realization that my team and I don’t know all of our source code. I’m not talking with you about some code written ten years ago and that no one uses. I am talking about the code of major components that at the heart of our production – and that’s scary.
This situation can be the downfall of a team, if a team can’t support, change, or add to its main components, then it can’t adapt to the change, making the team, and sometimes the organization, obsolete.
This problem should be a cause of concern to both individual developers (you want to do something new and not dwell in the past), and of management (you want to pay developers to develop, not maintain).
But it doesn’t have to be like that. I have seen two types of solutions throughout my career, implemented in more than one team, and I’d like to explain both of them.
The first solution is simple – don’t let knowledge die. When a new developer comes to the team he would study every code that the team has written (or that knowledge is somehow distributed among developers) and there would be a comprehensive documentation to help lost memories.
This solution actually works, in my first team I know everything piece of code, I felt in control, and I know I could change what’s needed if that would be necessary.
But thus solution was of a limited success. It waists months in training and keeps the team with eyes on the past rather than on the future. Also, after there is too much source code (and it takes time to get there), this solution is just not feasible.
But there is also another way, a way to keep developers doing new stuff and not be consumed by old code out of fear that they won’t be able to change it otherwise.
In my last team I learned something quite amazing. I was asked to modify systems which I never seen a line of code in then. This was really scary, and I resisted, and I had to be convinced. But in the end I jumped into the unknown code and made the change – easily!
You may think that I am implying that developers are just scared of touching unknown code and that everything would be fine. No, that’s usually not the case. Usually reality is far worse and touching one place in the code causes damage to another place, and that can be magic like to know that beforehand.
But the key word is usually. And it’s not a matter of luck which code would be easy to change and which code isn’t. So what’s the secret?
The secret is within the code and its quality. We can build systems that has the quality of being able to change, have a safety net that would tell us if we broke something, and that would allow us to move forward without fear.
In future posts I would describe the tools and techniques you can use to achieve this result.
I hope that you’d find it interesting,