Software Engineering Devastation

Original: Software disenchantment

I came across this article online, and I recommend that every software engineer take a look at it. While some viewpoints may seem overly radical, I generally agree with the core ideas.

Why is software so "slow"?

At the beginning, the author mentions that fields like automotive, aviation, and architecture have developed certain models over time; the wing designs, shapes, and functions of airplanes are nearly uniform, and the results are evident for all to see.

I've been pondering why these fields seem to have established patterns, while software development appears to be getting worse. Every time I run npm install on my MacBook Pro or iMac, I hear the fans spin up to full speed. Web development feels like it's built on an unstable foundation, with countless frameworks and state management tools available for the front end.

However, comparing software development to something like aviation seems a bit unfair. Airplanes (especially commercial ones) are designed to transport passengers quickly and safely from point A to point B. Houses are meant to provide people with sturdy and durable shelters. Both have very clear purposes that don't significantly change with the times.

But what about software? Because of rapid iterations, there are more possibilities. A website's initial purpose may have been just to display information, but now it encompasses a vast array of functions: watching videos, listening to music, sharing updates, uploading images, playing games. Thanks to hardware upgrades and technological advancements, we can now do so much more with a single browser.

This brings us to the original sin of JavaScript. It’s a programming language created in a relatively short span of time that has now evolved into the most popular programming language worldwide—something even the author likely didn't foresee.

I find it somewhat unfair to criticize JavaScript by comparing it to Java. Java has its own VM, Runtime, JDK, etc. In web development, we have to rely on a plethora of browsers, which has led to the emergence of tools like Babel and Webpack.

From this perspective, it seems too simplistic to say, "Hardware has become faster, but software has become slower." Was it possible to achieve so much using just a browser 20 years ago? Were the functionalities and complexities of software 20 years ago comparable to what we have today?

As computer users, we seem to still need extremely simplified software that allows users to access a streamlined browser (without history, downloaded files, or dev tools) whenever they desire.

The author also laments that modern web applications are incredibly bloated. Gmail, for instance, struggles to scroll smoothly, and Slack's app is a resource monster. I share this curiosity about why resource consumption is so high. I understand that it’s built with Electron, but why does using Electron lead to such high resource usage?

I maintain a positive attitude toward the possibilities that Electron brings to GUI development, though many people complain about its resource intensiveness. I believe this is something that should improve in the future, but if we look at Slack and VS Code, both are quite successful cases built on Electron.

The author continues his critique, turning to text editing. He states that the input delay in Emacs, developed 42 years ago, is less than that of modern text editors. 3D games can render millions of graphics within 16ms; why can’t simple text editing achieve the same?

While I’m currently using a MacBook Pro, many users are on less powerful devices. We shouldn’t assume all users have high-end equipment just because we do, nor should we blame users for using less capable devices. This is beyond doubt; I was also shocked by the resource consumption of Slack and VS Code.

Another issue the author mentions is We’re stuck with it. I strongly resonate with this point. More and more engineers seem indifferent to how things are implemented. Is it slow? That’s fine, as long as it meets business requirements. Don’t understand how it works? Just use a package. This "good enough" mentality is not what a professional engineer should embody; it’s not engineering—it’s laziness.

I've been increasingly aware of this. While there are indeed many tools that help you build a decent product (website) with a superficial understanding, the demand for detail and principles seems to be diminishing. This is not a good trend for me, so I constantly remind myself to understand the underlying principles, which are often not that difficult (though operating systems really are tough QQ).

This year, I plan to return to the basics, focusing on the three great romances of programming: "operating systems, compilers, and graphics." I previously delved into WebGL in 2017, so that leaves operating systems and compilers as my major topics for the year ahead.