Ask any programmer whether he likes to write new code or maintain existing code. You can be sure he will choose - write new code. Ask him the next question, which of these is harder? The answer will be - maintain existing code.
Ask any software company what they want and most will answer Growth. Ask them how they will grow and they will say either "new projects", "new products" or "new features".
This alignment of organization interests and programmers interests results in the more experienced and best programmers working on writing new code. The easier task. The rest will be asked to maintain existing code. This means the least experienced programmers are working on the harder task.
This results in the quality of code deteriorating fairly rapidly and however good the initial architecture it very quickly becomes a big ball of mud. What are the results of this big ball of mud architecture? Bug fixes and minor modifications become harder and take longer to do and gradually existing customers find their complaints and suggestions are being ignored.
This slippery slope will be familiar to many software organizations. The older the product the harder it is to keep existing customers happy.
Is there any way out of this? The rest of the blog will look at this question in more detail and make some suggestions.
Let us examine the deterioration of the quality of code. Why exactly does this happen?
First we need to understand the drunkards walk algorithm. When a drunkard leaves a bar if at every intersection he goes in a random direction, including the one he came from, will he ever reach his house? The answer is he will, but its very hard to predict when that will happen. (In the name of political correctness it has been renamed Random Walk.) Here is a visualization of a drunkards walk.
Developers often use a similar strategy when they maintaining code in complex systems with which they are not familiar.
They squint at the code and say "I think this is the problem" and make a change. They hopefully throw it across to the testers. The test team re-opens the issue. Often without rolling back the previous change, the developer will squint and make one more change. At some point the problem goes away.
Then one more defect comes in and another fix is found with this drunkards walk. Slowly but surely the code is becoming fragile.
The problem of deteriorating code is invisible. It feels good to be solving point problems quickly. People appreciate you for fixing the defects. You may actually get a few employee of the month awards for "caring for the customer".
Like this mom who has solved a point problem. She is proud of it.
Till one day she drive over a bump too fast and the inevitable happens, the chair tumbles out. It is a good solution but unfortunately it is fragile.
This is the concept of Jugaad that we Indian's are so proud of. These are low-cost "point" solutions that will not scale and are unsafe.
In software these Jugaad solutions slowly but surely increase technical debt. One day when the architecture reaches the inevitable big ball of mud, developers will throw up their hands and say, until we do a complete re-write we can't add more features or fix some of the bugs.
When I talk about this to developers, they kind of shrug their shoulders "What other way is there." They know no better approach. Before we go further, think about it, is there a better way to maintain code? If you do know another way, are you using it? Do you make sure every programmer in the organization is using it?
So here is my suggestion. You need to follow the Boy Scout Rule. "Always check a module in cleaner than when you checked it out." This sounds like a good thing to do. But the Boy Scout Rule neatly skips over the hard question. How do I do this? How do I make sure it is better?
The answer to this hard question is simple. Whenever you make changes to an existing code base you have to first understand how the relevant portion of the existing system works. Then make the changes in such a way that they extend and improve the design. (How do you understand an existing system? How do you identify what is relevant? - more blog posts, coming shortly :-) ). Once you feel you have understood the system, the critical step is verifying that you actually have understood the system. To do this you first make a prediction. What will be result of making some change in the system.
Then make the change. If your prediction was perfect, you have understood the system and can make a "clean change". If it is wrong, roll back the change. Spend more time understanding the system, repeat till your predictions are perfect. Then make the required changes keeping the Boy Scout Rule in mind.
So the suggestion to avoid the slippery slope of constantly deteriorating code and customers getting disillusioned with you, teach all your programmer how to avoid the drunkard's walk.
The "Know" techniques in PowerBoost teach you in detail how to avoid the drunkards walk.
Techniques like these are part of the PowerBoost Framework.