The longer I write software, the more my sense of “impressive” changes. What actually amazes me these days isn’t modern technology, but older syste...
For further actions, you may consider blocking this person and/or reporting abuse
That is the negative consequence of over-provisioning.
Developers get fast machines and fast internet connections, and then they assume everyone else has access to the same means.
The same is happening with hosting, even websites that are local want fast page loads on the other side of the world. And because of hyperscalers like AWS, Azure and Google cloud it is possible.
Don't get me started on AI, people are expected to have multi gigabyte models on every device they own.
The tech industry needs to do less disrupting and add more value.
"Re-introduce constraints intentionally" is the key phrase. And you're spot on—the platforms that host this software share the responsibility. True innovation from hyperscalers wouldn't just be more power, but tooling that rewards leanness and helps us build software that's fast because it's efficient, not just because it's running on a beast!
We loved your post so we shared it on social.
Keep up the great work!
Let's spread the gospel
Running 500K+ API calls daily taught me this the hard way. Switched to Cloudflare Workers because the platform forces discipline—tight CPU limits, pay-per-request billing. Can't be wasteful when the edge punishes bloat. Constraints aren't nostalgia, they're competitive advantage.
Got it!
This is striking, but I believe that incentives are completely out of date rather than developers losing manners. Most teams are rewarded for meeting deadlines and satisfying stakeholders rather than for efficiency or restraint. It is difficult to advocate for discipline when frameworks and deadlines essentially penalize it. Fixing this seems to begin at the organizational level rather than with individual developers attempting to be purists.
On spot. The atmosphere we code in! The air we breath
I agree with your points. I would like to add another factor to the problems of modern software development: the dynamics of capitalism. I know it sounds like a bold statement, but in times of software abundance, the race to be "first" becomes overwhelming. I believe the flow of money is driven by this mechanism. The Windows system, in my opinion, corroborates this. As far as I know, Windows wasn't considered a high-quality product, but it became very popular for various reasons. This "popularity" made money flow to Microsoft, and this was an important factor in developing a better product. Not all software follows this logic (Linux, for example), but if we restrict ourselves to software in the context of companies and businesses, being first makes all the difference. Therefore, to me, it seems that software development faces a lot of pressure to be "ready" as quickly as possible, even at risk, and then we have to deal with the problems and technical debt. Unfortunately.
Good point. It reminds me of @doogal example about prototypes vs. core systems.
The real issue is: do our development phases include a culture of cleanup? A prototype might not need to be lean, but is there ever a planned stage to pay down that debt before it becomes production bloat? Too often, the "temporary" solution becomes permanent because the business incentive to refactor it never arrives.
I think there is a balance to be struck that needs to be aware of the unique context that an application is being developed in.
We need to be thinking about the financials of the business we are working for because ultimately, that is why we are being paid. That business survival or not can be helped by the trade-offs we make.
We generally need to deliver software fast enough that the business can make money, if we deliver it in a poor state, then it can become unstable or the speed of delivery after the first couple of releases can drop as we get mired in technical debt.
The way I tend to approach it is by being deliberate about the "low-quality" parts of a product, put a higher quality facade around something that is hacky. Generally the facade is very quick to make, you still deliver on time and then you have a decent interface that you can use to isolate the hacky bits and dealing with them becomes a much more manageable endevour.
For example, say we are building a T-shirt ordering application, we know roughly that we want to have requirements for taking payment, telling the warehouse to ship the T-shirt and emailing the user. Each one of those 3 tasks could be written as very hacky scripts as long as they have been isolated from one another with a reasonable interface. Then dealing with the technical debt becomes a much more concrete conversation about improving the email system, rather than refactor the whole application
I'm from the generation of UK spectrum bedroom coders, and when I first studied computer programming, we were marked on things such as:
When that started to change, and coding became easier because you didn't have to work within constraints, I lost interest in computers for over 20 years.
It would be nice to see it return.
PS: 1k ZX Chess, written for the ZX81 is, for me, the best computer code written. A chess game, with a computer opponent, in just 672 bytes 🎯
what we lost
This is like a gale of fresh air. Back in the 80s I ran a small dev team sharing an Altos Xenix computer with, IIRC, 128Kb of memory, developing in MF COBOL. As our target platform was IBM PCs one of the acceptance tests was that the application should load and execute in 64Kb.
Them was the days my friend!
Them days, wish we could go back
Thanks for your post! I mostly agree, but it's funny that you cite Windows 95 as a good example, that unstable pre-NT desktop operation system built on top of MS-DOS that needed 9 floppy disks to install. Software like Windows 95 was one of the reasons that the Linux community developed desktop environments, because developers were craving for stable alternatives to Microsoft, and Steve Jobs hadn't yet decided to bring his NeXT step ideas back to Apple.
I appreciate memory saving and efficiency right now and back then, but I'd rather point to home computer game development in the 1980s or the 1990s demo scene instead. Now you can retort and point out what an idiosyncratic chaos Commodore assembly development meant ;-)
Haha, excellent and fair critique! I was using Windows 95 more as a shocking reference for scale, not stability—but your point stands!. The real craft was indeed in the demo scene, game devs, and early Unix communities working under extreme limits. It’s precisely that mindset we’ve drifted from. And you nailed the irony: today's Linux, in many forms, consumes far beyond what its pioneers imagined. The spirit of minimalism they fought for has been overshadowed by convenience!
As an eight-year Linux user, the painful irony is watching the ecosystem recreate the bloat it opposed. Even after applying limits; browsers and CLI tools crash from pure memory bloat on an 8GB RAM! That was an entire server in those days—no complex logic, just waste. That's the tangible price of the discipline we've lost.
I always was thinking, why we reinvent the wheel. Things may be overhauled, but not at the cost of a browser that eats up CPU resources and memory. When I started with my current main open source projets's language, it was about Windows 3.1. I know about the stuff - I don't really need AI to do my job :-)
Love this!
You're the software developer friend I've never had. We should be friends! Ha
But seriously, I spent years mentoring developers on efficiency. It's a lost art form on enterprise applications (at least where I've been). Now I see 10 microservices built for products handling 1000s of requests per DAY (not second). And it feels like a complete waste. It's not efficient with memory, CPU or IO usage. But more than that it's not efficient for the devs either, or the support staff. It feels like wasted productivity...
However, I also understand that sometimes efficiency comes at the cost of training and man hours and thus businesses tend to reward speed over efficiency. Resources aren't a constraint anymore (not until budget season) and so businesses have trained developers this way. There are still efficiency driven developers and when done well they're praised but overall Software is not forced into the same level of discipline as other engineering disciplines like electrical, mechanical, or industrial engineering. When you mess up on a circuit design and it gets to production, it can cost 100s of thousands of $$ to fix requiring better discipline up front.
I wish we could find a way to create that same level of discipline with Software where that high schooler that learned how to program python last weekend, doesn't think he's a genius because he made something work... but hey that's just me.
Brilliant analogy. We need to make software waste as tangible as a burned PCB.
Consider me a friend!
Sorry, but you are just plain wrong. This has nothing to do with manners. It had to do with priorities. When there is a choice between big fixes and new features or lower ram usage, the team usage will lose every time as long as ram is not the main contraint. We all dream of the perfect program but in most cases there is no such thing. There are a series of tradeoffs and budget constraints and design choices for and bad. Technical debt is a real problem that is typically not well handled by most modern organisations as it rarely takes precedence over new features. But when ram or performance are critical, I can assure you that there are programmers that still know how to run code in very minimal ram. Rust code for example is typically much more efficient than JavaScript but that benefit also comes at a very real cost that has nothing to do with manners
You're right—it's priorities. But those priorities are shaped by a culture that has stopped valuing the craftsmanship you're describing.
When you work close to the metal—financially, operationally, emotionally—you cannot rely on the system to catch your slack. Your habits are the system.
That foundational friction teaches lessons no framework ever can.
This really resonates with me. I’ve been building software for a long time, and I recognise that shift you’re describing — from being careful and intentional, to assuming the machine (or the cloud) will just absorb whatever we throw at it.
A big reason I created myapi.rest was actually because of this. I kept seeing teams re-implementing the same small utilities over and over, often in rushed ways, with little thought for performance, limits, or long-term maintenance. It felt… a bit careless.
For me, software manners is about respect — for the system, for the next developer, and for the future version of yourself. Even when things are “cheap” or abstracted away, I still believe there’s value in doing the small things thoughtfully.
You scored it!
I think your post brings a few interesting topics up.
There is probably a balance to be struck between importing the world with little regard to consequences, and optimizing performance down to the last byte.
Different applications in different contexts will probably land on different points on this spectrum, for example if we are building a prototype webapp to show a concept to a user, it would probably be on the less optimised with less good "manners".
Whereas an application where the concept is more concrete and the focus is on delivering performance that is good enough for now and the new couple of years would probably fall closer to the other end with better manners and more optimisation.
Sometimes even within the same application you might have different parts at different points on the spectrum, say we are a company whose USP is being an insurance broker. We'd probably want to make sure that the insurance broker bit of our application was put together very well and we spend most of our time there, vs spending less time building supporting functions like an Admin UI, or Reporting, we'd still have them to a good enough quality, but probably use more off the shelf type tooling for those bits as that is not where there core of our business is.
Spot on—it's all about context and conscious choice on that spectrum.
My major concern is the loss of that awareness. We default to "import the world" even for critical production systems, forgetting to respect the user's resources. It’s not about optimizing every prototype; it’s about ensuring the broker's engine doesn’t fail because of bloat, forcing the user to upgrade hardware in a few years. That's the line between a strategic compromise and accidental bloat.
Totally agree with your pragmatic take.