Introduction: The worst project you have ever seen, how long did it take to finish? Six months? One year? The weird project introduced today was not only horrible at the beginning, it also lasted for more than 12 years until the project leader was arrested and thrown into prison.
How bad is it? Tell you with the following shocking data:
A total of more than 6 million lines of C++ code,
a total of more than 50,000 classes,
limited by the version of the compiler, the C++ syntax used is all outdated and can only be deployed
on a certain (not maintained) operating system.
Database software based on CORBA From a company that went bankrupt for a long time
. Several superimposed layers make up the user interface, and none of these layers are maintained by the original author.
Running a user interface requires 40-50 sub-threads to be started
. It requires 48 on 32 parallel machines. Compilation in hours.
Without the use of runtime library dynamic link technology, an executable program is as large as hundreds of megabytes. It takes about 15 minutes to start up. It
usually crashes within 30 seconds to 30 minutes.
"Hell-level" bad projects you have never seen
Ten years ago, in 2008, the technology blog projectfailures broke the news. In those years, the blogger had been employed by a large French technology company and participated in a software project commissioned by a government agency. The position was a consultant. There, he witnessed the utmost stupidity and madness and the terrible role they played in software development.
Ten years later, this hellish project was turned over again, and there was a stir again, and the projectfailures blog even published a review on it.
In the article, he wrote: "This is no longer just a lack of professional competence. The ruthless trampling of human dignity in this project has become so serious that sometimes it makes me feel like I am in prison."
What? It's just writing some code, besides losing your hair, will you even get in with your life! ? Why is this project so scary!
What's the situation with this project?
Around 1996, a French government agency asked a company to develop a piece of software. In general, this thing should not be too complicated, but there are some unusual small problems that need to be solved.
Party A paid several million euros in advance, and the planned construction period was about 2 to 3 years. So the company hired a few programmers and started to work. With the funds in place, the company began to recruit people frantically, doubling the team every three months or so.
As a result, 7 years later, this project has not yet taken shape. The fines for delays amount to several thousand Euros every day. So the management decided to streamline the team and reduce project expenses-the specific method is to open all the people who work, and also recruit some novices who have no experience in software development to work.
Ten years after the start of the project, the entire project has been deep in the quagmire of disasters, and it is entirely composed of pure chaos. So the middle-level managers of the project finally decided to recruit some people with software engineering development experience to drag the mess out of hell.
After another two years, the project is still lingering. The company used to send Party A a "design change" bill with increasing amounts to compensate for the daily penalty for delays in construction. This is all in 2008!
How could this project be so bad?
- The code quality is terrible
In terms of language selection, no one dares to say that C++ is a simple and easy to understand language. In fact, C++ is probably the worst programming language in terms of simplicity. You know, it is so complicated that even its creator, Bjarne Stroustrup, dare not say that he fully masters the language.
Of course, this cannot be entirely blamed on the development team. You know, at that time, there was still a big market for thinking mazes like C++ with endless complexity. Many young people who wish to become super programmers are eager for this super-sounding language. In fact, most of these poor children were abused by C++ in the end. How many beautiful youths were spent repeatedly debugging a large section of obscure and difficult code, and spent exploring why this program would have no reason. The inexplicable collapse happened.
People with normal brains have turned to other languages and other projects. You know, life is short
However, it seems that this company has not jumped out of this circle, or plunged into the C++ pit.
Taking a step back, no matter what programming language you are using, maintaining a huge code base is not an easy task in itself-and the code base of this project is actually more than 6 million lines.
So, what is the concept of more than 6 million lines of code?
In contrast to the Linux 3.13 kernel code, except for the kernel driver and architecture, the source code in kernel/ is only about 130,000 lines; another example is the famous editor Emacs, which has too many functions and is too large. , It is often complained as "lack of an operating system with a good editor", but even so, its total source code size is only 1.59 million lines.
Even if you are very good, with ten lines at a glance, you probably have to spend 7 days awake in front of the monitor to get through all 6 million lines of code.
So we can imagine how many programmers are driving crazy to maintain such a large code base. Take a look at the following two examples, I think if I were a programmer, I would be crazy first.
Once, a programmer in the project was asked to fix a bug that "right-clicking the interface will cause the entire application to freeze". After several days of careful inspection and exhausting countless patience, he discovered that the right-click response event actually worked. It's normal, but this "normal" process requires the program to take 45 minutes to dynamically generate each menu item from a huge (static!) content library, and then display the menu. If you click the right button again at this time, sorry, let’s take another 45 minutes to regenerate the menu item...
On another occasion, the user reported a "Failed to load data from CD-ROM" bug. The programmers spent several weeks testing and analyzing the code, but in the end they directly marked the issue as "resolved". Because they found that the function of loading data from CD-ROM is actually good. The problem is that it takes about 7 days to read 700MB of data.
It really tests patience.
Version control is all messed up
Incredibly, the team worked for several years without a version control tool at all, until a guy in the team with a clear mind suddenly thought of using a version control tool to manage code. The results of the initial attempts did not satisfy everyone, so the team switched to another version control system. It will last for a year or two, and then this version control system somehow got caught up and lost all the records of previous changes.
The version control tool selected for this project is a scourge with a graphical user interface, a pile of digital electronic waste directly imported from Sweden. They had to arrange 4 people to form a "version control team" who was responsible for maintaining the normal operation of the version control system full-time. This directly leads to the following situations:
1) To check out files from the version control system for the first time, you need to make an appointment with the version control team. Generally speaking, you can get authorization after a week.
2) If you want to modify the file, you must go through the approval of the middle management. You need to list the files that need to be modified in advance, tell your manager the list, and then report to the version control team to apply. The latter will give you feedback in about two days.
3) Each modification of a file will trigger a branch, which means you have to merge all the modifications received by this file yourself. You may think that with so many files in the project, the chances of two people changing to the same file should be small. However, in fact, most of the changes are concentrated in the same about 100 files, so every merge Guaranteed to make you unhappy.
4) Before submitting the modification (checking in the file), you will also experience a mental torture: the code you are going to submit will be handed over to a so-called automatic bug detection program for review, and after it is passed, it will be shown to the middle management. To submit successfully. Needless to say, this is of no avail. Bugs are still popping up like bamboo shoots after a rain. It is much faster than everyone can eliminate bugs. What's more, after analyzing the number of bugs found, it is found that the number of new bugs brought by this "defect correction" method is twice the number of bugs it fixes...
5) Version management is too simple. The old version is 1, today’s version is 2, and the later version is 3. No one can know exactly which version is sent to the customer.
Sometimes, the management will set a so-called official delivery time, and this time schedule has nothing to do with any kind of work plan in the team. When the scheduled delivery date arrived, the customer actually received a blank CD with an installation tutorial...because no one could build an executable program for several weeks. As a result, the customer found that he had received a blank CD, and then formally complained, and then received an old version of the program CD as a response. The reason why the customer finds that the program is an old version is because the "About" page of the software still has the same date as last year's version...
The team composition is even more inexplicable
The team is filled with such a large group of people without any software engineering experience. If there are not many bugs in this software, it would be really unreasonable, right?
Remember as mentioned above, the management once decided to streamline the team.
It stands to reason that any manager with a normal mind will find that for such a pure software engineering project, personnel expenditure must be the most important expenditure. However, this discovery did not prevent the management from opening all programmers with a little bit of experience and replacing them with rookies with much lower salary requirements. In contrast, all the managers’ jobs were held firmly, and they were not affected at all.
It seems that books like "Teach Yourself C++ in 21 Days" must be regarded as classics by them.
No, you are too naive, and "Learn C++ in 3 Days".
What has become of this team? Of the 55 people, there are only 20 programmers, and the remaining 35 are managers. Yes, you read that right, this lineup is really luxurious, with 1.75 managers for each programmer!
Few managers have experience in software engineering. At that time, it happened that SCO took the Unix copyright to sue Linux users. Even if the whole thing was just a bluff, it was still terrible to many people-if one day suddenly you have to Paying for free software, how good is that?
Technical knowledge is also quite lacking. It's been 200x years. Few people in this group have any knowledge of the Internet. The few who are familiar with the Internet are just watching small movies on the Internet. If you mention what you have read on the Internet, you will only get other people's snickers.
The abnormal direction of the administrative management model
The above ridiculous situation may make people laugh, but if you know that the group of French guys in the management are like German devils in Auschwitz concentration camp, then you probably won’t laugh. . Let’s take a look at these morbid bureaucratic regulations:
1) Late arrivals are forbidden, everyone must be on duty before 9 am. One day, the personnel manager stood by the door of the company early and fired all those who came to the company after 9:01 on the spot. Programmers, managers, and sales were not immune.
2) The coffee machine is cut off from time to time, which lasts for several days. The reason, of course, is that people who go to drink coffee are not as efficient as people who sit down and type code. Not only that, whenever a leader comes to inspect the development department, the coffee machine will be turned off, so that the leader will not see that someone is "not working".
3) The level of dirty and messy toilets can be said to be the only disgusting and scary one in the industry. I think this is due to the management's "efficient" policy to avoid everyone spending time on paid toilets.
You may have to ask, why do people come to work in such a perverted company? The most important thing is that during that time, the French domestic economy was struggling on the brink of collapse (until now, France has not completely gotten out of this quagmire). It is not easy to find a job that is enough to make a living, and the working conditions are harsh. .
The inevitable ending
As netizens commented, the whole project is stuck in an endless chain: lack of experience leads to inefficiency, inefficiency leads to too much overhead, cost savings and layoffs of experienced people, further reducing efficiency.
So, why does management still sit back and watch this situation worsen? In the final analysis, it is still worry about failure. If you cut down the project, it means that the project has failed, and the person with leadership responsibility is you. If this project is still lingering, then after you are promoted and transferred, the mess will naturally be cleaned up by your successor.
In the end, the company leader in charge of this project was arrested for misappropriating funds and other reasons, and went to jail. This project, which had been struggling in the flames of hell for more than ten years, was finally terminated.
As a witness of the whole thing, the blogger of projectfailures advises young people who have just entered the world of programming:
1) Cherish life, don't toss yourself with C++;
2) I would rather pick up some small projects that are not so stable, but can give full play to their strengths, and don't covet to take part in something that looks very high-sounding project;
3) Object-oriented Database is not a good thing;
4) CORBA should die in pain;
5) Those stupid product managers, please refer to the previous one.
Finally, if you feel that your current job is very awful and irritating, I hope this project can make you a little bit happy.
