If you didn’t see my frequent checkins to projects as usual, that’s because I switch between coding mode and writing mode every weekday, and focus on writing my thesis in the weekends. I enjoy my first academic writing opportunity, and it’s a process of learning. I am improving my writing skills little by little. Thanks Venkat for his patience and precious advice. So I am glad to extract three sections in my thesis draft, and share these with you. Yes, code quality always be a crucial topic in software development.
People won’t use products of low quality, for example, no one prefers a car with poor quality tires as that might put drivers in danger. Similarly, an unreliable application will not keep the users satisfied. Code quality is one of the most crucial elements that lead to high quality software.
Importance of Code Quality
Even though code quality is subjective, it is a measure of how well the code is designed and implemented. Good quality of code has many advantages:
- easier to read and understand
- has low cost and risk of maintenance
- helps improve the software design
- easy to change
In the perspective of software project management, quality, time, and cost are three central factors that determine success of a software project. Among these elements, quality is the only one that “cannot be changed on the spot by management fiat.” 15 Just like the Therac-25 accident 22, failure of the Ariane 5 23, and round-off error of the Patriot missile 24, people already learned from experiences that the consequences of poor quality code can be terrible, and are sometimes impossible to undo.
It is admitted that code quality is important, however, in reality, we have to sometimes compromise. It’s important for us to be sensitive to these debts we acquired during product development.
Technical debts are acquired from shortcuts that are made during the planning and execution of software development 16. Deferring refactoring of a piece of code with low quality leads to some serious technical debts.
Usually, under the pressure of deadline, developers write "quick and dirty” 20 code. Messy code soon turns into technical debts. As soon as a technical debt is owed, interests will incur. As a result, developers need to pay them off with extra time and efforts in the future. As the software evolves, when too many things depend on a piece of bad code, it’s really hard to fix. So, it’s really necessary to pay the technical debt as soon as possible. First Law of Programming also tells developers that "lowering quality lengthens development time.” 21
Even worse, if poor quality code is not amended, the tendency by developers to break code will grow. This tendency is confirmed by the broken window theory 17.
Broken Window Theory
Broken window theory is a criminological theory introduced by social scientists James Q. Wilson and George L. Kelling 17. They used a vivid example to prove that a broken unrepaired window in a building could arouse the feeling of being abandoned. If nobody in the building cares about this broken window, gradually, more and more windows get broken. Consequently, this type of disorder leads to additional crimes and anti-social behaviors.
Apply broken window theory in software development, a single piece of bad code could redirect development to a bad circle, and then poor code will multiply. Eventually, poor code could erode the architecture of the software, resulting in a design rot. Once code quality starts going down, the neglect accelerates the rot faster than any other factors 19, and the corroding project rapidly goes out of control.
Hence, developers should really care about their code quality, and be conscious with potential problems in their source code. The potential problems in code are named Bad Smells in Code, introduced by Kent Beck and Martin Fowler 18. In daily life, developers usually call it code smell or smelly code for short.
I will discuss the code smells in the next section, and will publish them after the thesis is defensed.
15 Spinellis, D. Code Quality: The Open Source Perspective. (2006). Indianapolis, IN: Addison-Wesley Professional
16 Technical Debt. Retrieved from http://c2.com/cgi/wiki?TechnicalDebt
17 Wilson, J. Q., & Kelling, G. L. (1982). BROKEN WINDOWS: The police and neighborhood safety. The Atlantic Monthly. Retrieved from http://www.manhattan-institute.org/pdf/atlantic_monthly-brokenwindows.pdf
18 Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code. Indianapolis, IN: Addison-Wesley Professional.
19 Hunt, A., & Thomas, D. (2000). The Pragmatic Programmer. Indianapolis, IN: Addison-Wesley.
20 Fowler, M. (2009). Technical Debt. Retrieved from http://martinfowler.com/bliki/TechnicalDebt.html
21 First Law of Programming. Retrieved from http://c2.com/cgi/wiki?FirstLawOfProgramming
22 Leveson, N. G., & Turner, C. S. (1993). An investigation of the Therac-25 accidents. Computer, 26(7), 18-41. IEEE Computer Society. doi:10.1109/MC.1993.274940
23 Dowson, M. (1997). The Ariane 5 software failure. ACM SIGSOFT Software Engineering Notes, 22(2), 84. doi:10.1145/251880.251992
24 Skeel, R. (1992). Roundoff error and the Patriot missile. SIAM News, 0-1.