Bloat, the burning of unnecessary computer resources, is a symptom of a lack of knowledge.
Most people are not deliberately trying to make their code resource-inefficient. It’s just that they have a job to do, and they know just enough to get it barely done. Extras like bloat, security, and extendability are off the table. To handle them properly requires knowledge they do not have, nor the time to acquire it.
There are infinite ways to accomplish any task with a computer. But these days they are all wrapped in inconsistent primitives or calls which are often quite messy. If you understand what’s really below that level, you can figure out how to utilize it to do only exactly what you want. But if you don’t really understand how they work, you're left chaining them together and fiddling until the output approximates your goals.
This has been understood since the 60s, often called the software crisis. The higher we build the house of cards, the more disconnected each new generation gets from what's holding it all up.
The rise of don’t look before you leap philosophies of development fuelled the problem. Coders are in such a panic rush that they just have to grasp at what is easiest, but combined with tunnel vision, that is also usually what is pretty wasteful too.
If you’ve got some fiddling to do with a string, then most people pick the most popular primitives. When they realize that the combination does a bit of extra work, they discount it as a micro-optimization. It’s not; it's a lack of knowledge driving the deoptimization or bloat, as we like to call it.
If they knew more about how it worked underneath, they’d pick a different set and augment that with better code of their own. The output would be the same, but the wasted steps would be gone. They weren’t needed.
That’s a trivial example, but we see this with fiddling, calling libraries and APIs, allocations, polling, queuing and caching, pretty much all over the place. There is some reasonable way to encode the steps, but getting there requires understanding what the steps actually do. Not a guess or a vague understanding, but not enough knowledge to be able to implement them yourself.
Q&A sites fuel this, because they give people a magic sequence, thus offering them the option to just blindly use it.
If you knew better, most people would choose to write the code properly; it doesn’t take more time. If they write bloated stuff, it is because they didn’t know better.
When computers were really slow, bloat was obvious and often unworkable. As Moore’s law kicked in, bloat became just another consequence of the race to get more code out there. But as Moore’s law fades, we'll be forced to return to those early days when people coded with more precision. To do that, they’ll need depth. You can’t correctly pick the best underlying steps if you have no idea what’s actually underneath. Figuring that out will keep you ahead of the pack.
Thursday, October 1, 2026
Thursday, September 24, 2026
Webapps
In the early days of the Web, people struggled to make websites more dynamic. The original web technologies were centred around static presentations; they were pretty good at this.
As the trends matured, more and more technologies became available to make the sites dynamic, but also to use them to essentially wrap other programs and systems. The web interface was born; people gave these the cool name of webapps.
In those days, most serious developers continued to produce native GUIs. The web technologies seemed hokey and crude. Many were just mindless fronts that called the real stuff in the back. Light clients calling APIs.
The problem with native apps was portability. There were more operating systems back then, and it was crazy expensive to rewrite the same program for each one. The technologies for writing stuff once and getting it to run everywhere were a great idea, but the implementations were generally too limited to be useful.
What the web promised, though, was a guaranteed way to avoid portability problems. These promises, however, were quickly disrupted by the browser wars and by the emergence of mobile devices.
That led to a huge wave of ‘frameworks’ that all promised portability across all of these different platforms and form factors. Initially, they helped; webapps grew a little more sophisticated. But somewhere along the way, they all got pretty convoluted. Suddenly crafting a reasonable webapp was a whole lot more effort than just crafting native apps. That bump in complexity was rewarded with a visible drop in quality. Webapps started to become extremely buggy.
The browsers themselves grew in sophistication, but their integration was compromised by huge security failures. The web became a free-for-all for scams, driving a lot of people into silos.
They are still just a limited window into some features, but most of the ways to extend them are too fiddly to be practical.
So we’re left with most interfaces starting on browsers, then getting mobile cousins, then maybe better native versions. Oddly ironic since, except for form factor, they're all a bunch of interactions on a whack load of widgets. The foundations for graphical user interfaces haven’t changed for decades, just after the client/server split. All of these modern technologies trace a close lineage to their earlier generations.
If we were going to rethink this, it would be to go way back to the portability days. We’d still like to write one set of code that covers all three locations, pushing each right to its limits. That is, you’d grab a webapp you like, run it natively, and it would save your files locally. If you run it on a phone, it would give you the option of local or hosted.
If you can wire in optional platform capabilities and some dynamic form factor support, then you really could return to a point where writing interfaces wasn’t the bulk of the development effort. If it was near trivial to dump out 80% of the boring screens in a few days, then you could spend more time deciding which widget arrangements were best suited for which tasks, rather than expensive widget/presentation wiring and refactoring.
Webapps suck. They almost didn’t, but then fate intervened. We don’t need more siloed clumps of monetizable half-baked features; we have enough already. We need better adaptive and integrated tools that allow us to spend less time on computers, not more. The answer to this is not probabilistic personalized interface generation; more opaque, crappy code will only make things worse. It is to rework our foundations and get back to some of the great ideas of the past that we skipped over too quickly.
As the trends matured, more and more technologies became available to make the sites dynamic, but also to use them to essentially wrap other programs and systems. The web interface was born; people gave these the cool name of webapps.
In those days, most serious developers continued to produce native GUIs. The web technologies seemed hokey and crude. Many were just mindless fronts that called the real stuff in the back. Light clients calling APIs.
The problem with native apps was portability. There were more operating systems back then, and it was crazy expensive to rewrite the same program for each one. The technologies for writing stuff once and getting it to run everywhere were a great idea, but the implementations were generally too limited to be useful.
What the web promised, though, was a guaranteed way to avoid portability problems. These promises, however, were quickly disrupted by the browser wars and by the emergence of mobile devices.
That led to a huge wave of ‘frameworks’ that all promised portability across all of these different platforms and form factors. Initially, they helped; webapps grew a little more sophisticated. But somewhere along the way, they all got pretty convoluted. Suddenly crafting a reasonable webapp was a whole lot more effort than just crafting native apps. That bump in complexity was rewarded with a visible drop in quality. Webapps started to become extremely buggy.
The browsers themselves grew in sophistication, but their integration was compromised by huge security failures. The web became a free-for-all for scams, driving a lot of people into silos.
They are still just a limited window into some features, but most of the ways to extend them are too fiddly to be practical.
So we’re left with most interfaces starting on browsers, then getting mobile cousins, then maybe better native versions. Oddly ironic since, except for form factor, they're all a bunch of interactions on a whack load of widgets. The foundations for graphical user interfaces haven’t changed for decades, just after the client/server split. All of these modern technologies trace a close lineage to their earlier generations.
If we were going to rethink this, it would be to go way back to the portability days. We’d still like to write one set of code that covers all three locations, pushing each right to its limits. That is, you’d grab a webapp you like, run it natively, and it would save your files locally. If you run it on a phone, it would give you the option of local or hosted.
If you can wire in optional platform capabilities and some dynamic form factor support, then you really could return to a point where writing interfaces wasn’t the bulk of the development effort. If it was near trivial to dump out 80% of the boring screens in a few days, then you could spend more time deciding which widget arrangements were best suited for which tasks, rather than expensive widget/presentation wiring and refactoring.
Webapps suck. They almost didn’t, but then fate intervened. We don’t need more siloed clumps of monetizable half-baked features; we have enough already. We need better adaptive and integrated tools that allow us to spend less time on computers, not more. The answer to this is not probabilistic personalized interface generation; more opaque, crappy code will only make things worse. It is to rework our foundations and get back to some of the great ideas of the past that we skipped over too quickly.
Thursday, September 17, 2026
Oversimplication
For a long time, the software industry turned against sophisticated power techniques like abstraction.
Partly because getting a little abstract is difficult for some people, but also because it slows down the number of lines they can grind. As an added bonus, it is a bit harder to debug.
People felt that rapidly churning out super simple, near-trivial, brute force code was the best approach.
Strangely, though, a great deal of the actual foundation of software rests on some pretty complex abstractions. Little of what is now possible with computers would be there or work properly if it didn’t. A lot of that code came from an age when people still cared about getting it correct. It’s not ‘legacy’, it’s ‘classic’.
As I watched these oversimplification trends take hold and gain strength, I was getting increasingly worried about the frailty of all of the software that we depend on. Everything is so buggy these days that it’s a wonder that anything works. A few decades back, people would dispute that claim and say it was crazy, but now it’s way worse and so obvious the tables have turned.
There are plenty of known problems out there where any and all attempts to brute-force some crude logic will fail. The scary part is that it may not ‘completely fail’. It may just look like it’s working, work some of the time, but then fail right in the middle of consequential moments.
Software has many essentially ‘physical’ boundaries. You can’t do anything to get past them; they are hard and fast limits. It’s also not particularly malleable, and certainly gets rapidly less malleable as the codebase grows. The crap at the bottom gets frozen there as more stuff gets piled on top. A digital form of gravity, I guess.
Any sort of ‘just jump in and pound it out’ philosophy is a recipe for failure. By the time you’ve clued into your most obvious mistakes, and there will be obvious mistakes, it is too late to go back and fix them. Then building on top of that shaky mess is doomed.
If the problem you are trying to solve is complicated, then any viable real solution to that problem is at least equally complicated. We’ll call this the equality rule.
Techniques like abstraction and generalization are the only means to take that unmanageable complexity and bring it down to a reasonable level where you can implement it correctly. All your other attempts to ‘hack through’ the issues are just a waste of time.
But some people are often so focused on trying to create the simplest solution possible that they end up ignoring the problem they are trying to solve. So, it’s disconnected. The solution is wonderful, but useless.
Instead, it’s way better to go grab a sheet of actual paper and start writing out any proposed solution first. Sketch some mechanics. Think of it as modelling clay, like what they use for car design. Then take that proposed solution and go back to properly explore the problem. If they don’t match up, go back to the design board. A sketch in time saves buckets of wasted coding. It’s orders of magnitude faster than coding up a bad solution, throwing it away, coding up another, throwing that away, ad nauseam.
Grungy coding habits like that are oddly okay for demos and quick prototypes, but it only works because the code is tiny. Scale screws with everything, and any code that is good enough will always grow. Maybe we should call that the destiny rule. If the code kinda works, then it is fated for continued expansion until it doesn’t work anymore.
The oddest part, though, is that the motivation to keep it simple is great. The thing should be as simple as possible; it’s just that any distance way over or way under that bar is exponentially worse. You need to hit the bar, and that bar is positioned by the equality rule.
If there is any sort of method to the madness, it is to start simple. But know immediately that it is too oversimplified. Bad design. Keep going back to the problem to figure out why it won’t work in specific situations. Put those complexities carefully back into the design. Iterate, over and over again.
If you think that might take too long, and you really don’t have decades to catch up with the state of the art, the shortcut is not to ignore the problem, but rather to jump out and do some reading on the state of the art. Leverage what other people have already figured out. Read a bit, learn a lot. Revise what you actually think simple really means. Know that if a kink in the problem space stumbles too close to a boundary, then find the best fit possible within your timeframe to actually address it, or at least carve out some space for it to be corrected later.
What you don’t want to do is hobble something together out of components you barely understand. While that keeps your code simple, what rests below explodes with overcomplexity.
It’s worth noting that the crazy balancing act necessary for modern software design is not something you can learn instantaneously. Because of this, the fastest way to gain knowledge is always mentoring. Get on a good project, work with good teams, and get someone who knows a bit to explain their rationale. Don’t be skeptical, at least not at first. Everyone is wrong, but some people are less wrong, thus closer to the knowledge you are seeking.
While it's tempting to believe that there is always a simple software solution for everything, it’s been proven incorrect so many times that it has become boring and forgotten, again and again. If you want to build software that really solves people’s problems for them, then that software has to really solve people’s problems for them. If their problems have become crazy complicated, then it’s obvious that anything simple will not even come close to fitting properly. I really should call ‘the equality rule’ a law or something...
Partly because getting a little abstract is difficult for some people, but also because it slows down the number of lines they can grind. As an added bonus, it is a bit harder to debug.
People felt that rapidly churning out super simple, near-trivial, brute force code was the best approach.
Strangely, though, a great deal of the actual foundation of software rests on some pretty complex abstractions. Little of what is now possible with computers would be there or work properly if it didn’t. A lot of that code came from an age when people still cared about getting it correct. It’s not ‘legacy’, it’s ‘classic’.
As I watched these oversimplification trends take hold and gain strength, I was getting increasingly worried about the frailty of all of the software that we depend on. Everything is so buggy these days that it’s a wonder that anything works. A few decades back, people would dispute that claim and say it was crazy, but now it’s way worse and so obvious the tables have turned.
There are plenty of known problems out there where any and all attempts to brute-force some crude logic will fail. The scary part is that it may not ‘completely fail’. It may just look like it’s working, work some of the time, but then fail right in the middle of consequential moments.
Software has many essentially ‘physical’ boundaries. You can’t do anything to get past them; they are hard and fast limits. It’s also not particularly malleable, and certainly gets rapidly less malleable as the codebase grows. The crap at the bottom gets frozen there as more stuff gets piled on top. A digital form of gravity, I guess.
Any sort of ‘just jump in and pound it out’ philosophy is a recipe for failure. By the time you’ve clued into your most obvious mistakes, and there will be obvious mistakes, it is too late to go back and fix them. Then building on top of that shaky mess is doomed.
If the problem you are trying to solve is complicated, then any viable real solution to that problem is at least equally complicated. We’ll call this the equality rule.
Techniques like abstraction and generalization are the only means to take that unmanageable complexity and bring it down to a reasonable level where you can implement it correctly. All your other attempts to ‘hack through’ the issues are just a waste of time.
But some people are often so focused on trying to create the simplest solution possible that they end up ignoring the problem they are trying to solve. So, it’s disconnected. The solution is wonderful, but useless.
Instead, it’s way better to go grab a sheet of actual paper and start writing out any proposed solution first. Sketch some mechanics. Think of it as modelling clay, like what they use for car design. Then take that proposed solution and go back to properly explore the problem. If they don’t match up, go back to the design board. A sketch in time saves buckets of wasted coding. It’s orders of magnitude faster than coding up a bad solution, throwing it away, coding up another, throwing that away, ad nauseam.
Grungy coding habits like that are oddly okay for demos and quick prototypes, but it only works because the code is tiny. Scale screws with everything, and any code that is good enough will always grow. Maybe we should call that the destiny rule. If the code kinda works, then it is fated for continued expansion until it doesn’t work anymore.
The oddest part, though, is that the motivation to keep it simple is great. The thing should be as simple as possible; it’s just that any distance way over or way under that bar is exponentially worse. You need to hit the bar, and that bar is positioned by the equality rule.
If there is any sort of method to the madness, it is to start simple. But know immediately that it is too oversimplified. Bad design. Keep going back to the problem to figure out why it won’t work in specific situations. Put those complexities carefully back into the design. Iterate, over and over again.
If you think that might take too long, and you really don’t have decades to catch up with the state of the art, the shortcut is not to ignore the problem, but rather to jump out and do some reading on the state of the art. Leverage what other people have already figured out. Read a bit, learn a lot. Revise what you actually think simple really means. Know that if a kink in the problem space stumbles too close to a boundary, then find the best fit possible within your timeframe to actually address it, or at least carve out some space for it to be corrected later.
What you don’t want to do is hobble something together out of components you barely understand. While that keeps your code simple, what rests below explodes with overcomplexity.
It’s worth noting that the crazy balancing act necessary for modern software design is not something you can learn instantaneously. Because of this, the fastest way to gain knowledge is always mentoring. Get on a good project, work with good teams, and get someone who knows a bit to explain their rationale. Don’t be skeptical, at least not at first. Everyone is wrong, but some people are less wrong, thus closer to the knowledge you are seeking.
While it's tempting to believe that there is always a simple software solution for everything, it’s been proven incorrect so many times that it has become boring and forgotten, again and again. If you want to build software that really solves people’s problems for them, then that software has to really solve people’s problems for them. If their problems have become crazy complicated, then it’s obvious that anything simple will not even come close to fitting properly. I really should call ‘the equality rule’ a law or something...
Subscribe to:
Posts (Atom)