December 17, 2013 at 10:08How important it is to write good code.
I have to read a lot of code. This is open source, and all sorts of frameworks, and enterprise application code. It is about the latter that I would like to talk today.
Most enterprise application code sucks. Applications are buggy and slow, they are difficult to test, constantly problems with deployment and updating. It does not seem to surprise anyone.
But the people who wrote the crap code surprise. These people, with considerable experience, know several languages, read many books, know OOP, SOLID, refactoring, patterns and other obscure words. That is, about the same as many of you reading this post.
In 1969, an experiment was conducted. During the experiment, two identical cars were left in two places - in a prosperous campus and in a disadvantaged area of a large city. It is not surprising that in a dysfunctional place the car stood for only a couple of days and was gutted, while in a safe place the car stood for an untouched week. But as soon as the glass was broken in the surviving car, the inhabitants of this most prosperous town took it apart for details in a few hours and turned it upside down.
Later, scientists called this phenomenon "Theory of broken windows." According to the theory, any manifestation of disorder or violation of norms provokes people to forget about the rules as well. The theory received several experimental confirmations and can be considered quite reliable.
There is also the opposite effect. Maintaining order leads others to maintain order.
In enterprise development, pressing deadlines and uncertainties of requirements is so high that it seems to do “fast and dirty” - a much better option than doing it right. Instantly, the “quick and dirty” approach begins to spread throughout the application, both by clipboard inheritance (aka copy-paste), and due to the effect of broken windows.
Another factor affecting the quality of the code is the complexity and imperfection of the platforms and frameworks used in development. Because of this, hacks and ridiculous workarounds often appear in the code. Over time, it begins to seem that these hacks are good code. Even when framework problems are fixed, people continue to use hacks. By the way, these hacks can eventually get on the Internet through forums, blogs or pastebin and spread far beyond the limits of one application.
You can say that the quality of the code does not affect the quality of the application. Alas, how it affects. Programmers make mistakes. The worse the code, the more difficult it is to find and fix these errors so as not to create new ones. Pressing the timing and complexity, most likely, will not allow you to write a good code and another hack will appear.
In open source and product development, this is less common. There they monitor more quality and less pressing deadlines.
Often programmers forget that program code is written primarily for people. Even if you write the program alone, then looking at it after a month, you will not remember why you wrote this or that piece of code and what it is responsible for.
Good code should, first of all, express intentions very clearly. Unfortunately, the “fast and dirty” development methods hit primarily in terms of code comprehensibility. Improving the code deliberately delayed until better times when there will be a pause to refactor. Those best times never come, and the code begins to read and modify immediately after getting into source control.
Even if you are completely satisfied with your code (in most cases, programmers are happy with your code), then think about how another person will read your code (in most cases, programmers are unhappy with someone else's code).
The only way to achieve high productivity and efficiency is to write good code right away. The only tool to improve the quality of the code is you yourself. If you don’t always want to make good code, then neither tests nor static analysis tools will help you. Even a review of other programmers will not help. The code can always be made so confusing that it will not be possible to find an error while reading, while pretending that the code is very important and no one will rewrite it.
First of all, you need to think about structure and naming. Code with encrypted identifiers and obscure execution flow is likely to contain errors. Do not allow such code, it is much cheaper than fixing errors.
Clearly express your intentions in your code, minimize non-obvious implicit aspects. Do not strive to make the code as concise as possible; strive to make it as clear as possible.
If you have to edit the code, then do not create hacks. Spend some time, write normally. Save on support. If the code is really bad, it was made “quickly and dirty” and overgrown with hacks, then just throw it out and rewrite it. Just do not try to rewrite everything. Consider productivity: a programmer writes 40-60 debugged lines of code per day at a normal pace and 120-200 at an accelerated rate (high concentration, clear goal, it’s clear what to do).
If you yourself write “quickly and dirtyly”, for example, a prototype to clarify the requirements, then throw out the code and rewrite it normally right after your code does its job.
If you copied part of the code from another place or, God forbid, from the Internet, then figure out how it works before uploading changes to source control. Do not use code snippets that are incomprehensible to you at all.
Always keep your code clean and tidy, use tools that help you do this. You will not do this - the code will very quickly turn into garbage. Collect statistics on the density of problems in the code, this will help you better understand how to write good code.
Reread your code. Refactor constantly while writing. Remember that “later” refactoring never occurs.
Think about what code you want to write before you write it. Writing code is such an absorbing process that there is no time to think about quality. The state of flow is a state of freedom of expression. You need to limit self-expression in advance so that the code is good.
Everyone is familiar with the error cost curve: The
error found and eliminated at the coding stage is 10 times cheaper than the error found during testing and 100 times cheaper than the error found in production. There are real examples of errors in history, the correction of which cost tens of thousands of dollars.
Therefore, it is very important to eliminate errors at the development stage, and by the efforts of the developers themselves.
Do not confuse good and perfect code. There is no perfect code, it makes no sense to engage in endless improvement in the pursuit of ideal. Good code is code that is readable, understandable, solves a problem, properly structured, and contains no errors. Writing good code is not just your goal, it is your responsibility.
Most enterprise application code sucks. Applications are buggy and slow, they are difficult to test, constantly problems with deployment and updating. It does not seem to surprise anyone.
But the people who wrote the crap code surprise. These people, with considerable experience, know several languages, read many books, know OOP, SOLID, refactoring, patterns and other obscure words. That is, about the same as many of you reading this post.
Theory of Broken Windows
In 1969, an experiment was conducted. During the experiment, two identical cars were left in two places - in a prosperous campus and in a disadvantaged area of a large city. It is not surprising that in a dysfunctional place the car stood for only a couple of days and was gutted, while in a safe place the car stood for an untouched week. But as soon as the glass was broken in the surviving car, the inhabitants of this most prosperous town took it apart for details in a few hours and turned it upside down.
Later, scientists called this phenomenon "Theory of broken windows." According to the theory, any manifestation of disorder or violation of norms provokes people to forget about the rules as well. The theory received several experimental confirmations and can be considered quite reliable.
There is also the opposite effect. Maintaining order leads others to maintain order.
How does this affect the code?
In enterprise development, pressing deadlines and uncertainties of requirements is so high that it seems to do “fast and dirty” - a much better option than doing it right. Instantly, the “quick and dirty” approach begins to spread throughout the application, both by clipboard inheritance (aka copy-paste), and due to the effect of broken windows.
Another factor affecting the quality of the code is the complexity and imperfection of the platforms and frameworks used in development. Because of this, hacks and ridiculous workarounds often appear in the code. Over time, it begins to seem that these hacks are good code. Even when framework problems are fixed, people continue to use hacks. By the way, these hacks can eventually get on the Internet through forums, blogs or pastebin and spread far beyond the limits of one application.
You can say that the quality of the code does not affect the quality of the application. Alas, how it affects. Programmers make mistakes. The worse the code, the more difficult it is to find and fix these errors so as not to create new ones. Pressing the timing and complexity, most likely, will not allow you to write a good code and another hack will appear.
In open source and product development, this is less common. There they monitor more quality and less pressing deadlines.
Code is written for people
Often programmers forget that program code is written primarily for people. Even if you write the program alone, then looking at it after a month, you will not remember why you wrote this or that piece of code and what it is responsible for.
Good code should, first of all, express intentions very clearly. Unfortunately, the “fast and dirty” development methods hit primarily in terms of code comprehensibility. Improving the code deliberately delayed until better times when there will be a pause to refactor. Those best times never come, and the code begins to read and modify immediately after getting into source control.
Even if you are completely satisfied with your code (in most cases, programmers are happy with your code), then think about how another person will read your code (in most cases, programmers are unhappy with someone else's code).
Commitment to quality
The only way to achieve high productivity and efficiency is to write good code right away. The only tool to improve the quality of the code is you yourself. If you don’t always want to make good code, then neither tests nor static analysis tools will help you. Even a review of other programmers will not help. The code can always be made so confusing that it will not be possible to find an error while reading, while pretending that the code is very important and no one will rewrite it.
First of all, you need to think about structure and naming. Code with encrypted identifiers and obscure execution flow is likely to contain errors. Do not allow such code, it is much cheaper than fixing errors.
Clearly express your intentions in your code, minimize non-obvious implicit aspects. Do not strive to make the code as concise as possible; strive to make it as clear as possible.
If you have to edit the code, then do not create hacks. Spend some time, write normally. Save on support. If the code is really bad, it was made “quickly and dirty” and overgrown with hacks, then just throw it out and rewrite it. Just do not try to rewrite everything. Consider productivity: a programmer writes 40-60 debugged lines of code per day at a normal pace and 120-200 at an accelerated rate (high concentration, clear goal, it’s clear what to do).
If you yourself write “quickly and dirtyly”, for example, a prototype to clarify the requirements, then throw out the code and rewrite it normally right after your code does its job.
If you copied part of the code from another place or, God forbid, from the Internet, then figure out how it works before uploading changes to source control. Do not use code snippets that are incomprehensible to you at all.
Always keep your code clean and tidy, use tools that help you do this. You will not do this - the code will very quickly turn into garbage. Collect statistics on the density of problems in the code, this will help you better understand how to write good code.
Reread your code. Refactor constantly while writing. Remember that “later” refactoring never occurs.
Think about what code you want to write before you write it. Writing code is such an absorbing process that there is no time to think about quality. The state of flow is a state of freedom of expression. You need to limit self-expression in advance so that the code is good.
Code Quality Economics
Everyone is familiar with the error cost curve: The
error found and eliminated at the coding stage is 10 times cheaper than the error found during testing and 100 times cheaper than the error found in production. There are real examples of errors in history, the correction of which cost tens of thousands of dollars.
Therefore, it is very important to eliminate errors at the development stage, and by the efforts of the developers themselves.
In the end
Do not confuse good and perfect code. There is no perfect code, it makes no sense to engage in endless improvement in the pursuit of ideal. Good code is code that is readable, understandable, solves a problem, properly structured, and contains no errors. Writing good code is not just your goal, it is your responsibility.