Rakes that are not worth stepping on
From the translator: This is a translation of the article by Joel Spolsky. After 2 years, this article will be able to get car rights in the US, and after two more - and not only there. Yes, she is 14 years old (or rather, 14 years and 11 days), but she has not lost a single gram of actuality. I regularly see how programmers (and I myself, at times) break to step on this rake. The fact that I did not find its transfer to Habré may well indicate that I was looking bad. Please transfer errors in the LAN
UPD: It turns out the translation of Joel's articles, including this one, is also available in the paper “Joel on Programming”
Finally, the first public beta version of Netscape 6.0 comes out. Version 5.0 does not exist. The previous major release - version 4.0 - was released almost three years ago. Three years is an incredibly long time in the world of the Internet. All this time in Netscape, they sat and watched helplessly as their market share declined.
')
It's a little mean to criticize them for so long waiting between releases. They didn't do it on purpose , right?
Not true! That is exactly what they did. And with this they made the single biggest strategic mistake a software company could ever make.
They decided to rewrite the code from scratch.
Netscape was not the first company to make such a mistake. Borland made it when buying Arago, deciding to turn it into dBase for Windows - a project that took so much time that all the goodies went to Microsoft Access; and then they performed it again, rewriting Quattro Pro from scratch and hitting everyone with how little the program could do. Microsoft itself almost repeated the same mistake when trying to rewrite Word for Windows from scratch into a doomed project called Pyramid, which was minimized, thrown out and forgotten. Fortunately for Microsoft, the work on the old code did not stop, and they had something to release, so it all turned into a financial catastrophe, but not a strategic one.
We are programmers. And programmers in their hearts are architects, and the first thing they want to do when they get on to work is to bulldoze everything and do something big. We are not thrilled with the consistent improvements: tweak, fix.
There is an insidious reason why programmers always want to throw out all existing code and start writing again. They think the old code is a mess. And here is an interesting observation: most likely they are mistaken. The reason they think code is terrible is basically a fundamental programming law:
Reading the code is harder than writing it.
That is why it is so difficult to reuse the code. That's why everyone in the team has its own function for splitting a string into an array. They write their functions because it is easier and more fun to write their own function than to understand the work of the old one.
In confirmation of this axiom, one can ask practically any modern programmer about the code he is working on. “It's just a damn mess,” he will say. "All I want is to throw him to hell and start over."
Why mess?
“Well,” he says, “look at this function. She is two pages long! There is almost all unnecessary. Yes, I don’t even know why here is half of these API calls. ”
Before the release of the new spreadsheet manager for Windows from Borland, the press quoted Philip Kahn, the company's founder, into the holes of how much Quattro Pro would be cooler than Microsoft Excel since it was rewritten from scratch. Completely new code! As if the code is rusting.
The idea that the new code is better than the old one is clearly absurd. Old code was used . It is tested . Many bugs were found and they were fixed . And that's all right. The code does not produce bugs just wallowing on the hard disk. Just the opposite! Software is that old Dodge Dart, which is rusting just idle in the garage? Is this a teddy bear that looks bad if not made entirely from new material?
Let's go back to the two-page function. Yes, I know, this is a simple function to display a window, but it is overgrown with garbage and other junk, and no one knows why. Well, I'll tell you why: these are bug fixes. This piece fixes a bug that happened to Nancy when she tried to install everything on a machine without IE. This one is the bug that occurs when there is a shortage of memory. And this one - when the file is on a diskette, and the user pulled it out in the middle of everything. This LoadLibrary call is terrible, but thanks to it the code works on older versions of Windows 95.
There have been weeks of real-time use of the program before each of these bugs has been found. A programmer could take several days to reproduce and correct them. It often happens that a fix is ​​just one line of code, or maybe even a couple of characters, but a lot of time is invested in these two characters.
When you throw out the code and write it again, you throw away all this baggage of knowledge. All these fixed bugs. Years of work of programmers.
You throw out your advantage in the market. You give two or three years to your competitors, and this, believe me, is a lot of time in the context of software development.
This is a very dangerous situation when you have to release the old version of the code from year to year with an absolute lack of the possibility of strategic changes or reaction to market demands. And all due to the fact that the new product is not ready. It is like just closing a business for all this time.
This is the use of huge amounts of money to write code that already exists.
What is the way out of this? By all accounts, the Netscape code was really bad. Well, he could be bad, but, you know what? He even worked quite well on a wild amount of real computer systems.
When programmers say their code is a terrible mess (and they always say so), this usually means three types of problems.
The first is the problem of architecture. The code is not refactored. The code responsible for network connections suddenly throws its own dialog boxes from nowhere; this should be handled in the UI code. Such problems can be corrected one by one: careful refactoring and changing interfaces. This can be done by one programmer working carefully and implementing his changes entirely, without disturbing anyone. Even quite impressive architectural changes can be made without throwing out the code. In the Juno project, we once spent several months reworking the architecture: just moving everything around, clearing everything up, creating meaningful base classes and interfaces between modules. But we did it neatly and with the current code, we did not introduce new bugs and did not throw out the working code.
The second problem on which programmers consider their code a mess is inefficiency. Netscape was thought to have bad rendering code. But this affected only a small part of the project, which can be optimized or even rewritten. But do not rewrite everything. When optimizing for the speed of 1% of work gives 99% of the result.
And third, the code may just be incredibly disgusting. Once I was working on a project in which FuckedString data type was used seriously. In another project, we agreed to start the property names with "_", but later decided to move to a more standard "m_". Therefore, half of the functions began with "_" and half with "m_", and it was disgusting. Honestly, these are problems that can be solved by writing five-minute macros in Emacs, and not by rewriting from scratch.
It is important to remember that when you start writing from scratch there is no reason to believe that it will turn out better than it was the first time. First, most likely the team of programmers is no longer the one that worked on the first version, so there will not be “more experience”. Everything will end with the fact that all the old mistakes will be made, as well as some new ones, which were not in the original version.
The old do-to-throw mantra is very dangerous when applied to a large-scale commercial project. When experimenting with code, you can cut a function written two weeks ago in connection with finding a better algorithm. Everything is in order here. You can refactor a class to make it easier to use. Here, too, everything is in order. But throwing out the entire program is a dangerous mistake, and if Netscape were under the supervision of a company with experience in the software industry, they might not have shot themselves in the leg with such zeal.
UPD: It turns out the translation of Joel's articles, including this one, is also available in the paper “Joel on Programming”
Finally, the first public beta version of Netscape 6.0 comes out. Version 5.0 does not exist. The previous major release - version 4.0 - was released almost three years ago. Three years is an incredibly long time in the world of the Internet. All this time in Netscape, they sat and watched helplessly as their market share declined.
')
It's a little mean to criticize them for so long waiting between releases. They didn't do it on purpose , right?
Not true! That is exactly what they did. And with this they made the single biggest strategic mistake a software company could ever make.
They decided to rewrite the code from scratch.
Netscape was not the first company to make such a mistake. Borland made it when buying Arago, deciding to turn it into dBase for Windows - a project that took so much time that all the goodies went to Microsoft Access; and then they performed it again, rewriting Quattro Pro from scratch and hitting everyone with how little the program could do. Microsoft itself almost repeated the same mistake when trying to rewrite Word for Windows from scratch into a doomed project called Pyramid, which was minimized, thrown out and forgotten. Fortunately for Microsoft, the work on the old code did not stop, and they had something to release, so it all turned into a financial catastrophe, but not a strategic one.
We are programmers. And programmers in their hearts are architects, and the first thing they want to do when they get on to work is to bulldoze everything and do something big. We are not thrilled with the consistent improvements: tweak, fix.
There is an insidious reason why programmers always want to throw out all existing code and start writing again. They think the old code is a mess. And here is an interesting observation: most likely they are mistaken. The reason they think code is terrible is basically a fundamental programming law:
Reading the code is harder than writing it.
That is why it is so difficult to reuse the code. That's why everyone in the team has its own function for splitting a string into an array. They write their functions because it is easier and more fun to write their own function than to understand the work of the old one.
In confirmation of this axiom, one can ask practically any modern programmer about the code he is working on. “It's just a damn mess,” he will say. "All I want is to throw him to hell and start over."
Why mess?
“Well,” he says, “look at this function. She is two pages long! There is almost all unnecessary. Yes, I don’t even know why here is half of these API calls. ”
Before the release of the new spreadsheet manager for Windows from Borland, the press quoted Philip Kahn, the company's founder, into the holes of how much Quattro Pro would be cooler than Microsoft Excel since it was rewritten from scratch. Completely new code! As if the code is rusting.
The idea that the new code is better than the old one is clearly absurd. Old code was used . It is tested . Many bugs were found and they were fixed . And that's all right. The code does not produce bugs just wallowing on the hard disk. Just the opposite! Software is that old Dodge Dart, which is rusting just idle in the garage? Is this a teddy bear that looks bad if not made entirely from new material?
Let's go back to the two-page function. Yes, I know, this is a simple function to display a window, but it is overgrown with garbage and other junk, and no one knows why. Well, I'll tell you why: these are bug fixes. This piece fixes a bug that happened to Nancy when she tried to install everything on a machine without IE. This one is the bug that occurs when there is a shortage of memory. And this one - when the file is on a diskette, and the user pulled it out in the middle of everything. This LoadLibrary call is terrible, but thanks to it the code works on older versions of Windows 95.
There have been weeks of real-time use of the program before each of these bugs has been found. A programmer could take several days to reproduce and correct them. It often happens that a fix is ​​just one line of code, or maybe even a couple of characters, but a lot of time is invested in these two characters.
When you throw out the code and write it again, you throw away all this baggage of knowledge. All these fixed bugs. Years of work of programmers.
You throw out your advantage in the market. You give two or three years to your competitors, and this, believe me, is a lot of time in the context of software development.
This is a very dangerous situation when you have to release the old version of the code from year to year with an absolute lack of the possibility of strategic changes or reaction to market demands. And all due to the fact that the new product is not ready. It is like just closing a business for all this time.
This is the use of huge amounts of money to write code that already exists.
What is the way out of this? By all accounts, the Netscape code was really bad. Well, he could be bad, but, you know what? He even worked quite well on a wild amount of real computer systems.
When programmers say their code is a terrible mess (and they always say so), this usually means three types of problems.
The first is the problem of architecture. The code is not refactored. The code responsible for network connections suddenly throws its own dialog boxes from nowhere; this should be handled in the UI code. Such problems can be corrected one by one: careful refactoring and changing interfaces. This can be done by one programmer working carefully and implementing his changes entirely, without disturbing anyone. Even quite impressive architectural changes can be made without throwing out the code. In the Juno project, we once spent several months reworking the architecture: just moving everything around, clearing everything up, creating meaningful base classes and interfaces between modules. But we did it neatly and with the current code, we did not introduce new bugs and did not throw out the working code.
The second problem on which programmers consider their code a mess is inefficiency. Netscape was thought to have bad rendering code. But this affected only a small part of the project, which can be optimized or even rewritten. But do not rewrite everything. When optimizing for the speed of 1% of work gives 99% of the result.
And third, the code may just be incredibly disgusting. Once I was working on a project in which FuckedString data type was used seriously. In another project, we agreed to start the property names with "_", but later decided to move to a more standard "m_". Therefore, half of the functions began with "_" and half with "m_", and it was disgusting. Honestly, these are problems that can be solved by writing five-minute macros in Emacs, and not by rewriting from scratch.
It is important to remember that when you start writing from scratch there is no reason to believe that it will turn out better than it was the first time. First, most likely the team of programmers is no longer the one that worked on the first version, so there will not be “more experience”. Everything will end with the fact that all the old mistakes will be made, as well as some new ones, which were not in the original version.
The old do-to-throw mantra is very dangerous when applied to a large-scale commercial project. When experimenting with code, you can cut a function written two weeks ago in connection with finding a better algorithm. Everything is in order here. You can refactor a class to make it easier to use. Here, too, everything is in order. But throwing out the entire program is a dangerous mistake, and if Netscape were under the supervision of a company with experience in the software industry, they might not have shot themselves in the leg with such zeal.
Source: https://habr.com/ru/post/219651/
All Articles