Refactoring

I came into contact with the idea of refactoring long before I actually read the relevant literature. I was working for some months in a department which developed the software for information and entertainment systems in cars. Most of the software was programmed in C++ which was not too far away from the Java environment for which refactoring became a classical method. The colleagues talked about refactoring in the meetings and I could actually see what they were doing to their code, and also do it myself. Refactoring simply means to re-work source code, to improve its design. Being able to "grow" for a while in an environment where refactoring was practiced I came back to the microcontroller development. There I was faced with a heap of source code which looked like a bowl of spaghetti. Stuff which was just hard to comprehend and even harder to perform any maintenance on it. It was at hand that we urgently needed some refactoring. However, the whole programming environment was different and I could only apply some of the methods we used in the C++ programming and had to develop some new ones, which were suitable for the microcontroller software.

Only many months after establishing a modified way of refactoring for microcontroller C, I got a hold of Martin Fowler's book on refactoring. I read it more for curiosity, because after two years of work we had our refactoring established and it worked with good success and therefore I did not care too much if I was in agreement with the ideas of this book. But amazingly I discovered that I came to almost the same conclusions and principles and even to a large degree applied very similar methods of refactoring. Martin Fowler described his methods for an environment of object oriented programmimg in Java and therefore many of these methods did not apply to us, but there were a number which could be transfered to simple C programming. We did this instinctively and on top of it we developed some additinal ones which especially match the C programming and our application of microcontrollers in safety critical systems. These methods and the principles we set up can be found in the sub-pages about principles and methods of refactoring.

Refactoring is sometimes also called perfective maintenance. It is a way of constantly improving software without changing its functionality. This is for example applied by the LINUX community. Since years they do maintenance on the code and constantly improve it without really changing the functionality and interfaces. But this way of doing things it is not much valued by managers in modern business. In the past years big software companies turned into share holding financial organisations with attached software department, with the sole purpose to raise the financial profit. Being forced by the rules of "time to market" software very often is produced like eggs in a chicken farm. I.e. the output (of new functionality) has to be as big as possible for as less costs as possible. However this approach most times does not really save costs, but shifts them to the customer, preferably without the customer noticing it. Runtime increases and stability suffers as a result of this philosophy. We all can feel that on our own skins, being users of some well know operating systems and office applications.

However these rules should not apply for those companies who have to provide software for safety critical or other highly reliable applications. For these companies perfective maintenance should not be a book with seven seals, but should be applied in every day product development.