Change

Way back a long time ago, I wrote some code to use a neural network to deal with the Kinematics of a robot arm in 2 dimensions. In nearly 20 years, no-one has ever needed to change a single line of that code.

However, that is entirely because it was my final year college project, and it has not seen the light of day since I showed it to the professors all those years ago.

If people use your code, then the requirements will change. And you will have to change the code. This is as certain as any physical law, and as true as any mathematical proof. It is unavoidable.



And if you don't make a very concerted effort, changes absolutely will degrade the code.

This brings us to the wretched conclusion that the most important code is often in the worst condition.

The very fact that the code has gone through many changes suggests that it is important. It must be in use. If it were not in use, no body would request changes. All those changes tend to degrade the code.

Imagine repairing a house that is well lived in by a large and active family. Each repair, unless done with great care and skill will make the house look just that little bit shabbier. And as things look worse, it's easier to make a quick and nasty repair. There's even a name for this - "The broken window effect".

So over they years, a huge amount of  research, development and books and websites have dealt with trying to manage change. Trying to isolate parts of the code that might change, and to isolate the impact on the rest of the code.

One fundamental things remains true, across all the computer languages, and across all the methodologies, and practices. If your code is hard to understand, it will be hard to change. If it is hard to change, bugs will be introduced.