I read the first 2 chapters of this book almost 16 months ago and I did not quite understand the significance of clean code back then. This week I decided to listen to the video version of clean code (available in SafariBooksOnline). The video version made it much easier to understand and I had a few good laughs.
In the first chapter Uncle Bob explains why clean code is important. He tells us the story of Sword Inc, a software company that failed because they produced bad code. When code is not clean the productivity of the development team decreases as time increases. The reason for this loss of productivity is that the developers build a mess as they develop the product. And the software product eventually fails becuase when the management demands new features within a certain deadline, the development team is not able to deliver because they just can’t.
The management tries all sorts of things (like increasing developers) to improve productivity, but nothing works. According to Brook’s law, adding more man power to a late project makes it later.
Finally the management turns to the developers for a solution. The developers solution is to redisgn the entire system! Management does not want to do this since it is expensive. The mangement however, after some time, decides to do it. But even this would not solve the problem. Eventually the company would loose customers because when they replace the new product for the old (more feature rich) product, customers leave for better products.
The only way to solve this problem is to stop running away from it and clean the mess.
So what is bad code? You know that a software systems contains bad code if it is rigid, is fragile, lacks seperability and is opaque. Uncle Bob goes on to explain that bad code is the fault of developers not management, not anybody else.
The second chapter is all about making your code more readable with the help of better naming strategies.
I can relate to this chapter and the Sword Inc company failure. Last semester I wrote software for a class project. Since we only had a limited amount of time and a bunch of requirements to fulfill, I rushed through the development process. As a result of my rushing, the code lacks the properties of clean code. If I had to use the code again or implement a new requirement, I would be lost.
From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.
