When did software go off the rails? (opens in new tab)

> Hardware capability increases exponentially, but software somehow just bloats up, using the power and space, without providing much more functionality or value.

I disagree. Our baseline for software has increased dramatically. If you don't care much about the added functionality or value of the new software, use Mosaic or Netscape 4.0 to browse the web.

There are obvious improvements in browsers which you are so used to that you forgot them: tabs, ability to zoom, process-level isolation for websites, support for newer protocols, CSS, Unicode support, font rendering things I'm probably not aware of, a built-in debugger and inspector in the browser, and so on.

Again, if you think that software hasn't advanced much, simply use the software from 10 or 20 years ago, and see if you can stand the experience.

I think a lot of it is you tend to only optimise as much as you need to. When the average user only has 4MB of memory, you're going to spend a lot of time optimising image size for example. When you can assume 4GB of memory, you're going to put that time into other places as the effort would be very difficult to justify.

Wouldn't your users appreciate more features than optimisations most of them aren't going to notice? For the same block of time today compared to decades ago, you're going to be creating an app that uses more memory and CPU but has a lot more features. Developer time isn't free and needs to be justified.

I used to write DOS apps for 66MHz PCs and you'd spend an enormous amount of time optimising memory and CPU usage. This was similar for the initial batch of Android phones as well as you didn't get a lot of resources (e.g. loading a large image into memory would crash the app). Now I can create more features in way less time and rarely have to think about optimisations unless dealing with a lot of data.

I think expecting every software developer to release software that uses the absolute minimum amount of CPU and memory possible is completely unrealistic. The people commenting that developers don't know how to write optimised code anymore have different priorities to a typical business. I know how to make low level optimisations and have even resorted to assembly in the past but I'm only going to these lengths when it's absolutely required.

For commercial projects, it doesn't make any business sense to optimise more than is needed even if that makes software developers squirm.

Organizations get what you reward.

Tech Debt is rewarded.

Doing something for the first time, almost by definition, means one does not really know what one is doing and is going to do it somewhat wrong.

Hiring less skilled labor (cheap coder camps for example) to implement buzzword bingo solutions gets you into a place where all the software contains large chunks of it's substance coming from people doing it for the first time... and not 100% right.

As we never go back to fix the tech debt we end up building stills for the borked and less than great. When that structure topples over we start over with a new bingo sheet listing the hot new technologies that will fix our problems this time round for sure.

I'd think that a good fraction of the current language expansion is that the older languages are too complex and filled with broken. Green fields allow one to reimplement printf, feel great about it, and get rewarded as a luminary in the smaller pond.

.....

oh... and well the cynic in me would argue planed obsolescence at the gross level. No one buys the new stuff unless there's new stuff.

This is not a single thing.

I think the biggest culprits are abstraction layers. You use a framework that use js that use a VM in a browser that runs on an OS. The time when showing text was done by the application writing a few bytes in VRAM is long gone. Each layer has its internal buffers and plenty of features that you don't use but are still there because they are part of the API.

Another one is laziness : why bother with 1MB of RAM when we have 1GB available? Multiplied the number of layers, this becomes significant.

Related to laziness is the lack of compromise. A good example is idTech 5 game engine (Rage, Doom 2016). Each texture is unique, there is no tiling, even for large patches of dirt. As expected, it leads to huge sizes just to lift a few artistic constraints. But we can do it so why not?

Another one is the reliance on static or packaged libraries. As I said, software now use many layers, and effort was made so that common parts are not duplicated, for example by using system-wide dynamic libraries. Now these libraries are often packaged with the app, which alleviate compatibility issues but increase memory and storage usage.

There are other factors such as an increase in screen density (larger images), 64 bits architectures that make pointers twice bigger than their 32 bit counterparts, etc...

To understand this, you need to read Andy Grove, especially "Only the Paranoid Survive". It's fascinating: basically everything I, as a user, see as a boon, he perceives as a threat. From his point of view, everything that allows people to buy cheap machines, run fast software etc. is negative and needs to be dealt with. Intel basically didn't change over the years, with the recent x86/ARM fuss showing just that. On the other end of the spectrum are companies exploiting the existing possibilities - for a long time it was Microsoft, making each version of their flagship products more and more resource hungry, so the users were forced to upgrade ("What Andy giveth, Bill taketh away"). What is happening now is the extension of the same story - "Memory is cheap? Let's use all of it!".

As a developer, you rarely care about memory usage; as a web developer, you have limited influence on CPU usage. And since most managers care only about getting the project done on time and within the budget, this is what most developers concentrate on.

Software is causing science is moving backward.

Software makes the world more complex faster than we can understand it, so even though we have more knowledge we understand less about the world.

We used to know how cars work. We used to know how phones work. Now we don't, and never will again.

The implications are unsettling.

I think it started when we went away from native compiled languages. Visual Studio 6 was in my opinion the best version in terms of responsiveness/functionality. After that, with .Net, Visual Studio started including more .Net code and become more and more slow over time. Over time, people slowly got used to their applications being slower and slower. Then the web came and people started writing apps in Javascript. The Javascript apps are not too bad compared to the .Net apps, so people did not notice. However, if you were comparing them to Pascal/C/CC++ apps, you would have noticed a big difference.

I still find it amazing that DOOM was 2.5MB. A Google search page is ~20MB (16MB in DDG). And a Wikipedia page is ~19MB. (FF 55). This is crazy to me. That even simple things take so much space now. I know space is cheap, but this does feel bloated. And while these sizes might not be noticeable on a computer, it definitely is on a mobile connection. I had figured the advent of mobile would make optimization more appealing, but it seems to go in the other direction.

I think the explanation is that bloated software is cheaper to make.

It is cheaper to develop a .Net app than a C app. Cheaper in Development and maintenance.

It is cheaper to not care about efficient data management, or indexed data structure.

What we're losing in efficiency, we gain in code readability, maintainability, safety, time to market, etc.

Software complexity increases exponentially with linear growth in features and polish. Occasionally someone takes the time to step back and rethink things, but generally you’re just adding another layer on top of the ancient ruins. Code archaeologist should be a job title in many organizations.

This keeps coming up every couple of years, but is just wrong.

In the last 5-10 years, there hasn't been almost increase in requirements. People can use low-power devices like Chromebooks because hardware has gotten better/cheaper but software requirements haven't kept up. My system from 10 years ago has 4gb of ram - that's still acceptable in a laptop, to say nothing of a phone.

If you're going to expand the time horizon beyond that, other things need to be considered. There's some "bloat" in when people decide they want pretty interfaces and high res graphics, but that's not a fair comparison. It's a price you pay for a huge 4k monitor or a retina phone. Asset sizes are different than software.

I won't dispute that the trend is upward with the hardware that software needs, but this only makes sense. Developer time is expensive, and optimization is hard. I just think that hardware has far outpaced the needs of software.

It happened one step at a time.

We wanted multi-tasking OSes, so that we could start one program without having to exit the previous one first. That made the OS a lot bigger.

Eventually, we got web browsers. Then Netscape added caching, and browsers got faster and less frustrating, but also bigger. And then they added multiple tabs, and that was more convenient, but it took more memory.

And they kept adding media types... and unicode support... and...

We used to write code in text editors. Well, a good IDE takes a lot more space, but it's easier to use.

In short: We kept finding things that the computer could do for us, so that we wouldn't have to do them ourselves, or do it more conveniently, or do something at all that we couldn't do before. The price of that was that we're dragging around the code to do all those things. By now, it's a rather large amount to drag around...

Wonder how much of it is only due to asset. I keep making my colleague notice than a single background image displayed on a high res iphone occupies more ram than the total data of their app by a factor of 100 (at the minimum). Same goes for app size on disk : it's most often mainly assets.

So just loading from disk, decompressing, put on Ram then moving around and applying visual effects is probably half of the reason everything is slow. Those "bloat" graph should also mention screen resolution and color depth.

TFA doesn't even load without javascript. I use noscript and this HTML file won't display anything unless I allow JS to load from a different domain. Perhaps the author should practice what he preaches. Then again, I don't really know what he preaches because I can't be bothered to allow the JS to load.

Back in the late 1960s, see

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Note NASA controlled the moon missions with an IBM 360/95 that had something like 5 MB of RAM, 1GB of disk, and about 6 million instructions per second.

Today an internet-controlled light switch runs Linux and has vastly larger specifications. Connecting to WiFi is more complex than sending astronauts to the moon!

This is what I get after starting Chromium, before opening any website. Does this mean it is using 178064 + 175208 + 92132 + 90492 + 87596 = 623492 KB = 623 MB right off the bat without having loaded any HTML?

    NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND        

     0  979612 178064 108084 S   0,0  1,1   0:01.38 chromium-browse
     0 3612044 175208 128552 S   0,0  1,1   0:01.83 chromium-browse
     0 1372444  92132  67604 S   0,0  0,6   0:00.27 chromium-browse
     0 1380328  90492  58860 S   0,0  0,6   0:00.62 chromium-browse
     0  457928  87596  75252 S   0,0  0,5   0:00.67 chromium-browse

Software went off the rails when Java decided to store all nested nonprimitive objects on the heap, and Sun thought this was an acceptable choice in a language marketed at general purpose app development.

Typically as developers we let the software bloat until it hurts us directly. Since we are always using more and more powerful machines we are always going to let the bloat continue. If we get called on it we've got the slam-dunk in our back pocket: "Premature optimization is the root of all evil."

I'll make three points.

The article is focused on machine efficiency. Human efficiency also matters. If you want to save cycles and bytes then use assembly language. Geez, we had the assembler vs fortran argument back in the 70's. Probably even in the 60's but I'm not that old. Guess what? High level languages won.

Next.

Hey, Notepad is much smaller, leaner, and faster than Word! Okay. But Word has a lot of capabilities that Notepad does not. So is it "bloat" or is it "features" ? Guess what, Windows is a lot bigger and slower than DOS.

Imagine this argument from a business person:

If I can be to market six months sooner than my competitor for only three times the amount of RAM and two times the amount of CPU horsepower -- IT IS WORTH IT! These items cost very little. You can't buy back the market advantage later. So of course I'll use exotic high level languages with GC. I'm not trying to optimize machine cycles and bytes, I'm trying to optimize dollars.

Ok, fair enough, but have a look at yourself. Your blog is static content not served statically, that requires javascript.

Look at any analog - real estate property, an army of people, a kitchen. Anything left un-groomed during high use becomes unusable. Grooming software needs to be either someone's full-time job (real-life custodians), or a big constantly-enforced chunk of everyone's job (military grooming standards).

At a big company could argue requirements writers need to be technical, but once you've done a startup you'd know that you're in an army and not in a fixed building that needs architected once. The customer and your enemies are always on the move and you have to keep moving on new terrain as the money and your business keeps moving there. Build with code of conduct for your developers, and allow the code base to evolve with modules, or some other approach.

I love bloated software, I wish opening facebook would require 128GB RAM.

It makes hardware cheaper for everyone, even nerds who use terminal and lightweight WMs ;-)

Software was never on the rails. This whole industry has, AFAICT, been flying by the seat of its pants from Day 1 with whatever hacks get today's job done. For a while, that meant hacks to save space and time. Now... it doesn't.

I suspect this is the inevitable price for the expanding scale of the software industry. Perhaps the problem isn't about depth, as in what a given piece of software can do, as much as breadth, as in how much software there is now and how many different things it can do collectively.

One cost of the increasing breadth in the industry is that if we want to have a lot more software then obviously it can't all be written by the same relatively small pool of expert programmers who wrote software in the early days. With more software being written by people with less skill and experience, many wasteful practices can creep in. That can include technical flaws, like using grossly inefficient data structures and algorithms. It can also include poor work practices, such as not habitually profiling before and after (possibly) optimising or lacking awareness of the cost of taking on technical debt.

Another cost of the increasing diversity in the software world is that to keep all that different software working together, we see ever more generalisations and layers of abstractions. We build whole networking stacks and hardware abstraction libraries, which in turn work with standardised protocols and architectures, when in days gone by we might have just invented a one-off communications protocol or coded directly to some specific hardware device's registers or memory-mapped data or ioctl interfaces.

There is surely an element of deliberately trading off run-time efficiency against ease of development, because we can afford to given more powerful hardware and because the consequences of easier development can be useful things like software being available earlier. However, just going by my own experience, I suspect this might be less of a contributory factor than the ones above, where the trade-off is more of an accident than a conscious decision.

Besides all other things people have mentioned there is also new requirements for ui:s. People complain if their drag-movement with a finger don't align perfectly with a nice animation on the screen on a cheap phone. Those things did not exist 10 years ago or 20 years ago. Interfaces were simpler and easier to build and users were happy that it worked.

But I do agree that software could be a bit faster nowdays.

A: Around the time that a simple blog post required JS from four separate domains in order to display anything other than a blank page.

It's kind of because we can.

I'm currently on a Mac and a PC. The Mac's CPU is at maybe 5% when I'm doing most things.

The PC is at 1%.

I'm using half the PC's memory and 3/4 of the Mac's.

These are no up to date, high memory or high performance machines.

Have a look at your own machine. Surely for most of us it's the same.

And that memory usage is mostly in one application - Chrome. The only bloat that hurts a bit now is web page bloat. And on a good connection this isn't an issue either.

It's also different on phones where application size and page size seems to matter more.

I do often wonder wth is going on with bloat. I can understand a videogame which has huge amounts of media might be large. But business apps?! It doesn't make sense.

Software is written better.

In the past, computational complexity was lowered by arbitrary size limits. e.g. if you had a O(n^2) algorithm you might cap n at 10 and now you have a O(1) algorithm. Job done.

Now, computational complexity is lowered by aggressive use of indexing, so you might lower your O(n^2) algorithm by putting a hash table in somewhere, and now you have an O(n) algorithm. Job also done.

The practice of putting arbitrary size limits on everything has almost died out as a result.

This article is a waste of bandwidth and server storage space, the entire content is just an elaboration of the title, with not even a single consideration to what the cause is.

There are also a few graphs to make the author feel like he is a scientific researcher writing a paper instead of what he is actually doing , which is posting a question that quite frankly could with little extra thought fit in a tweet.

I've been teaching myself C, with the intention of learning how to write code for embedded applications where efficiency is key.

It seems to me that new languages prioritize quick iteration over effective machine operation. The easier a language is to write and interpret, the faster an outfit can churn out an application. The exponential computing power growth has been sufficient enough to absorb these collective "shortcuts". Thus, it is not being taken advantage of properly.

The CSCI/Engineering fields have become more of a gold rush than thoughtful trades. Boot camp management seeks profit, and trainees seek to quickly fill high paying jobs. It all culminates into this situation where code doesn't need to be clever and thought out - just created A.S.A.P to handle whatever trending niche market or "low-hanging fruit" there is. The work of these products get handled server side, where electrical costs for cooling is a fundamental expense.

Thanks Jason, enjoyed your thought-provoking post. I'm reminded of Parkinson's law that "work expands so as to fill the time available for its completion". It's as if the software bloats up to fill up the available hardware capacity.

From a fundamental level though, my hunch would be how modern development takes modularization / abstraction to a type of extreme. Imagine a popular Node.js module and how many dependencies it has and how many dependencies its dependencies have.

It's not hard to imagine a lot more computing power is required to handle this. But that's ok to decision makers, computing power is cheap. Saving developers time by using modularized developments brings more cost/profit benefits, like what Dan said.

PS: the link on Visual Studio. Oh wow, what fond nostalgic memories it brings me :)

I would guess at least some of the issue is that most users don't show a preference for faster smaller software, especially because it doesn't benefit them if a product uses less RAM and CPU. Displaying a UI is better than a text mode interface. Icons that don't look jaggy on the screen are nicer than ones that do. Anti aliasing, gradients and drop shadows make things look nice. Drag and drop that has a pretty animation is nicer than drag and drop workout. It is the same reasons people choose a BMW when a Corolla does pretty much the same job. People pay the cost they want to live with. In the trade off between functional and thrifty and pretty and feature packed, the latter nearly always wins.

"The Blogger tab I have open to write this post is currently using over 500MB of RAM in Chrome."

So, why are you using Blogger instead of emacs/vi/notepad to write a static HTML page?

Apparently the author seems to think that all that bloat DOES give him something, no?

Software does so much more today as a baseline requirement. Think about all that internationalization, high DPI graphics, security, nice APIs and modularity: these aspects of software have never been at such a high level before.

I look at articles like this and the comment responses to it and I can't help but think everyone is like the old man grumbling how "things used to be built to last!"

Have people really forgotten their computing history so soon?

Let's roll back the clock. Windows 95 ran for a total of 10 hours before blue screening. Windows ME ran for -2 minutes before blue screening and deleting your dog.

Roll back further. IBM was writing software not for you. Not for your neighbor. They were writing software for wealthy businesses. Bespoke software. Software and hardware that cost more than you make in a lifetime.

Software, today, represents responses to those two historical artifacts.

1) At some point software became complex enough that we discovered something we didn't know before ... programmers are really bad at memory management. Concurrently, we also realized that memory management is really important. Without it, applications and operating systems crash.

And yes, this point was hit roughly around Windows 95. You really couldn't use Windows 95 for more than a day without something crashing.

So the programming ecosystem responded. Slowly and surely we invented solutions. Garbage collected languages and languages without manual memory management. Java, .NET, Python, etc. Frameworks, layers of abstractions, etc.

Now fast forward to today. I'm absolutely shocked when an app crashes these days. Even games have become more stable. I see on average maybe 1 or 2 crashes in any particular game, through my _entire_ playthroughs. And usually, the crashes are hardware bugs. I haven't seen a Firefox crash in ... months.

This is leaps and bounds better. Our solutions worked.

The caveat, of course, is that these new tools use more memory and more CPU. They have to. But they solved the problem they were built to solve.

2) In the "good old days" software was bespoke. It was sold strictly B2B. For a good long while after that it remained a niche profession. Does no one remember just how expensive software and hardware used to be? And people scoff at $600 phones...

But software exploded. Now everyone has a computer and software is as ubiquitous as water.

With that explosion came two things. Software got cheaper. A _lot_ cheaper. And software filled every niche imaginable.

When software was bespoke, you could get the best of the best to work on it. Picasso's and Plato's. But those days are long gone. Picasso isn't going to make Snapchat clones.

We needed a way to allow mere mortals to develop software. So we created solutions: Java, JavaScript, Python, .NET, Ruby, etc. They all sought to make programming easier and broaden the pool of people capable of writing software.

And just like before, these tools worked. Software is cheap and plentiful.

We can bemoan the fact that Slack isn't a work of Picasso. But who wants to pay $1 million per seat for Slack? Instead, Slack is free in exchange for the sacrifice of 4GB of RAM.

The lesson here is two fold. Software today is better than it ever was, and it will continue to get better. We've learned a lot and we've solved a lot of problems. Battery constraints are forcing the next evolution. I would never have dreamed of a world where my laptop lives for 10 hours off battery, but here we are. I can't wait to see what the next decade holds!

Is this a projection of "the next 90%" issue?

"The first 90% took 2 weeks to finish. The second 90% also took 2 weeks to finish (and now your 99% done). The next 90% also takes two weeks to finish (99.9% done)..." Reapplied to another resource..."The first 90% consumes 1GB of RAM. To solve the next 90% of the problem, takes 1GB of additional RAM...

If you continue this trend, the problems solved in the incremental steps maybe used fractionally less often, but are probably also more complex and required a greater resource investments. Our software does a lot more, but the later developed parts are usually used left often and are more complex. Talking to the one and only ship headed to the moon when you don't particularly care who hears you is less difficult than securely purchasing things online over a WiFi connection. At the user experience level its just "thing A talks to thing B" but the later case has also had to solve n-th 90% issues of congestion and security and handshake and...

That being said, we rarely go back and see what in the earlier iterations are now based on false assumptions. So there probably is a fair amount of accumulated cruft with no clear detector for what is cruft and what is essential.

> There have been a few attempts at a Software Minimalism movement, but they seemingly haven't gained much traction.

For those interested in exploring a minimalist approach, it's worth checking out http://suckless.org/philosophy and https://handmade.network/manifesto

Excuses excuses, most modern software developers have no clue as to how to right tight code

This line caught my attention:

"And somehow our software is still clunky and slow."

It is? I haven't really noticed. It seems to me that my 9 year old desktop still runs most modern software reasonably well. My new laptop runs it much more quickly than machines from 15-20 years ago.

Granted, in an abstract sense, CPU usage and memory consumption has grown a bit, but the actual user experience is better.

It's all about cost and what users can accept. If a feature costs 10 times less, takes half the time to implement and is easier to maintain but produces the same result for the end user, why would software companies bother to optimise (if the end user does not care)?

Also, it seems to me that the optimisation on the web is done on speed at the detriment of memory usage.

Older software was written in languages you had to manage the memory in C, C++, pascal etc, it requires more skilled developers (I'm told), simpler languages like javascript require less knowledge to write applications. The cost is though higher resource usage.

I think a potential solution would be to encapsulate every program in their own VMs, with memory & cpu limits set.

Put some control back in the user's hands, prevent less run-away bad behaviour from the apps.

> The Blogger tab I have open to write this post is currently using over 500MB of RAM in Chrome. How is that even possible?

Mate, you picked /blogger/ as your preferred blogging platform. Blogger can't even deliver a page title without Javascript.

There's a whole world of much higher quality software out there, it may be that you've chosen not to use it.

This dude should try switching his blog to Pelican[1], it might be something of a revelation.

[1] https://blog.getpelican.com/

While application software has become more bloated, Microsoft has done a fairly good job at keeping Windows necessary footprint down.

After Apple stopped supporting 32 bit x86 Macs years ago, I decided to put Windows 7 on my old 2006 era Core Duo 1.66ghz Mac Mini with 1.25GB of RAM. My parents still use it occasionally. It can still run an updated version of Chrome and Office - not at the same time of course - and it isn't painful.

My Plex Server is a 2008 era Core 2 Duo 2.66Ghz Dell business laptop with 4Gb of RAM.

I would posit that the decrease in price of computational resources drives a couple of things - better quality (more resolution, colors, for e.g) and ease/cost of development.

You might see individual applications do the same things, and consume more resources due to the layers and layers of abstractions, BUT be cheaper to build. As a consequence, many, many, many more applications being built, for cheaper, reaching more people, "eating the world".

At the risk of being downflamed for not knowing something obvious, I see it as the gap between what standard runtime libraries provide (e.g. nice generic list, stack, and queue classes) and the algorithms devs implement on top of them. A part of me wants to see all of the grotesque implementations of "visit every relationship in this tree" that get invoked when I click the "add comment" button on this.

Not sure about when, but I think that restrictive software licensing combined with Moore's law guaranteed wasted computing power. Companies that sold both hardware and software had an incentive to soak up that power to encourage perpetual upgrading. It grew wasteful "software ecosystems". That or testers should fail more software that doesn't run quickly on low end hardware.

IMHO, the starting point was the requirement of 3D accelerated video cards. The last 3D games I have played (alone in the dark 1, doom) did not require any 3D card. But now, you can't display a line of text without a huge pile of crappy layers above insane GPU. 25year ago, direct video memory mapping and bitblt operations were sufficient.

I think the author demonstrates well the problem by using a blogger theme that requires JavaScript to be turned on instead of statically rendering the blog post that is just a few paragraphs long as HTML and serving that from a simple server.

He shouldn't ask "when" though but who made it go off rails (sic!) and why.

This article is based on the misunderstanding that software complexity has NOT grown exponentially. It has.

Even though features might be added in a linear fashion (and I think that's not true either - the teams that build large applications have grown too), the complexity the whole system might scale as the square of the number of features, or exponentially. That is: if word2017 has 10 times the number of features as Word6.0, we should not be surprised to see CPU and RAM requirements be 100 or 1000 times higher.

Finally, just like a memory manager in an OS makes sure all memory is actually used, software should be using the computers' resources. If an average computer now is 4x3Ghz then a foreground application such as a photo editor should have features that at least some times puts that hardware to good use. Otherwise there was no point in having that hardware to begin with. As software developers we should aim to scale our software to use the available hardware. We should not just let twice as fast hardware run our software twice as fast.

Software went off the rails approximately when JavaScript became mandatory to display text on a webpage.

Software itself is the sacrifice of system optimization for human optimization. Give me unlimited human power and I'll give you purpose-designed chips for each individual use case with the program encoded in the wiring of the logic gates.

Software went off the rails following the advent of the downfall of the real IDE, the mouse and the web browser.

The browser is the big one, you're running an operating system inside of another.

The IDE not being able to target a true cross platform binary has hampered us.

The mouse has made developers lazy and et them put interfaces in clunky places.

(contradicting myself) Not using the mouse for coding anymore (see the downfall of the IDE)

And OS and browser vendors should have allowed binaries to run at a higher ring level, IE run something similar to dos inside of a browser, I would much rather cross compile to the major architecture than code in HTML/CSS/JS.

The Jevons Paradox applies here: As technology improves, cost goes down, which increases demand, which causes more of a given resource to be used, not less.

Everybody here says that "software bloats" but nobody says how it bloats. Why does chrome take 500mb to render a page? Where does that memory go.

Although it's great for campfire stories I don't really see a problem. Resources are there to be used - the lesson from StarCraft is you don't horde resources to victory. I think most believe this as how many of us are writing unikernel OSs purposed built for our hand tuned assembly backends

Just like roads and budgets the utilization will always grow to overflow.

Why did a bunch of open, unintelligent questions even get to the frontpage of HN? If this is the way one should think (ask questions we all on a low, unintelligent level agree are interesting) in order to become CTO, I will never get there...

//The Engineer

Ironic that your blog needs javascript to display a page.

Written in a blog that does not work with javascript off.

IMHO, there is no Software Engineering. There is only Computer Science. There is none of the discipline that comes from engineering, and only the messiness that comes from science. The heroes in software are Computer Scientists and everyone wants to be a Computer Scientist. No one wants to be a Software Engineer. It isn't even clear to me that Software Engineering exists in a clearly defined way. Maybe a manager or director imposes their will on a group somewhere and engineering is done.