Incomprehensible software engineers: Why write tens of thousands of lines of code when a few thousand lines can do the job?

one

Our company's Windows software has been around for more than a decade, and after generations of engineers' renovations, the content has become a mess. In the past three months, I found time to rewrite the entire main program myself. The original program had tens of thousands of lines, but I rewrote it to only a few thousand lines, with the same functions, better performance, and a neat architecture.

[[229124]]

After finishing the Alpha version the other day, I couldn't help but laugh so hard that the whole office was startled by my laughter.

two

During the period of rewriting this program, I probably spent no more than four hours a week on it in the first two months. Later, I took advantage of the Chinese New Year to work overtime at the company for a few days, but I never spent more than four hours a day writing programs.

I usually write programs for two or three hours during the day. When I encounter a bottleneck, I will do other things or simply go home for dinner. Before going to bed at night, I will lie in bed and check information on my mobile phone. When I am on the way to work the next day, I will naturally think of a good solution.

Programming is a kind of creation, not hard work. You cannot sit in front of the computer for more than ten hours a day. Otherwise, working overtime will only make your brain more confused.

Many of the programming experts I know don't spend too much time writing programs every day.

three

One day in 1995, in Salt Lake City, USA, I was accompanying Zhang Mingzheng, the founder of Trend Micro, who was helping his father cross the street. He suddenly said to me, "Yijing, I really don't understand. In the software industry, the output of an excellent engineer can easily match that of 10 or 20 mediocre engineers, but the company only needs to pay him two or three times the salary. Then why are there still companies willing to pay to hire those mediocre engineers?"

At that time, I had just graduated with a Ph.D., so of course I didn’t know how to answer his question; and now, after so many years, I still don’t know how to answer that question.

Zhang Mingzheng asked me that question because I introduced several classmates and friends to work at Trend Micro. They were experts who could do ten or a hundred things. Trend Micro didn't pay them ten or a hundred times their salary, but it treated them well and gave them a lot of stocks.

Later, TrendForce went public in Japan, and my friends all became billionaires. Their wealth should be ten or a hundred times that of an average engineer, right?

Four

Writing a large program is not always a matter of "more people means more work".

If it's civil engineering or manufacturing, the more people there are, the greater the output. If a project is delayed, more people can be transferred to help.

However, in software engineering, the more people there are, the more difficult it is to coordinate, and the programs written tend to have lower quality and worse performance.

This is the famous "The Mythical Man-Month: Adding manpower to a late software project makes it later".

IBM discovered this peculiar phenomenon when it was developing the OS/360 operating system software in the 1960s.

So I don't understand why large software companies employ so many software engineers?

five

When I was in the military, I worked as an information officer at the Information Center of the Tenth Army Corps in Taichung. At that time, I had two college graduates from information science departments under me, but I thought they wrote programs too slowly, and it was even more troublesome to explain them to them, so it would be faster for me to write them myself.

So I told them to cool off and I would write all the programs. They felt very embarrassed and made me some delicious milk tea.

Later we became good friends.

six

When writing a program, the longer it is, the better or more powerful it is.

When I was young and studying computer science at NTU, I would brag to my friends, “The programming language compiler I wrote has more than 10,000 lines in total.”

Later, I went to Brown University in the United States to study for a doctorate in computer science. When I graduated, I liked to brag to my friends: "The program in my doctoral thesis is so powerful, but I only used 7,000 or 8,000 lines of code to complete it."

seven

Second-rate software engineers like to complicate simple problems and write programs that others cannot understand.

First-class software engineers like to simplify complex problems and write programs with clear and understandable structure, so that people will feel that the problem seems very simple after reading it.

Third-rate software engineers will admire second-rate software engineers because they think that second-rate engineers must be super-powerful since they can’t even understand the programs they write.

Third-rate software engineers will not worship first-rate software engineers, because they think that what first-rate engineers do is easy to understand and seems simple.

Only first-rate software engineers will admire first-rate software engineers, because only they can see what makes other first-rate software engineers so good?

This is the case with Taiwan's software industry, and it is roughly the same with the software industry in the United States.

eight

IBM was the world's largest computer company until the late 1980s, when it hired some of its hardware executives to run its software division.

Based on their experience managing the manufacturing department, the senior executives decided to use KLOC (thousands lines of code), which is the number of lines of code written by each software engineer per year, to calculate the efficiency of the software department.

As a result, software engineers "talk a lot more than they say" and write a bunch of long and inefficient software programs.

Nine

To become a first-class software engineer, one must be familiar with the various basic theories of computer science and accumulate long-term practical experience.

When I was taking classes for my doctorate in computer science at Brown University, the amount of programming assignments was very heavy. In the Operating System class, the professor asked each of us to independently write a mini Unix operating system that included a file system and a process system.

When taking the Compiler class, the professor asked each of us to write a compiler independently, and each module had to be written in two or more ways, and then compared with each other;

The computer graphics course taught by Professor Andy Van Dam was like a living hell. The teaching assistant sent out a questionnaire and found that the average time spent by each student on writing programs for that class was more than 40 hours per week. The students almost rebelled.

However, those who have taken the above three courses without failing and getting high scores will become masters or even top masters who understand both theory and programming.

ten

When I was doing my PhD at Brown University, I estimated that there were about ten programmers like me in our department.

But the most recognized programmer in our department is still my advisor, Prof. Steve Reiss. He alone is probably equivalent to five to ten engineers of our level.

There are many legends about him. One time I went to his office to find him and saw him playing a solitaire game. He was a little embarrassed when I discovered him, and quickly told me that he thought the solitaire game on Windows was very fun, but he didn't have a Windows computer, so he spent four or five days using his spare time to write a similar solitaire game on his own Sun Work Station, including a colorful graphical interface and so on.

If you want to play video games, just write one yourself? I wanted to laugh, but I almost knelt down in front of my master.

eleven

Among the software experts I met at Brown University, there are probably not many who later made programming their career and wrote great and widely used programs.

Because some people later become university professors, and professors usually don't write programs themselves. After a long time, I don't know how much of their skills are left?

Some people later went to some big companies to write some very boring and uninteresting programs in order to get high salaries. After a long time, I don't know how much of their skills are left?

Some people later entered the industry and were promoted to management positions soon after. However, management personnel usually cannot write programs themselves. After a long time, I wonder how much of their skills are left?

Therefore, there are not many programming experts to begin with, and programming experts who continue to write programs are even rarer.

twelve

There is an old joke in the American software industry: If there are two engineers on the same team, one is very good at programming and the other is very bad at programming, the one who is promoted to manager must be the one who can't program.

Because the team needs the one who can write programs to stay and write programs.

Thirteen

My best programming skills were probably when I just got my Ph.D. more than 20 years ago. At that time, I understood the theory and had accumulated a lot of programming experience. I dare not say that I can be as good as a hundred people, but I should be able to be as good as ten people.

Unfortunately, I was promoted to a management position not long after that. After becoming a manager, assistant manager, and general manager, if I still wrote programs myself, I would be laughed at by others.

So I stopped writing programs, and I also learned to put more engineers in my department. Otherwise, if the team wasn’t big enough, I would be looked down upon by other departments and my superiors.

After twenty years, my skills are only about 20% to 30% left.

fourteen

I am now my own boss. One of the best things about being my own boss is that I can write programs whenever I want. Even if someone wants to laugh at me, I can ignore them.

fifteen

I took advantage of the Chinese New Year holiday to rewrite our company's main Windows program. After completing it, I felt that my skills had recovered to 30% to 40% of what they were before, and I couldn't help but feel very happy.

But I still think that software engineering is a very difficult industry to understand. Although I am a software engineer myself, and my doctoral thesis is about programming environment, the topic is the issues I mentioned here.