Inside a 12‑Year Software Nightmare: Lessons from a 6‑Million‑Line C++ Disaster

The story originates from a 2008 post on the projectfailures blog, where the author, a former consultant for a large French tech company, describes a government‑commissioned software project that spiraled into a twelve‑year disaster.

Project Background

In 1996 a French government agency contracted a company to develop a software system. The client prepaid several million euros and expected a 2–3 year delivery. The company hired programmers, repeatedly doubled the team size, and after seven years the project was still far from complete.

Why It Was So Bad

More than 6 million lines of C++ code across over 50 000 classes.

Code written with outdated C++ syntax limited to an unsupported operating system.

Reliance on CORBA and a bankrupt database vendor.

Multiple overlapping UI layers, none maintained by the original authors.

Running the UI required 40–50 threads.

Compiling the whole codebase on 32 machines took 48 hours.

The executable was several hundred megabytes because no dynamic linking was used.

Startup time was about 15 minutes, and the application crashed within 30 seconds to 30 minutes.

Code Quality Issues

The codebase was written in C++, a language notorious for complexity. Maintaining a six‑million‑line codebase proved nearly impossible; reading it all would take a programmer about a week of nonstop work. Bugs often required absurd amounts of time to reproduce, such as a right‑click menu that regenerated its entire structure in 45 minutes.

Version Control Chaos

The team operated without any version‑control system for years. When a tool was finally introduced, it was unreliable, causing lost history and requiring a dedicated four‑person “version‑control team.” Checking out files required a week‑long appointment, and every change triggered a painful merge process that frequently introduced new bugs.

Team Composition and Management

Management repeatedly fired experienced programmers and replaced them with inexperienced staff to cut costs. Eventually, out of 55 people, only 20 were developers while the remaining 35 were managers, many without software‑engineering experience. The company also imposed draconian policies such as firing anyone arriving after 9:00 am and disabling the coffee machine during inspections.

Outcome

The project’s endless delays incurred daily fines of thousands of euros. After years of mismanagement, the company’s leadership was arrested for embezzlement, and the project finally terminated. The author advises newcomers to avoid large, legacy C++ projects, steer clear of CORBA, and be wary of overbearing product managers.

Overall, the case illustrates how poor technical choices, lack of proper version control, and dysfunctional management can combine to create a software development hell.