Book – Code Simplicity

It is very short (less than 100 pages) but contains a lot of truth about software design in a very condensed way. At the end, it defines a list of laws and rules that any good software engineer or architect need to know and follow constantly to create really valuable and long-term software.

It starts with a comparison that I believe is very effective to underline how complex the software is:

Windows 2000 was 30 million lines of code, something like writing a book of 200 million of words – over five times the size of the Encyclopedia Britannica.

Everyone can easy agree with the following sentence:

The average computer program is so complex that no person could comprehend how all the code works in its entirely

The author believe that the software design can be defined as a science. Even if you don’t agree with him, the list of laws and rules presented in the books are still extremely helpful and important.

The most important foundational law of the book is:

The purpose of software is to help people

This fundamental law bring towards the three goals of a science of software:

To allow us to write software that is as helpful as possible

To allow our software to continue to be as helpful as possible

To design systems that can be created and maintained as easily as possible by their programmers, so that they can be – and continue to be – as helpful as possible

The book then define the Equation of Software Design that the author call the Primary Law of Software Design:

D = V / E

This equation should help to prioritise the work and can be summarised in this way:

The desirability of any change (D) is directly proportional to the value of the change (V) and inversely proportional to the effort involved in making the change (E)

that can be reduced to:

It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.

So, nearly all decisions in software design reduce entirely to measuring the future value of a change versus its effort of maintenance. The quality level of your design should be proportional to the length of future time in which your system will continue to help people.

Then, the book introduce the Law of change:

The longer your program exists, the more probable it is that any piece of it will have to change

explaining the typical mistakes that software designers make when attempting to cope with this law:

writing code that isn’t needed

not making the code easy to change

being too generic (Over-engineering)

Perfect easy of maintenance is impossible but it should be the ultimate goal.

Finally, the Law of Testing:

The degree to which you know how your software behaves is the degree to which you have accurately tested it