The Value System
Clean Code developers have a value system. It consists of the values, which are described below:
- Evolvability
- Correctness
- Production Efficiency
- Reflection
Evolvability
We want to start this chapter using a provoking assumption:
There is no software-maintenance!Maintenance is a proactive process. In a manufacturing plant components will be exchanged before they break. They will be exchanged to ensure the reliability – it is known from experience that reliability can turn into a vulnerable state, if operation is continued without exchanging components. In worst case the whole plant can come to standstill. Every car-owner knows that the oil needs to be exchanged periodically – this is not because the oil will be exhausted, but it's known by the manufacturers experience that the engine can be prevented from damage, if the oil gets exchanged betimes.
All those things do not exist in software. Software is as it is – usually it contains mistakes. Also those mistakes are as they are. One can't do anything to improve the state of the software. Of course, there are proactive practices during operation. For instance, those practices can be periodically checking size of log-files and databases and leaking memory. But the software itself can't be maintained. Any kind of changing or extending the software happens to eliminate mistakes or to implement new requirements.
To make changes possible software needs to have a good inner structure, which benefits those changes. This is what we call evolvability. Usually, software gets utilized over a long period of time – usually much longer then intended. During this time the general requirements might change or new features must be added. Ideally, the implementation of a new feature has a fixed price, which is independent of when the implementation will be done.
In practice, the price of a feature increases the later the implementation is done. In the beginning a feature is well-priced, but in the end it is almost impossible to add new features, because nobody is able to look through. In consequence the software gets ditched and will be rewritten. Until this point is reached the costs of development increase exponentially. The bad things with exponential growth are two things: First, one can hardly recognize that the costs are increasing, because increasing is moderate. On the other hand, when one will notice increasing costs it is almost too late to go against, because the costs will increase too fast.
The easier a software can be adapted to changing requirements, the higher is the evolvability. But: evolvability can't be added subsequently – it must be taken into account from the beginning. The software must be designed for evolvability.
For an example: Classes shall have a single responsibility. If a class is responsible for more than one thing, it is harder to overlook – and this hinders from making changes, because changes require a deep understanding of the code, which needs to be changed. Furthermore, the coupling between classes’ increases – abruptly everything is linked up. To prevent this, it is important to assure that function units have clear responsibilities and it's necessary to keep an eye on the coupling. If there are a couple of classes in a software system, which are responsible for several things, it is very hard to get rid of this problem afterwards. The coupling might be too tight to rip out single function units. It is very costly to implement new features in such a system. If it is not started early enough to solve those problems the situation is worsening. At a specific point it will be almost impossible to add new features – this is the worst case scenario.
We think it shall not come so far. Considering evolvability from the beginning, software can be developed over long periods of time. The cost per feature will increase slightly, but not exponentially!
Correctness
From a functional point of view software must be accurate. A book-keeping application must book the accountings accurately, a spreadsheet-application must calculate accurately and also the non functional requirements must be fulfilled. The program must act with consideration on resources like memory, processor-time, disk space and it must comply with defined response times. Not before all requirements are fulfilled, the software is accurate.
Indeed, nobody will contradict that software must be accurate. But what are we doing to get accurate software – that’s the question. In our opinion it is not enough to give a new software release to the test-department, which is responsible for finding errors. We believe, accuracy must be taken into account during the development – developers must deal with the question of accuracy, as well. In order to do this they need to know about the requirements – and in most cases there is a lack of well defined requirements. Developers are getting instructed to implement a feature without being briefed about the acceptance criterion for the feature. Just to be clear: we don't want to pass the buck to someone else being outside of the development department, because developers are responsible to ask for the requirements, instead of taking a look into the crystal-ball.
In comparison to the car-manufacturing software development comes off badly. A car consists of many components, whose accuracy can be approved and verified separately. Just imagine, you had to monitor an engine by sitting on the car's hood, holding a checking-device in your hand and the car is driving with a speed of 200 km/h on the Autobahn. Sounds weird, right? A lot of times a debugger gets utilized in the same way – we think this is wrong.
Production Efficiency
In the end development time and costs are playing a big role – and the costs will be much higher, if the software-development lifecycle is not efficient. It starts with manual work-steps, which will not be automated and it ends up with high error-rates, which require touching the software again and again. At least production efficiency means that software can be developed over years or decades, instead of beginning from the scratch, again. Concurrently, a high production efficiency reduces the vulnerability to mistakes.
The production efficiency as a value is an important indicator to put other values into a measured relation. Someone who invests unlimited effort into accuracy is also doing something wrong.
Reflection
There is no advancement without practicing retrospection. Only those who reflecting, how a problem was solved can determine whether the chosen way was easy or hard – learning is based on reflection. In a pretty young area of science like the information technology, it is very important considering new findings. Reflection is necessary – on all levels. Starting with reflection regarding implementation during pair-programming, the daily reflecting of the team, the reflection at the end of each iteration, to the point of the reflection of the whole industry sector regarding their acting. There is no advancement without reflection.
Principles and practices¶
The value system guides clean code developers in their daily work. It does not provide solutions for specific problems, but it defines a framework for solutions. The four values are too abstract for a concrete realization – that's why we have assembled some modules. Each module covers at least one of these values. These modules fall into two categories: principles and practices.
Principles
The clean code developer principles are the basic regularities to structure software. They are either orthogonal to other conditions or they are of overriding importance. Code shall always be in accord with a maximum number of principles. Of course, they are not as mighty like the law of nature, which nobody can counteract. But anyhow, in reference to law of nature those principles have the same fundamentality. Where a principle is not adhered a negative effect will not occur immediately, but in the short or medium term infringements will not remain without pain. The pain is noticeable in higher effort in the understanding of code or complications by adding new features. The pain gets ultimate when the software is no longer evolvable. It can be seen in the code, whether a principle had been followed or not.
Practices
Practices are techniques and methods which are constantly used. They describe what clean code developers are doing practically. The motto of the practices is: “Do it always in the same way. Do it every day.” Practices are concrete advises, which might require special tools. It can't be seen in the code, whether a practice had been followed or not.