food for thought: code bloat

[madires]

Code bloat has become astronomical: https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/

What do you think? Waste of energy and resources? Lazy software developers? Greedy managers, companies and shareholders?

[YurkshireLad]

Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.

[SiliconWizard]

It's rather easy to figure out where code bloat comes from, but the interesting point is indeed to consider how wasteful it ends up being as far as resources are concerned, especially in times where software is literally everywhere, and it's only going to get worse.

[bd139]

Bloat exists because it's currently cheaper to leave piles of shit everywhere than clean it up.

When performance or user experience suffers in any way then it will change.

There's a massive performance and energy usage wall coming up on the hardware side of things that will put the focus back on software efficiency.

[AndyBeez]

Good engineering is having the most efficient solution to meet the engineering problem. This is why there are for example, composite materials in mechanical engineering and large scale integration in electronic engineering. But in software engineering?

If you measure 'efficiency' in avation, planes get lighter, stronger and faster over time. In computing, software just gets heavier, slower and fractured with points of failure. Only advances in hardware keep the code bloat from sinking the proverbial airship.

Moore's law not only doubles speed and storage over time but by definition, doubles the amount that can be processed and stored. Ergo, more code can fit into the same space-time variable. More 64bit code to connect my anal-ytics to my anus-ytics in the metaverse fart cloud. Why, because someone else thinks my user experience needs that? Or maybe a case of built it and they will come? No, install that shite and I will find every freakin' way of cleansing it from my valuable SSD.

Once upon a home micro, the 1,786 bytes consumed by this single icon were enough to run a program. Now you need a server farm the size of Wyoming just to store all of the world's emojis!

Code bloat or the equivalent data puke, means we have far too many computer resources to know what to do with.

[SiliconWizard]

Keep in mind nobody knows if there's such a thing as software "engineering".
This has been an ongoing debate for decades.

[bd139]

Code bloat or the equivalent data puke, means we have far too many computer resources to know what to do with.

Sort of. At the moment, the constraining cost is energy. That's starting to burn the end users now.

Watch the race to the bottom on energy usage. Which is why ARM is popular suddenly.

Eventually the software will be the constraining factor.

Windows Defender probably has its own ozone hole at the moment 

[SiliconWizard]

Windows Defender probably has its own ozone hole at the moment 

[CatalinaWOW]

This is a problem in all forms of writing.  There is a famous quote attributed variously to Blaise Pascal, Mark Twain and Jane Austen among others.

"I don't have time to write you a short letter, so I am writing a long one."

It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.

[bd139]

I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.

[SiliconWizard]

One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?

I'm almost certain that the answer is a resounding NO, as the impact of software spreads in very large amounts contrary to that of developers, and also as we humans are surprisingly efficient in terms of energy consumption compared to most machines we ever designed.

[bd139]

It also depends on the impact of the software on society. The particular thing I am currently working on allows a whole specialist industry to remote work, thus reducing energy consumption on travel and office space. So really if we are inefficient we might be less inefficient than if we didn't exist.

Things get very complicated very quickly.

[CatalinaWOW]

The energy I was speaking of isn't measured with a wattmeter.  It is the will to do what is often a boring job with little recognition for success.

It appears that in bd139's anecdote time was the only one of three requirements available.

[brucehoult]

One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?

There's a big difference between software used by 10 people and software used by a billion people. For 10 people it's almost always going to be cheaper to buy them a faster machine. Each. It is at least actually a valid engineering and financial tradeoff.

It also depends on whether the costs of hardware to overcome software bloat are borne by the company itself (e.g. web servers) or by their customers (e.g. Microsoft Windows and Office).

[golden_labels]

In ending “the bloat” software devs are happy to follow EE: just lead the way! Stop using readily available and tested discrete components, which waste board space and underutilize characteristics. Instead roll out a new custom chip for each problem. Of course optimized so no watt or square millimeter is wasted.

Each time this kind of topic emerges, it’s not noticing equivalent phenomenon in one’s own domain⁽¹⁾, an ocean of blissful ignorance and attributing the situation to defects in someone’s character. There is a huge variance and, just like in any industry branch, there are extremes. So yes, there are cases like applications ran in embedded internet browser (Electron), similarly like there are barcode scanners built upon a computer running Windows with Internet Explorer for driving the display⁽²⁾ or solar roadways. But if you use extremes as the benchmark for the entire branch, you just deceive yourself.

You complain that in the past you could fit a program into 1kB and now it takes 1GB?⁽²⁾ I assure you that you still can go towards sub-megabyte code sizes, ignoring executable file structures and interfacing with the environment. You will also get exactly what you had back then, best pictured by that pixelated screenshot in the article. You will also pay as much as it costed back then and you may forget about ever having non-proprietary software. The quality and reliability will also be limited to the garbage-in-garbage-out philosophy, with “garbage in” being things you would nowadays thought as perfectly normal input.

The alternative is to understand how things actually work. Then you will grasp why, even with most perfect approach and hypothetical hyper-optimised software, for nearly all software products you will not reach improvement reaching even an order of magnitude. Or you may remain in the comfort zone of throwing shit, turning blind eye towards your own domain and imagining a world that never existed.

⁽¹⁾ Not surprising, as for your own domain you understand the situation and can explain the choices. Not so much for a process where you only see the final outcome.
⁽²⁾ Except for vendored software, which is a management issue forced upon developers, it does not. It’s like measuring size of your smartphone by including the power adapter. Some go as far as including the entire power plant.

[Siwastaja]

It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.

This is not the problem, it's the opposite. I'm positive that cutting the resources to 1/10th would reduce unnecessary bloat to 1/10th.

It's not about software project managers optimizing the costs, it's the problem of them not optimizing. Rather, the whole software "engineering" (whether that exists or not) is in a long-term crisis that is deep enough that people like managers do not know what is possible. They assume all that complexity is needed.

[Siwastaja]

In ending “the bloat” software devs are happy to follow EE: just lead the way! Stop using readily available and tested discrete components, which waste board space and underutilize characteristics. Instead roll out a new custom chip for each problem. Of course optimized so no watt or square millimeter is wasted.

Bad analogy. Better analogy is this:

You are designing a room thermostat which needs to click a relay to power a heater below certain temperature.

You have absolutely no idea how to do it, so you outsource ten full size server racks full of circuit boards. Each circuit board comes with a twenty 1000-pin connectors, from which 1000-wire flat cables run from random boards to other random board within this server room. What comes to the circuit boards - their designers did not know what to do, so they soldered in sub-boards, 42 per each main board. These sub-boards are then designed by yet another company, and each comes with either 1000 discrete transistors in SMD, some have 20 transistors in metal cans, some have a few electron tubes, and some come with FPGAs, for which the HDL is developed by yet another company.

The room thermostat finally requires a room of at least 50 square meters, and a 3-phase power supply of 3x100A, and compressed air, too. You can't just buy it, it needs to be custom ordered, and it takes 4 years of planning and 4 years of build to finally get it. During commission, the company is able to demonstrate the relay indeed clicks under well specified but untested circumstances, but it does not work after this demonstration. After extending the power supply to 3x200A, and building a new server room extension to the house within the next 3 years, the thermostat starts usually working, but over the weekends it stops working because the control room worker (who is now hired full time in the shack built in the backyard, did I mention?) is not able to make the required trimpot bias adjustments for over 24 hours. But this is not to worry, because it is usually fixed by Tuesday.

And every thermostat is built this way, because everybody thinks there is no any other way.

[Berni]

Yep computers are getting ever more powerful, but software is becoming inefficient at an even faster rate. So putting it all together computers are actually becoming ever slower for the end user.

Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM . And it worked well. It always ran fast, it had the software to do things like play back all modern video formats, render full desktop webpages(including ones with embedded flash), it could play Youtube. etc... Kept doing it for many years and still ran as snappy as on day 1. Every app i launched would start up and be ready in a second. Apps didn't even have a startup splash screen because they load so fast.

These days we have phones with multiple cores running well into the GHz clock speeds on much more powerful ARM processors in terms of work per clock cycle. Yet every single app needs a splash screen upon opening it because it takes multiple seconds for the app to load (otherwise the user would not know it is loading) and yet most apps don't do much that the old PDA could not do. Despite this new phone having easily 100x the computational power it's all so slow.

[bd139]

I think your understanding of the splash screen is probably wrong. That's a marketing interstitial mostly which can be optionally used to hit the network to try and get the initial screen if it needs it. Most of the apps on my phone at least don't have one and are 100% instant starting. My iPad, which is basically the same thing but bigger, is the only computer I've had that can actually keep up with me it's that fast.

As for windows mobile, I did a lot of development on that for POS and POD systems. I think you have some faulty memories there. It was painful at best.

[madires]

The alternative is to understand how things actually work. Then you will grasp why, even with most perfect approach and hypothetical hyper-optimised software, for nearly all software products you will not reach improvement reaching even an order of magnitude. Or you may remain in the comfort zone of throwing shit, turning blind eye towards your own domain and imagining a world that never existed.

Going to an extreme of hyper-optimization isn't realistic anyway. But there are plenty of opportunities to do things better. The blog post mentioned in the first post also talks about many soft devs never seen good and efficient code, causing them to produce bloat since they never learned other ways to design code. I've seen this also many times. Or in EE terms, if you need just a NAND gate use a 4093 and not a large FPGA just because you used that FPGA in your last project and you are familiar with it.

[SiliconWizard]

One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?

There's a big difference between software used by 10 people and software used by a billion people.

That was kind of implied in the following: "the impact of software spreads in very large amounts contrary to that of developers".
Of course if the number of users is not significantly greater than the number of developers, that becomes a particular case and the outcome can be different.
(The beauty of partial quotes =) )

For 10 people it's almost always going to be cheaper to buy them a faster machine. Each. It is at least actually a valid engineering and financial tradeoff.
It also depends on whether the costs of hardware to overcome software bloat are borne by the company itself (e.g. web servers) or by their customers (e.g. Microsoft Windows and Office).

The problem here is that you chose to look at it only from the development cost perspective, which is the most usual way of looking at software bloat (and engineering bloat in general when it applies.)

The interesting point that I found in this thread and which I was embarking on was the energy side of it. Not the development (or more generally "production") cost. The immediate cost is what everyone already knows about. Cost cutting is a cause here, not a consequence. In this thread, I was personally only talking about the consequences, not the causes, as I think the OP was also interested in.

And even the economic point of view is trickier than it appears. People tend to look at economy on very small scales and kinda treat it as though it was some magic. While if you look at the big picture, economy basically follows the rules of physics. Except in very groundbreaking (and now relatively rare) cases of managing to do things much more efficiently without any negative side-effect, whatever cost cutting you're managing to achieve is going to be paid somewhere else.

As to the point about developers favoring code bloat out of laziness and/or because their job is boring, that's fun and rather true in general, but that's again just talking about causes rather than about consequences.

Siwastaja pointed it out: the software industry has been in a deep, ongoing crising for decades now and despite numerous attempts, it's still in crisis.
bd139, working in that area as far as I got, is lucid and honest enough about it all that he recognizes how fucked-up it all is while admitting great money can be made out of it.

[madires]

Let's assume MS could make Windows twice as efficient. How much power could be saved in total?

[radar_macgyver]

Some of this may be generational, or following previous designs even when not appropriate.

Case in point, we had some folks visiting from a commercial company with a prototype of a radar they wanted to test alongside some of our equipment. Their RF guy was there to operate the system. He didn't have any software background, but was running code written by their software guy. My jaw dropped a couple of feet when I saw him spin up a docker instance (!!!) to acquire the data from an Ettus Research USRP SDR. Then there was another docker instance to process the data and Matlab to view it. WHY??? I could understand using Matlab for a quick prototype, but docker? Geez!

Sounds like their software dev was someone who had used docker for developing web stuff, and was asked to work on a data acq. system with the above results. They probably consider it either old fashioned or black magic to just write a program to connect to a TCP socket and store the data to disk.

[brucehoult]

Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM .

That is very fast and a lot of RAM!

When I was working in a small company writing and selling a J2ME to native compiler for Verizon phones in 2006 to 2008 the typical phone had a maybe 16 MHz ARM7TDMI (running on a 16 bit bus) and 400 KB to 2 MB of free RAM. Some of the lower end phones (and we had literally 200 different models in the office for testing purposes) were I think as low as 1 MHz to extend battery life.

[Berni]

Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM .

That is very fast and a lot of RAM!

When I was working in a small company writing and selling a J2ME to native compiler for Verizon phones in 2006 to 2008 the typical phone had a maybe 16 MHz ARM7TDMI (running on a 16 bit bus) and 400 KB to 2 MB of free RAM. Some of the lower end phones (and we had literally 200 different models in the office for testing purposes) were I think as low as 1 MHz to extend battery life.

Yep this was around 2006 era and these ware the 'flagship' devices so they had an impressive amount of mobile processing power for the time. Also ran on Intels ARM CPUs back when they still made them. That 133MHz OMAP ARM was in a  Motorola MPX200 was i think from the 2003 era.

I think your understanding of the splash screen is probably wrong. That's a marketing interstitial mostly which can be optionally used to hit the network to try and get the initial screen if it needs it. Most of the apps on my phone at least don't have one and are 100% instant starting. My iPad, which is basically the same thing but bigger, is the only computer I've had that can actually keep up with me it's that fast.

As for windows mobile, I did a lot of development on that for POS and POD systems. I think you have some faulty memories there. It was painful at best.

Maybe it was because i was running WindowsMobile on the more powerful hardware of the time.

I did some development on it too, but that was once the .Net framework was running on them. This made software development on it almost as easy as making regular Windows apps on Win XP. The resulting executable would even run perfectly fine on Windows XP and on WindowsMobile.

That being said not all apps on Android are dog slow. Some of the small apps made by single developers (Like TotalComander for Android) start instantly and keep running responsively throughout its use. Yet quite a lot of bigger modern apps take >5 seconds to launch from a cold start and then often hang the UI for 1 second when pressing some buttons. Sure my phone is a midrange device from 5 years ago, but with how much computational power they carry, drawing a responsive UI should NOT be this hard of a task.