Why Bigger Software Teams Often Slow Down Projects: Lessons from a Decade of Refactoring

Our company's Windows software has been around for over ten years, and after many engineers worked on it, the code became a tangled mess. Over the past three months I rewrote the entire main program, reducing the codebase from tens of thousands of lines to a few thousand while preserving functionality, improving performance, and achieving a clean architecture.

After completing the Alpha version, I laughed so loudly it startled the whole office.

During the rewrite, I initially spent no more than four hours per week on the program for the first two months, then worked a few extra days during the Lunar New Year, still limiting each day to four hours of coding.

Typically I code for two or three hours during the day, take breaks when I hit a bottleneck, and later review material on my phone before bed, allowing ideas to surface naturally the next morning.

Coding is a creative act, not hard labor; sitting for dozens of hours a day only clouds the mind.

Many top programmers I know also limit their daily coding time.

In 1995, while in Salt Lake City with Trend Micro founder Zhang Ming‑zheng, he asked why companies pay only two or three times the salary for an outstanding engineer compared to many mediocre ones, despite the former’s output being equivalent to twenty average engineers. I had just earned my Ph.D. and could not answer, and years later I still have no answer.

He asked because I had introduced several highly capable friends to Trend Micro. They were not paid ten‑ or hundred‑times salaries but received substantial stock, later becoming billionaires after Trend went public in Japan.

Writing large software is not a case of "more people, easier work". In civil engineering or manufacturing, adding workers increases output, but in software engineering, more people make coordination harder and often degrade quality and performance—a phenomenon described in "The Mythical Man‑Month".

IBM discovered this while developing the OS/360 operating system in the 1960s.

Thus I still wonder why large software companies employ so many engineers.

When I served as an information officer in the military, I found two junior technicians too slow at coding, so I took over all programming myself, which led to a good friendship.

Good programmers are not judged by the length of their code. In university I bragged about a 10,000‑line compiler; later, during my Ph.D. at Brown University, I completed a powerful program with only 7‑8 k lines.

Second‑tier engineers tend to over‑complicate simple problems, producing unreadable code, whereas top‑tier engineers simplify complexity, making the solution appear obvious.

In the software industry of Taiwan and the United States, this hierarchy of skill is evident.

In the late 1980s IBM, the world’s largest computer company, appointed senior hardware managers to run its software division, using KLOC (thousands of lines of code) per engineer per year as a productivity metric, which encouraged developers to write unnecessarily long code.

Becoming a top software engineer requires deep knowledge of computer‑science fundamentals and extensive practical experience. In my Ph.D. courses at Brown, we built a mini‑Unix with file and process systems, wrote multiple compilers with different implementations, and endured a graphics course that demanded over forty hours of programming per week.

Those who survived these courses without failing and earned high grades became true masters of both theory and practice.

In my cohort, perhaps ten were at my level, but the most renowned was Professor Steve Reiss, whose single contribution equaled five to ten engineers.

He once wrote a Windows‑style solitaire game on a Sun workstation over several days, using only spare time.

Many of my talented peers later left programming for academia, high‑pay corporate jobs, or management positions, and over time their coding skills faded.

Thus, true programming masters are rare, and those who continue coding are even rarer.

An old joke in the U.S. software industry says that when two engineers are on a team—one good, one poor—the one who gets promoted is usually the poor programmer, because the good one must stay to write code.

At the peak of my abilities, shortly after earning my doctorate, I could probably handle ten times the work of an average engineer, though I never claimed to be a one‑hundred‑fold prodigy.

After moving into management, continuing to code became a source of ridicule, so I stopped and focused on building a team of engineers to maintain credibility.

Now, as my own boss, I can code whenever I like, regardless of others' opinions.

During the recent New Year break I rewrote our company's Windows main program, feeling my skills restored to about thirty‑to‑forty percent of their former level, which brought me great joy.

Nevertheless, software engineering remains a difficult-to‑understand field, even for a software engineer whose Ph.D. research was on programming environments—the very topics discussed here.

Source: Internet Note: The author appears to be a Taiwanese individual; the term “soft‑ware” has been standardized to “software”. Contributions are welcome.