We are destroying software
antirez.com
antirez.com
1. Good design is innovative
2. Good design makes a product useful
3. Good design is aesthetic
4. Good design makes a product understandable
5. Good design is unobtrusive
6. Good design is honest
7. Good design is long-lasting
8. Good design is thorough down to the last detail
9. Good design is environmentally-friendly
10. Good design is as little design as possible 1. Good design is innovative
UNIX innovated by simplifying Multics -
throwing away ring security and PL/I's memory safety features.
Linux innovated by cloning UNIX, giving it away for free,
and avoiding the lawsuit that sidelined BSD.
2. Good design makes a product useful
Yet somehow people managed to use UNIX anyway.
3. Good design is aesthetic
UNIX threw away clear, long-form command forms and kept
short, cryptic abbreviations like "cat" (short for "felis cattus")
and "wc" (short for "toilet").
Its C library helpfully abbreviates "create" as "creat",
because vowels are expensive.
4. Good design makes a product understandable
See #3
5. Good design is unobtrusive
That's why UNIX/Linux enthusiasts spend so much time
configuring their systems rather than using them.
6. Good design is honest
The UNIX name indicates it is missing something
present in Multics. Similarly, "Linux" is the
gender-neutralized form of "Linus".
7. Good design is long-lasting
Like many stubborn diseases, UNIX has proven hard to eradicate.
8. Good design is thorough down to the last detail
UNIX/Linux enthusiasts love using those details
to try to figure out how to get Wi-Fi, Bluetooth,
and GPU support partially working on their laptops.
9. Good design is environmentally-friendly
Linux recycles most of UNIX's bad ideas, and many
of its users/apologists.
10. Good design is as little design as possible
Linux beats UNIX because it wasn't designed at all.https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
Implementation simplicity meant one important thing: Unix could be quickly developed and iterated. When Unix was still new, this was a boon and Unix grew rapidly, but at one point backward compatibility had to be maintained and we remained with a lot of cruft.
Unfortunately, since implementation simplicity and development speed nearly always took precedence over everything else, this cruft could be quite painful. If you look at the C standard library and traditional Unix tools, they are generally quite user hostile. The simple tools like "cat" and "wc" are simple enough to make them useful, but most of the tools have severe shortcomings, either in the interface, lack of critical features or their entire design. For example:
1. ls was never really designed to output directory data in a way that can be parsed by other programs. It is so bad that "Don't parse ls" became a famous warning for shell script writers[1].
2. find has a very weird expression language that is hard to use or remember. It also never really heard about the "do one thing well" part of Unix philosophy and decided that "be mediocre at multiple things" is a better approach. Of course, finding files with complex queries and executing complex actions as a result is not an easy task. But find makes even the simplest things harder than they should be.
A good counterexample is "fd"[2]. You want to find that has a "foo" somewhere in its name in the current directory and display the path in a friendly manner? fd foo vs find . -name 'foo' -Printf "%P\n". What to find all .py files and run "wc -l" on each of them? fd --extension py --exec wc -l (or "fd -e py -x wc -l" if you like it short). "Find requires you to write find . -name '*.py' -exec wc -l {} ;". I keep forgetting that and have to search the manual every time.
Oh, and as a bonus, if you forget to quote your wildcards for find they may (or may not!) be expanded by the shell, and end up giving you completely unexpected results. Great foolproof design.
3. sed is yet another utility which is just too hard to learn. Most people use it as mostly as a regex find-and-replace tool in pipes nowadays, but its regex syntax is quite lacking. This is not entirely sed's fault, since it predates Perl and PCRE which set the modern standard for regular expressions that we expect to more or less work the same everywhere. But it is another example of a tool that badly violates the principles of good design.
The Unix Haters Handbook is full of many more examples, but the reality is that Unix won because other OSes could not deliver what their users needed fast enough. Unix even brought some good ideas to the mass market (like pipes) even if the implementation was messy. We now live under the shadow of its legacy, for better or worse.
But I don't think we should idolize the Unix philosophy. It is mostly a set of principles ("everything is a file", "everything is text" and "each tool should do one job", "write programs to work together") that was never strictly followed (many things in UNIX are not files, many commands do multiple jobs, most commands don't interact nicely with each other unless you just care about opaque lines). But most importantly, the Unix philosophy doesn't extend much beyond designing composable command line tools that handle line-oriented text for power users.
Only rule 7. and 9. are measurable and not purely subjective.
Why?
Maybe it's meant in an artistic sense, but under an engineering one I just don't see it.
> Everything is a file
“Good design is as little design as possible” ok cool but I have 30 different feature requests coming in every week from actual users, that doesn’t really help me make concrete design decisions
“Good design is aesthetic” whose aesthetic? Aesthetic is extremely cultural and arbitrary, my designers are fighting over whether a photorealistic leather texture is more aesthetic than a gradient texture background, how does that help?
“Good design makes a product useful” uh yeah okay I’ve never had a design problem that was solved by someone saying “you know what, we should just make this product useful” “oooh right how did we not think of that”.
I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable in my 15+ years working as a designer.
https://www.vitsoe.com/us/about/good-design#good-design-is-i...
You write software for a company so someone will give them money for it or so the company can save money
Everything else takes a backseat to that core mission. The first goal when writing software is to efficiently get to a point where one of those goals can be met.
It makes no sense to polish software if you are going to run out of money before it gets released, management cuts funding or you can’t find product market fit to convince investors to give you money depending on what your goal is.
Code doesn’t always need to be long lasting, you can’t predict how the market will change, how the underlying platform will change, when a better funded competitor will come in and eat your lunch, etc.
Good design doesn’t need to be “innovative”. It needs to fit within the norms of the platform or ecosystem it is part of.
We had our own internal load balancer, web servers, mail servers, ftp servers to receive and send files, and home grown software.
Now I could reproduce the entire setup within a week at the most with some yaml files and hosted cloud services. All of the server architected is “abstracted”. One of the things he complains about.
As far as backwards compatibility, worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is. Even back in the mid 2000s there was over a dozen ways to represent a string when programming and you had to convert back and forth between them.
Apple has been able to migrate between 5 processors during its existence by breaking backwards compatibility and even remove entire processing subsystems from ARM chips by removing 32 bit code compatibility.
Windows is a shitshow beacuse the leadership is chaotic, dragged all around all the time, never finishing nothing well. They only survived because of backward compatibility! Building on the unlikely success in the 90s.
Also, why do I have to install new software in every couple of months to access my bank account, secure chat, flight booking system, etc., etc., without any noticable difference in operation and functionality. A lot of things unreasonably becoming incompatible with 'old' (we are talking about months for f's sake!!) versions. That's a nuisance and erosion of trust.
Web actually excels here because you can use service workers to manage versioning and caching so that backwards compatibility is never a concern.
Are you talking about security updates?
All of that has been solved by the web at this point.
You say Windows is a shit show, but as someone who has developed a lot on both Windows and Linux, Linux is just as much a shit show just in different ways.
And it's really nice being able to trust that binaries I built a decade ago just run on Windows.
Wouldn't this need be solved by an emulator of older architectures?
There would be a performance cost, but maybe the newer processors would more than make up for it.
I would consider myself an Apple evangelist, for the most part, and even I can recognize what's been lost by Apple breaking backwards compatibility every time they need to shift direction. While the philosophy is great for making sure that things are modern and maintained, there is definitely a non-insignificant amount of value that is lost, even just historically but also in general, by the paradigm of constantly moving forward without regard for maintaining compatibility with the past.
They could have stuck with x86 I guess. But was moving to ARM really a bad idea?
They were able to remove entire sections of the processor by getting rid of 32 bit code and saving memory and storage by not having 32 bit and 64 bit code running at the same time. When 32 bit code ran it had to load 32 bit version of the shared linked library and 64 bit code had to have its own versions.
This is my personal bugbear, so I’ll admit I’m biased.
Infrastructure abstractions are both great and terrible. The great part is you can often produce your desired end product much more quickly. The terrible part is you’re no longer required to have the faintest idea of how it all works.
Hardware isn’t fun if it’s not working, I get that. One of my home servers hard-locked yesterday to the point that IPMI power commands didn’t work, and also somehow, the CPUs were overheating (fans stopped spinning is all I can assume). System logs following a hard reset via power cables yielded zero information, and it seems fine now. This is not enjoyable; I much rather would’ve spent that hour of my life finishing the game of Wingspan.
But at the same time, I know a fair amount about hardware and Linux administration, and that knowledge has been borne of breaking things (or having them break on me), then fixing them; of wondering, “can I automate X?”; etc.
I’m not saying that everyone needs to run their own servers, but at the very least, I think it’s an extremely valuable skill to know how to manage a service on a Linux server. Perhaps then, the meaning of abstractions like CPU requests vs. Limits will become clear, and disk full messages will cause one to not spam logs with everything under the sun.
I have done all of this myself with on prem servers that I could walk to. I know exactly what’s involved and it would be silly to do that these days
Linux is a far bigger shit show. At least at the platform level. Windows is a lesser shitshow at the presentation layer
It’s more about x86. Using an x86 laptop feels archaic in 2025. Compared to my M2 MacBook Air or my work M3 MacBook Pro.
The only thing that makes MacOS much better for me is the ecosystem integration
Not entirely, there are other reasons too
But we should respect semantic versioning. Python is a dreadful sinner in that respect.
There is no perfection here, but the correct way to reason about this is to have schema-based systems where the surfaces and state machines are in high level representations and changes can be analyzed automatically without some human bumping the numbers.
Also, when you have 32 bit and 64 bit code, you have to have 32 bit and 64 bit versions of the framework both in memory and on the disk.
This is especially problematic with iOS devices that don’t have swap.
We’re to reinvent the wheel for ourselves instead of relying on huge dependency trees, yet new languages and frameworks (the most common form of wheel reinventing) are verboten.
The only way I can think to meet all these demands is for everyone (other than you, of course) to stop writing code.
And I gotta say, a part of me wishes for that at least once a day, but it’s not a part of me I’m proud of.
In my opinion, vents are fine amongst friends. Catharsis and all that. But in public they stir up a lot of negative energy without anything productive to channel it to (any solutions, calls to action etc). That sucks.
Also what you call "negative energy" I would often call "rightful criticism on non-distilled thoughts that have internal controversies".
The writing style is reminiscent to this famous text (not written in jest, you have to understand that most of these statements depend on a context that is for you to provide):
"Property is theft." -- P.J. Proudhon
"Property is liberty." -- P.J. Proudhon
"Property is impossible." -- P.J. Proudhon
"Consistency is the hobgoblin of small minds." -- R.W. Emerson
Most logic and language is worst case. You go all in or not on a concept.
Purity culture probably arose from this (not just sexual, but in so many areas of life, we view the binary not as "bad vs good", but "at least once bad, e.g. polluted" versus "always good").
I mean I'm sure we heard a bunch of conflicting messages in our lives in many different areas, and we have rationalizations for why that is (oh, those guys belong to a different political group, different viewpoints, etc.), often to just save on computation power because how tf are you gonna answer these grand philosophical questions in an afternoon, much less your lifetime - it's very halting problem-esque. Nevertheless, we still make heuristics, live in the muddy waters, and live.
Just ask yourself: Why would I want to do that?
When somebody suggests nonsense to you just ask yourself that one simple question. The answers is always, and I mean ALWAYS, one of these three things:
* evidence
* ethos, like: laws, security protocols, or religious beliefs
* narcissism
At that point its just a matter of extremely direct facts/proofs or process of elimination thereof. In the case of bad programmers the answer is almost universally some unspoken notion of comfort/anxiety, which falls under narcissism. That makes sense because if a person cannot perform their job without, fill in the blank here, they will defend their position using bias, logical fallacies they take to heart, social manipulation, shifting emotion, and other nonstarters.
As to your point about reinventing wheels you are making a self-serving mistake. Its not about you. Its about some artifact or product. In that regard reinventing wheels is acceptable. Frameworks and languages are not the product, at least not your product. Frameworks and languages are merely some enabling factor.
OP indeed has mutually exclusive phrases. If we ever get to the "extremely directs facts/proofs" then things get super easy, of course.
99% of the problem when working with people is to even arrive at that stage.
I predict a "well, work somewhere else then" response which I'll just roll my eyes at. You should know that this comes at a big cost for many. And even more cannot afford it. Literally.
I think we're doing fine.
Circa 1982 or so (and some years before) IBM was shipping mainframe software written in Assembly that anyone could build or modify. They had a bug database that customers could access. Around the same era Unix was shipping with source code and all the tooling you needed to build the software and the OS itself.
So maybe compared to some of that we're doing worse.
But still, I think we can do better. That story you shared highlights a gross inefficiency and diminishing of agency that comes from dependencies.
It's fitting a messy, real world process, to the virtual, reduced (because formalism) computing world backed by failable, messy hardware components through an error-prone, misunderstanding-prone of programming.
So much failure points, and no one is willing to bear the costs to reduce them.
Sometimes it is valid to not reinvent the wheel. Sometimes wheel needs to be reinvented to learn. Both actions are done. Sometimes the decision was right. Sometimes not.
Overall as a whole we are creating things, more than we are destroying. I don't see the need to take a negative stance.
Writing a new green field project using 10.000 npm dependencies for an electron based front end is shockingly easy. But how do you keep that running for the next 15 years? Did the project need npm? Or a web browser? How do all the layers between the lamguage of choice and the bare metal actually behave and can you reason about that aggregate accurately?
The field has come to a point where a lot of projects are set up with too many complexities that are expedient in the short term and liabilities in the long term.
The current generation of junior devs grows up in this environment. They learn that these mistakes as "the right thing to do" when they are questionable and require constant self-reflection and reevaluation. We do not propagate a hacking culture enough that values efficiency and simplicity in a way that leads to simple, efficient, stable, reliable and maintainable software. On a spectrum of high quality craftsmanship to mass-produced single use crap, software is trending too much to the latter. It's always a spectrum, not a bunary choice. But as a profession, we aren't keeping the right balance overall.
I started a job in manufacturing a few months ago and having to think that this has to work for the next 20 years has been a completely different challenge. I don't even trust npm to be able to survive that so web stuff has been been an extra challenge. I landed on lit web components and just bringing it in via a local CDN.
I definitely use npm (or rather pnpm) because I know it will allow me to build whatever I want much faster.
A few of them aren’t decisions any individuals have control over. Most coders aren’t jumping onto new languages and frameworks all the time; that’s an emergent group behavior, a result of there being a very large and growing number of programmers. There’s no reason to think it will ever change, nor that it’s a bad thing. And regardless, there’s no way to control it.
There are multiple reasons people write software fast rather than high quality. Because it’s a time/utility tradeoff, and time is valuable. It’s just a fact that software quality sometimes does not matter. It may not matter when learning or doing research, it may not matter for solo projects, it may not matter for one-off results, and it may not matter when software errors have low or no consequence. Often it’s a business decision, not an engineering decision; to a business, time really is money and the business wants engineering to maximize the utility/time ratio and not rabbit hole on the minutiae of craftsmanship that will not affect customers or sales.
Sometimes quality matters and time is well spent. Sometimes individuals and businesses get it wrong. But not always.
Fair point: each one of us can think about the balance and understand if it's positive or negative. But an important exercise must be accomplished about this: totally removing AI from the complexity side.
Most of the results that neural networks gave us, given the hardware, could be recreated with a handful lines of code. It is evident every day that small teams can rewrite training / inference engines from scratch and so forth. So AI must be removed from the positive (if you believe it's positive, I do) output of the complexities of recent software.
So if you remove AI since it belongs to the other side, the "complicated software world" what gave us, exactly, in recent times?
One example: Newbies shouldn't reinvent the wheel. I think they should use the tools, that are available and common in the given context. When they want to tinker, they should write their own compiler. But they shouldn't use that in production.
Another: Backward API compatibility is a business decision in most cases.
Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.
I strongly disagree. They should, and fail and try again and fail. The aim is not to reinvent the wheel, but to understand why the wheel they're trying to reinvent is so complex and why the way it is. This is how I learnt to understand and appreciate the machine, and gave me great insight.
Maybe not in production at first, but they don't reinvent the wheel in their spare time either. They cobble up 200 package dependency chains to make something simple, because that’s what they see and taught. I can write what many people write with 10 libraries by just using the standard library. My code will become a bit longer, but not much. It'll be faster, more robust, easier to build, smaller, and overall better.
I can do this because I know how to invent the wheel when necessary. They should, too.
> Another: Backward API compatibility is a business decision in most cases.
Yes, business decision of time and money. When everybody says that you're losing money and time by providing better service, and lower quality is OK, management will jump on it, because, monies.
> Also, I think it doesn't help to start every sentence with "We are destroying software". This sounds much more gloomy, than it really is.
I think Antirez is spot on. We're destroying software. Converting it to something muddy and something for the ends of business, and just for it.
I'm all with Antirez here. Software came here, because we developed the software just for the sake of it, and evolved it to production ready where needed. Not the other way around (Case in point: Linux).
Often that "saving money" is just externalizing the cost onto your users. Especially in mobile development. Instead of putting in the tiny amount of effort it takes to continue support for older devices, developers just increase the minimum required OS version, telling users with older hardware to fuck off or buy a new phone.
Another example is when you don't take the time to properly optimize your code, you're offloading that cost onto the user in the form of unnecessarily higher system requirements.
Growing up in the 80s and 90s I understand viscerally how you feel, but this take strikes me as willfully ignorant of the history of computers, and the capitalist incentives that were necessary for their creation. The first computer and the internet itself were funded by the military. The PC wouldn't have existed if mainframes hadn't proved the business value in order to drive costs down to the point the PC was viable. Even the foundational ideas that led to computers couldn't exist with funding—Charles Babbage's father was a London banker.
I think a lot of what you are reacting to is the failed promise of free software and the rise of the internet, when the culture was still heavily rooted in 60s counter-culture, but it hadn't crossed the chasm to being mainstream, so it was still possible to envision a utopian future based on the best hopes of a young, humanitarian core of early software pioneers operating largely from the sheltered space of academia.
Of course no such utopian visions ever survive contact with reality. Once the internet was a thing everyone had in their pocket, it was inevitable that software would bend to capitalist forces in ways that directly oppose the vision of the early creators. As evil as we thought Microsoft was in the early 90s, in retrospect this was the calm before the storm for the worst effects of tech. I hear Oppenheimer also had some regrets about his work. On the plus side though, I am happy that I can earn enough of a living working with computers that I have time to ponder these larger questions, and perhaps use a bit of my spare time to contribute something of worth back to the world. Complaining about the big picture of software is a fruitless and frustrating endeavour, instead I am interested in how we can use our expertise and experience to support those ideals that we still believe in.
Agree. That statement/sentiment though doesn't refute the point that it's destroying software.
So basically they shouldn’t learn the prod systems beyond a shallow understanding?
They absolutely should, or they will never even get to understand why they are using these wheels.
Fun fact, try to question modern web developers to write a form, a simple form, without a library.
They can barely use html and the Dom, they have no clue about built-in validation, they have no clue about accessibility but they can make arguments about useMemo or useWhatever in some ridiculous library they use to build...ecommerces and idiotic crud apps.
Why? We should stop saying others how they want to write/use their code ASAP.
Many established technologies are a total shitstorm. If it is ok to use them, it is ok if somebody wants to use their own compiler.
When it comes down to it, whatever works best and is usually the most simple, non-breaking, used to win out. That decision has been disconnected from the value creators to the value extractors. It is impossible to extract value before value is created.
Additionally, programming is a creative skill no matter how hard they try to make it not one. Creativity means trying new things and new takes on things. People not doing that will harm us long term.
Generally speaking, because that’s very likely to end up being “pushing for rewrites of things that work”, and also a case of not “taking complexity into account when adding features”, and perhaps in some cases “jumping on a new language”, too.
This is an imagined scenario, but the likelihood of someone easily replacing a working compiler in production with something better is pretty low, especially if they’re not a compiler engineer. I’ve watched compiler engineers replace compilers in production and it takes years to get the new one to parity. One person tinkering and learning how to write a compiler almost for sure does not belong in production.
Those who do not know history are doomed to repeat it. Or re-re-reinvent Lisp.
There was this anecdote about storm lamp or something. New recruit comes to a camp and sees old guard lighting lamps are turned upside down and lit sideways with a long stick. But he knows better, he tells them and they smirk. First day he lights them the optimal way with a lighter. He's feeling super smug.
But next day he finds the fuse is too short to reach so he takes the long stick...
Few months later, he's a veteran, he's turning lamp upside down using lighter sideways, with a long stick.
And the fresh recruit says he can do it better. And the now old guard smirks.
I'm sure I'm misremembering parts, but can't find the original for the life of me.
If someone would hand me a project, that is full of self invented stuff, for example a PHP project, that invented its own templating or has it's own ORM, I would run. There is laravel, slim or symfony, those are well established and it makes sense to use them. There are so much resources around those frameworks, people who posted about useful things, or packages that add functionality to those. It just doesn't make sense to reinvent the wheel for web frameworks and thousands of packages around those.
Writing software is standing on the shoulders of giants. We should embrace that, and yes one should learn the basics, the underlying mechanisms. But one should make a difference between tinkering around and writing software, that will be in production for years and therefore worked on by different developers.
The JavaScript world shows how to not do things. Every two years I have to learn the new way of building my stuff. It is annoying and a massive waste of resources. Everyone is always reinventing the wheel and it is exhausting. I understand why it is like this, but we as developers could have made it less painful, if we would embrace existing code instead of wanting to write our own.
Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc)
https://www.youtube.com/watch?v=ZSRHeXYDLko
Software technology is in decline despite appearances of progress. While hardware improvements and machine learning create an illusion of advancement, software's fundamental robustness and reliability are deteriorating. Modern software development has become unnecessarily complex, with excessive abstraction layers making simple tasks difficult. This complexity reduces programmer productivity and hinders knowledge transfer between generations. Society has grown to accept buggy, unreliable software as normal. Unless active steps are taken to simplify software systems across all levels, from operating systems to development tools, civilization faces the risk of significant technological regression similar to historical collapses.
Unfortunately my stance is that fundamentally things won't change until we get hit with some actual hardware limitations again. Most devs and people in general prefer a semblance of a working solution quickly for short-term gains rather than spending the actual time that's needed to create something of high quality that performs well and will work for the next 30 years. It's quite a sad state of affairs.
With that said I'm generally optimistic. There is a small niche community of people that does actually care about these things. Probably won't take over the world, but the light of wisdom won't be lost!
Users have now been taught that $10 is a lot to pay for an app and the result is a lot of buggy, slow software.
That’s really the entirety of the issue, right there.
People aren’t just accepting bad software, they’re paying for it, which incentivizes a race to the bottom.
It’s like “The War on Drugs,” that looks only at the suppliers, without ever considering the “pull,” created by the consumers.
As long as there are people willing to pay for crap, there will be companies that will make and sell crap.
Not only that, companies that try to make “not-crap,” will be driven out of business.
That's easy to stop. Disallow warranty disclaimers.
We are fixing it up by refactoring - many through adding abstractions.
I’m sure code with bad abstractions can scale poorly, but I’m not clear how code without abstractions can scale at all.
That's quite unrelated to abstractions. It's just poorly written code, for whatever reasons may have led there.
Imagine if a company had been able to systemize the whims of a paranoid regime, allowing them to track and spy on their citizens with impunity in secret, and the population became so inured to the idea that it became an accepted facet of their culture.
Or what if a political party dominated a state and systematized a way to identify and detect oppositional thought, stamping it out before a counterculture could ever arise. Maybe that thought was tied to a particular religious, ethnic, and/or cultural group.
What if these companies are here today, selling those products to the highest (nation-state) bidders, and the methods they're employing to keep the conceptual wheels turning at scale rely on filtering that selects for candidates who will gladly jump through abstract hoops set before them, concerned only with the how and never the why of what they're doing.
Think about what happens when two people video call each other from opposite sides of the world. How many layers of hardware and software abstraction are they passing through, to have a reliable encrypted video conversation on a handheld computer where the majority of the lag is due to the speed of light? How much of that would you like to remove?
I would venture an alternative bogeyman - "move fast and break things" AKA the drive for profits. It's perfectly possible (as illustrated above) to reliably extract great performance from a tower of abstractions, while building those abstractions in a way that empowers developers; what's usually missing is the will to spend time and money doing it.
And then the video player crashes trying to play an ad
I haven't watched that talk by Blow yet so maybe he covers my concern.
I think you have to be mindful of incentives structures and constraints. There's a reason the industry went down the path that it did and if you don't address that directly you are doomed to failure. Consumers want more features, the business demands more stuff to increase its customer base, and the software developers are stuck attempting to meet demand.
On one hand you can invent everything yourself and do away with abstractions. Since I'm in the embedded space I know what this looks like. It is very "productive" in the sense that developers are slinging a lot of code. It isn't maintainable though and eventually it becomes a huge problem. First no one has enough knowledge to really implement everything to the point of it being robust and bug free. This goes against specialization. How many mechanical engineers are designing their own custom molding machine in order to make parts? Basically none, they all use mold houses. How many electrical engineers are designing their own custom PCB(A) processing machines or ICs/components? Again, basically none. It is financially impossible. Only in software I regularly see this sentiment. Granted these aren't perfect 1-to-1 analogies but hopefully it gets the idea across. On the other hand you can go down the route of abstractions. This is really what market forces have incentivized. This also has plenty of issues which are being discussed here.
One thought that I've had, admittedly not fully considered, is that perhaps F/OSS is acting negatively on software in general. When it comes to other engineering disciplines there is a cost associated with what they do. You pay someone to make the molds, the parts from the molds, etc... It's also generally quite expensive. With software the upfront cost to adopting yet another open source library is zero to the business. That is there is no effective feedback mechanism of if we adopt X we need to pay $Y. Like I said, I haven't fully thought through this but if the cost of software is artificially low that would seem to indicate the business and by extensions customers don't see the true cost and are themselves incentivized to ask for more at an artificially low price thus leading to issues we are currently seeing. Now don't misread me, I love open source software and have nothing but respect for their developers; I've even committed to my fair share of open source projects. As I've learned more about economics I've been trying to view this through the lens of resource allocation though and it has lead me to this thought.
In game development, whenever we go with highly abstract middleware, it always ends up limiting us in what we can do, at what level of performance, how much we can steer it towards our hardware targets, and similar. Moreover, when teams become so lean that they can only do high level programming and something breaks close to the metal, I’ve seen even “senior” programmers in the AAA industry flail around with no idea how to debug it, and no skills to understand the low level code.
I’ve seen gameplay programmers who don’t understand RAII and graphics programmers who don’t know how to draw a shape with OpenGL. Those are examples of core discipline knowledge lost in the games industry. Aka what we have now, we might not know anymore how to build from scratch. Or at least most software engineers in the industry wouldn’t. It cannot end well.
Building your own in my exp is a better idea — then you can at least always steer it, improve and evolve it, and fix it. And you don’t accidentally build companies with knowledge a mile wide and an inch deep, which genuinely cannot ship innovative products (technically it is impossible).
I’m not even sure if this is true anymore. We got new features foisted on us most of the time.
I no longer think that's true. Instead, I think consumers want reliability, but more features is a way to justify subscription pricing segregation and increases.
Aside, he's treated like a celebrity in the game developer niche and I can't understand why.
Depending on what tech you use it can be easier or harder to do as well. I'm making a game with Love2D now, which has made supporting Mac and Linux rather trivial so far, although I've run into challenges with mobile platforms and the web even though it support them (it does work, but it takes more low-level glue code to support native phone features, and the web doesn't seem to be well maintained and my game is throwing webassembly errors currently when I try to run it).
And my previous game (which is on the backburner for now) was made with Monogame, and while that technically has support for Mac and Linux (as well as mobile), I've had quite a few issues even just getting the Mac version working well, like issues with resolution, rendering 3D properly, getting shaders not to break, etc. And they haven't kept up with the latest Mac updates the past few years and have had to make a special push to try to get it caught back up. I've probably sunk a good 20+ hours trying to get it working well before putting that aside to work on the actual game again and I still might have to rearchitect things a bunch in order to get that working.
Meanwhile Unity would probably be pretty dirt simple to port, for the most part, but it comes with other tradeoffs, like not being open source, and trying to pull a stunt a couple years ago where they pulled the rug out from under developers with changing licensing to something aggressive (that convinced other developers to port their games away from the platform), etc.
And there's Godot, which seems to be getting more support again (which is great, I even considered it or my current game, I just like coding in Love2D a bit better), but if you ever want your game on consoles you have to pay a third party to port your games to consoles for you.
The guy you linked makes their own engine (and to be fair, so does Jonathan Blow, who you're critiquing), which is great, but not everyone wants to get that low level. I would rather spend more time focusing on building the games themselves, which is already hard enough, rather than spending all that time building an engine.
It was for that reason that I spent several years focused on board game design instead (as I can make a working game with drawing on index cards and some colored plastic cubes in less than an hour), although that has its own frustrations with significant hurdles to get your game signed by publishers as an unknown designer (I did get one signed four years ago, and it's still not released yet), and large financial risks being made for manufacturing and distribution.
Edit: Also the person you linked to isn't even sure it was financially worth it to support all of those platforms, they just do it for other reasons:
"Do you make your money back? It’s hard to say definitely which could mean no. Linux and macOS sales are low so the direct rewards are also low. ...For Smith and Winston [their current game] right now I don’t think it’s been worth it financially (but it will probably make it’s money back on Launch)"
I often work with people who refuse to use software unless it's so well known that they can google for stackoverflow answers or blog walkthroughs. Not because well-known software is stable or feature-filled; no, they literally are just afraid of having to solve a problem themselves. I'm not sure they could do their jobs without canned answers and walkthroughs. (and I'm not even talking about AI)
This is why I keep saying we need a professional standards body. Somebody needs to draw a line in the sand and at least pretend to be real adults. There needs to be an authoritative body that determines the acceptable way to do this job. Not just reading random people's blogs, or skimming forums for sycophants making popular opinions look like the correct ones. Not just doing whatever a person feels like, with their own personal philosophy and justification. There needs to be a minimum standard, at the very least. Ideally also design criteria, standard parts, and a baseline of tolerances to at least have the tiniest inkling if something is going to fall over as soon as someone touches it. Even more should be required for actual safety systems, or things that impact the lives of millions. And the safety-critical stuff should have to be inspected, just like buildings and cars and food and electric devices are.
The lunatics are running the asylum, so that's not happening anytime soon. It will take a long series of disasters for the government to threaten to regulate our jobs, and then we will finally get off our asses and do what we should have long ago.
I’d like to have standard professional certification because I could use it as proof of the effort I put into understanding software engineering that many ICs have not. But I think that many people have “that’ll do it” values and whatever professional context you put them in, they will do the worst possible acceptable job. The best you can do is not hire them and we try to do that already — with LeetCode, engineering interviews, and so on. That effort does work when companies make it.
(Safety critical work is, in fact, inspected and accredited like you would wish, and I have seen the ugly, ugly, terrifying results inside the sausage factory. It is not a solution for people who don't care or don't have a clue, in fact it empowers them)
Software written in C continues to be riddled with elementary security holes, despite being written and reviewed by experts. If anything the push to rewrite is too weak, we have known about the dangers for decades at this point.
We aren't destroying software, it was never all that. The software of the 90s was generally janky in a way that would never be tolerated today.
Modern software, at least for web, is generally hideously unreliable, unperformant, and manages decent uptime only by running it in large parallel deployments, with an orchestrator that automatically reboots dead instances.
Speaking as someone who grew up in the 90's, I think the software products thst are developed today lack the creativity that existed in the software developed during the 90's. Rigid development frameworks that exist today prevent "jankiness" by reducing the number of design decisions that are available to a developer, and in my opinion this has resulted in a lack of diversity in the products available to consumers.
Ironically everyone today is using Kubernetes (aka "Borg") under the hood, and this is the same weakness that the Borg had in Star Trek.
Microsoft’s Garnet and Dragonfly are independent implementations that are pretty different under the hood.
The complexity/dependency graph of a random application now-a-days is absolutely insane. I don't count everything in this, including the firmware and the OS like Muratori does in his video[1], but it is close enough. The transitive dependency problem needs to be solved. And we need to do something about Bill/Guido taking away all that Andy gives.
I consider the OS (Win32 API, Linux syscalls) to be the only hard dependency for anything I write in C. Tend to avoid libc because of distribution issues. But you have no control over this layer once you switch over to Java/Python.
The only thing you can then do is stop depending on every library out there to avoid writing a couple of hundred lines of code specific to your situation. It definitely increases the maintenance burden. But dependencies are not maintenance-free either. They could have the wrong API which you have to wrap around, or will break compatibility at random times, or become abandonware/malware or have some security flaw in them (rsync had a major security vulnerability just last month).
My personal max line count for a useful project that does one thing is 5-10KLOC of Java/JS/Python. It is something I can go through in a couple of hours and can easily fix a few years down the line if I need to.
[1] The Thirty Million Line Problem (2015) https://youtu.be/kZRE7HIO3vk
- never ending upgrades
- unstable ui, unstable ecosystems
- fix it later
- shallow business models (subscriptions, freemium, adinfested)
- social everything (it used to be that my computer was a little escape space where and when i wanted, now i'm tethered to the web noise)This is such a perfect point, no one would have invented the "tank chain" if reinventing the wheel was not allowed.
There are instances where this is good advice, but when they turn into rigid rules, bad software is the inevitable result.
And do you really need to write your own library and implementation of SMTP?
Reinventing the wheel where it makes sense is still allowed. But one should think first about the reasons, in my opinion.
'We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels.'
and this
'We are destroying software pushing for rewrites of things that work.'
But generally speaking I grok it.
The problem, IMO, is globally applying either rule.
I am unable to reconcile these two seemingly contradictory takes in the article (rest of it I concur with):
"We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."
"We are destroying software pushing for rewrites of things that work."
By rewrite do you mean 1-to-1 porting the code to another language because reason is: faster/easier/scalable/maintainable/_____ (insert your valid reason here)?
This is the recent thread I'm down. Pandas 2.2 broke SQLalchemy backwards compatibility: https://stackoverflow.com/questions/38332787/pandas-to-sql-t... + https://github.com/pandas-dev/pandas/issues/57049#issuecomme...
Since flagged, but it's also highly relevant here, since it shows this isn't someone who's interested in serious thoughts or discussion about the merits of his arguments, just hot takes and cheap shots. Whatever he may have done in the past, I see no reason why he should be taken seriously here.
—
†) Please interpret my words literally and in your favor.
Now everyone is a “celebrity”and hubris is at an all time high.
I’ve been in tech for 25+ years and never heard of this person until now but it’s not the first time I’ve heard similar talk.
These maxims strike me more as bitter senior neck beard developer complains about the rest of his team in a passive aggressive way at the work lunch table before COVID.
If you’re a celebrity, we don’t need your snarky complaints. We need you using your “celebrity” to make things better.
I think about this a lot. A general purpose approach is easy to hop between shallow solutions to many problems. So technologists love to have a few of these on hand, esp because they job hop. They're well known and managers love to say "why not just use XYZ".
But it's obvious that a fine tuned hand crafted solution (possibly built from a general one?) is going to significantly out perform a general one.
And sometimes the reverse problem is what is destroying software: being unwilling to push for rewrites of things when they desperately need one. I think we may have over indexed on "never rewrite" as an industry.
> We are destroying software mistaking it for a purely engineering discipline.
And I'm also seeing this the other way: engineers are beginning to destroy non software things, because they think they can blindly apply engineering principles to everything else.
With each new language and new library, there's a chance to do it better. It's quite a wasteful process, but that's different from things getting worse.
I think the situation (loosely, wasting time spinning your wheels by modernizing things that are actually fine the way they are and may be made worse by adopting "hot new thing") looks worse when you see it through that lens than it actually is throughout the industry as a whole. There are plenty of opportunities for modernization and doing some of the things described in this article that actually make some sense when applied to appropriate situations.
In other words, I totally understand the vibes of this post, it's one of the reasons I don't work in the parts of the industry where this attitude is most prevalent. I would never feel the push to write a post like it though because the poster is I think being a bit dramatic. At least that's the case looking at the industry from my (id argue broader) vantage point of being an expert in and working quite a bit with "legacy" companies and technologies that maybe could stand to have a new UI implemented and some tasteful modern conventions adopted at least as options for the end users.
This post reads as a description of how the wheels come off the wagon if you don't do things well.
With the evolution of AI agents, we'll all be virtual CTOs whether we like it or not, mastering scale whether we like it or not. We need to learn to do things well.
Managerial genius will be the whole ball of wax.
We're destroying software when we think documentation does not matter.
I was going to phrase it: We are destroying software by neglecting to documenting it and its design decisions.
> We are destroying software with an absurd chain of dependencies, making everything bloated and fragile.
> We are destroying software by always thinking that the de-facto standard for XYZ is better than what we can do, tailored specifically for our use case.
> We are destroying software mistaking it for a purely engineering discipline.
> We are destroying software claiming that code comments are useless.
> We are destroying software by always underestimating how hard it is to work with existing complex libraries VS creating our stuff.
This one begs the question: "What is 'fast'?". I mean, is it high-performance, or quickly-written? (I think either one is a problem, but "quickly-written" leads to bad software, and overly-optimized software can be quite hard to maintain and extend).
> We are destroying software trying to produce code as fast as possible, not as well designed as possible.
You might say "I don't need to be able to propose a solution in order to point out problems", and sure, but that's missing the point. Because by pointing out a problem, you are still implicitly asserting that some solution exists. And the counter to that is: no, no solution exists, and if you have no evidence in favor of your assertion that a solution exists, then I am allowed to counter with exactly as much evidence asserting that no solution exists.
Propose a solution if you want complaints to be taken seriously. More people pointing out the problems at this point contributes nothing; we all know everything is shit, what are you proposing we do about it?
You give an engineer ownership and let them learn from their own mistakes, rise to the occasion when the stakes are high. This presumes they will have the last word on changes to that sand box that they own. If they want to rewrite it — that's their call. I'm the end they'll create a codebase they're happy to maintain and we will all win.
(And I think they'll be a happier engineer too.)
Weird take.
Um, no you're not.
> And the counter to that is: no, no solution exists,
If that's the case, it's probably helpful to know it.
> we all know everything is shit, what are you proposing we do about it?
Give up on whatever doomed goal you were trying to reach, instead of continuing to waste time on it?
To me this is the most sure way to identify the adults from the children in the room. People that can actually program, strangely enough, aren’t bothered by programming.
Read responsively
"We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension.
And we are destroying software with complex build systems.
We are destroying software with an absurd chain of dependencies, making everything bloated and fragile.
And we are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."
Yie-die-die-die-diiiiieee-dieeee,Yie die die die dieee dieeee
If all people were identical and everyone was on the same level, things would be different. But that is not how the real world works.
Without a spec, the world falls into disarray and chance, next you need QA tests, and security auditors, and red teams, salespeople, solutions engineers, tech support, training, and a cascade of managers who try and translate "want" into "does" and "when" and to understand and accept the results. Architects and seniors who are both domain experts and skilled coders as the single truth on what the GUI is even supposed to mean. Taking on varying levels of risk with contracts, hires or expanding and contracting the previously mentioned R&D units. That's not software anymore, that's consulting. It's so expensive and unsustainable that it's only a matter of time until you're the leg that gets gnawed off, which is inevitably the result, when burn and panic (or other negative factors) leads you away from turning pain points (like issues, training, or difficult usage) into ice cubes for a cocktail.
Software engineering is far from a monoculture.
Maybe what I’ve seen change over the years is the strategy of “pull a bunch of component systems together and wire them up to make your system” used to be more of an enterprise strategy but is now common at smaller companies too. Batteries included frameworks are out, batteries included dependencies in a bunch of services and docker images are in.
It’s true many people don’t invent wheels enough. But there are a lot of developers out there now…
The young grow old and complain about change. The cycle of life continues.
This one packs a lot of wisdom.
I'm not a masochist; they're often built on top of components, e.g. my IDE uses the Monaco editor. But working on these tools gives me a sense of ownership, and lets me hack them into exactly the thing I want rather than e.g. the thing that Microsoft's (talented! well-paid! numerous!) designers want me to use. Hacking on them brings me joy, and gives me a sense of ownership.
Like an idealised traditional carpenter, I make (within reason) my own tools. Is this the most rational, engineering-minded approach? I mean, obviously not. But it brings me joy -- and it also helps me get shit done.
Or, more generally, the fact that most of what the software industry produces is much more in line with “art” than “engineering” (especially when looked at from a Mechanical Engineer or Civil Engineer). We have so much implementation flexibility to achieve very similar results that it can be dizzying from the standpoint of other engineering fields. consider
I just tried to develop a simple CRUD-style database UI for a mechanical hobby project. Being on the backend/systems side of the spectrum, for the UI I decided "yeah, considering I work on a Mac now, and there's no such thing as WinForms here, let's quickly throw together something small with python and tkinter". God, that was a mistake and lead to both suffering and lost days which I did not work on the main project on.
How is it that in 2025, we still do not have some sort of Rapid Application Development tool for Mac? How do we still not have some sort of tool that allows us to just drag a database table into a window, and we have basic DB functionality in that window's app? Jobs demonstrated that capability in the NeXT demo, Visual Studio has been doing it for decades, so has Delphi. But on Mac?
Swift is a train wreck, tkinter is like painting a picture with yourself being blindfolded, Qt does a lot of things right, but has a funky license model I am not comfortable with - and has pain points of its own.
I eventually coughed up the 100 bucks and got a Xojo license ... now I am working in BASIC, for the first time since 1992 - but it has an interface designer. For a massive boost in usability, I have to get back into a language I wished to forget a long time ago.
And that does not spark joy.
Yes, bloat is bad. Yes, I too make fun of people who have to import some nom package to check whether a number is odd or even.
But sometimes, you are not Michelangelo, chiselling a new David. Sometimes, you just need a quick way to do something small. Actively preventing me from achieving that by refusing to go with the times is destructive.
He makes very good points. But he missed one. We are destroying software(or anything else) by waiting till something goes wrong to fix it. ex: Software Security, US Food Standards and their relation to the health of it's citizens, etc...
Many of these have been an issue since I started programming many decades ago on minis. Seems as the hardware gets more powerful we find ways to stress out the hardware more and more. This making your list true to a greater extent year after year.
BTW, I like your WEB Site format a lot!
I think people vastly underestimate "the wheel". The wheel was something recreated independently over and over again for thousands of years across human history. Even your favorite programming language or web framework is not comparable to "the wheel".
So you cannot "destroy" software. But you can have fast food versus slow food, you can have walkable cities or cars-only cities, you can have literate or illiterate society etc. Different cultures imply and create different lifestyles, initially subjective choices, but ultimately objectively different quality of life.
The author argues for a different software culture. For this to happen you need to create a viable "sub-culture" first, one that thrives because it acrues advantage to its practitioners. Accretion of further followers is then rapid.
> We are destroying software by no longer caring about backward APIs compatibility.
and
> We are destroying software by always underestimating how hard it is to work with existing complex libraries VS creating our stuff.
I’d say for about 75% of the projects I’ve worked on, choosing an existing complex library over writing something new was due to backward compatibility. I’d say we vastly underestimate how much work is put into to deal with back compat.
My take: SemVer is the worst thing to happen to software engineering, ever.
It was designed as a way to inform dependents that you have a breaking change. But all it has done is enable developers to make these breaking changes in the first place, under the protective umbrella of “I’ll just bump the major version.”
In a better universe, semver wouldn’t exist, and instead people would just understand that breaking changes must never happen, unless the breakage is obviously warranted and it’s clear that all downstreams are okay with the change (ie. Nobody’s using the broken path any more.)
Instead we have a world where SemVer gives people a blank check to change their mind about what API they want, regularly and often, and for them to be comfortable that they won’t break anyone because SemVer will stop people from updating.
But you can’t just not update your dependencies. It’s not like API authors are maintaining N different versions and doing bug fixes going all the way back to 1.0. No, they just bump majors all the time and refactor all over the place, never even thinking about maintaining old versions. So if you don’t do a breaking update, you’re just delaying the inevitable, because all the fixes you may need are only going to be in the latest version. So any old major versions you’re on are by definition technical debt.
So as a consumer, you have to regularly do breaking upgrades to your dependencies and refactor your code to work with whatever whim your dependency is chasing this week. That callback function that used to work now requires a full interface just because, half the functions were renamed, and things you used to be able to do are replaced with things that only do half of what you need. This happens all the god damned time, and not just in languages like JavaScript and Python. I see it constantly in Rust as well. (Hello Axum. You deserve naming and shaming here.)
In a better universe, you’d have to think very long and very carefully about any API you offer. Anything you may change your mind on later, you better minimize. Make your surface area as small as possible. Keep opinions to a minimum. Be as flexible as you can. Don’t paint yourself into a corner. And if you really, really need to do a big refactor, you can’t just bump major versions: you have to start a new project, pick a new name (!), and find someone to maintain the old one. This is how software used to work, and I would love so much to get back to it.
Which is just fine when it is a non funded free software project. No one owes you anything in that case, let alone backwards compatibility.
Forbidding breaking changes isn't going to magically make people produce the perfect API out of the gate. It just means that fixes either don't get implemented at all, or get implemented as bolt-on warts that sow confusion and add complexity.
Legacy systems are born from rushing into implementation to feel productive rather than understanding the problem. Slow is smooth. Smooth is fast.
When I do a git blame of something coherent, that worked well in production, that I wrote years ago, almost none of my original code survived, every line is now written by a different person. That's the entropy of software systems left unchecked. It was not really rushed, there was a ton of time debating design before a single line was written.
If asked to implement a templated dictionary type, many C++ programmers will write a templated class. If they want to be responsible, they’ll write unit tests. But the simplest way is:
template<typename Key, typename Value>
using Dictionary = std::vector<std::pair<Key, Value>>;
It is trivially correct and won’t have any edge cases which the tests may or may not catch.
Some programmers would consider this implementation beneath them. In just 800 lines, they could build the type from scratch and with only a few months’ long tail of bugs.
> We are destroying software by jumping on every new language, paradigm, and framework.
Whilst I largely agree with the premise of the post, some of these points feel a little bit dissonant and contradictory. We can have stability and engineering quality _and_ innovation. What I think the author is trying to target is unnecessary churn and replacements that are net-worse. Some churn is inevitable, as it’s part of learning and part of R&D.
That culture usually starts at the top if you have it in your company, but occasionally you will just be lucky enough to have it in your team.
So before you write some software, you describe it to your team in a document and get feedback (or maybe just your manager).
If you don't do this, you don't really have a software design culture at your company. My rule was basically that if a piece of software required more than 1 Jira ticket, then create a doc for it.
There are dozens of homelab solutions for this (homepage, heimdall, etc.) but none of them was simple enough, framework-free or able to run completely offline (or even from cache).
Being able to code something that fits into a couple of screenfuls of text and does 99% of what I need still feels like “the right way”.
Yet: https://x.com/antirez/status/1885994950875046164
The reality is that man's "unnecessary complexity" is another's table stakes feature. The post isn't entirely without merit, but most of it reads like a cranky old timer who yearns for a simpler time.
Also I'm very enthusiastic with modern AI and definitely open to new things that make a difference. The complexity I point my finger to, in the post, is all unnecessary for software evolution. Actually it prevents going forward making it better because one have to fight with the internal complexity or with a culture that consider innovation rewriting the software with X or using Y.
Take for example the web situation. We still write into forms, push "post" buttons. Now we trigger millions of lines of code but the result is basically the same as 20 years ago.
What books can anyone recommend on software complexity ?
I'm looking to assert or challenge my intuitions around software complexity that I've built in the last decade.
Also to drive meaningful conversations around it. Having published material helps
When we build software, we answer three questions: "what?", "how?", and "why?". The answer to what becomes the data (and its structure). The answer to how is the functionality (and the UI/UX that exposes it). The answer to why is...more complicated.
The question why is answered in the process of design and implementation, by every decision in the development process. Each of these decisions becomes a wall of assumption: because it is the designer - not the end user - making that decision.
Very rarely can the end user move or replace walls of assumption. The only real alternative is for the user to alter the original source code such that it answers their why instead.
Collaboration is the ultimate goal. Not just collaboration between people: collaboration between answers. We often call this "compatibility" or "derivative work".
Copyright, at its very core, makes collaboration illegal by default. Want to make CUDA implementation for AMD cards? You must not collaborate with the existing NVIDIA implementation of CUDA, because NVIDIA has a copyright monopoly. You must start over instead. This is NVIDIA's moat.
Of course, even if copyright was not in the way, it would still be challenging to build compatibility without access to source code. It's important to note that NVIDIA's greatest incentive to keep their source code private is so they can leverage the incompatibility that fills their moat. Without the monopoly granted/demanded by copyright, NVIDIA would still have a moat of "proprietary trade secrets", including the source code of their CUDA implementation.
Free software answers this by keeping copyright and turning it the other direction. A copyleft license demands source code is shared so that collaboration is guaranteed to be available. This works exclusively for software that participates, and that is effectively its own wall.
I think we would be better off without copyright. The collaboration we can guarantee through copyleft is huge, but it is clearly outweighed by the oligopoly that rules our society: an oligopoly constructed of moats whose very foundations are the incompatibility that is legally preserved through copyright.
People tend to adapt to technology by becoming more lazy, putting less effort in understanding. Look at how after of calculators became common, we got generations of people who struggle to do basic math.
You'll also find that most people do the same stuff they would have done without a calculator still without a calculator. The advantage now is when they do reach for the calculator they aren't working with perhaps 2 digits precision like the slide rule that preceded them or having to tabulate large amounts of figures to maintain precision.
Do you have any data behind this claim?
> When developers become too dependent on AI to "assist" them in coding, they're more likely to be unable to debug "their own" code as they won't have a full grasp/understanding of it.
Again, do you have any evidence that this happen?
(This is an allusion to Kernighan’s lever.)
What is it about software that causes us to search for aesthetic qualities in the instructions we write for a machine? Ultimately the problems we’re solving, for most of us, will be utterly meaningless or obsolete in ten years at most.
That illusion has been lifted a little harshly for a lot of people over the past year or so. I still enjoy software-as-craft but I don't hold any false belief that my day job does.
We are destroying software by being absolute.
We are destroying software by assuming we know what we are doing.
Everything is relative; every solution has its own trade-offs. This blog post is very absolute - it ignores trade-offs and sells itself as the truth.
> We are destroying software by no longer caring about backward APIs compatibility.
Come on, who believes this shit? Plenty of people care about API backwards compatibility.
> We are destroying software pushing for rewrites of things that work.
So never rewrite something if it "works"? There are plenty of other good reasons to rewrite. You might as well say "We are destroying software by doing things that we shouldn't do!"
> We are destroying software claiming that code comments are useless.
No we aren't. The crazy "no comments" people are a fringe minority. Don't confuse "no comments" (clearly insane) with "code should be self-documenting" (clearly a good idea where possible).
Worthless list.
Setting up uv, Dockerfiles, GitHub Actions, Secrets etc. took me basically the whole day. I can very much relate to "We are destroying software with complex build systems."
I am reminded of howto guides that require downloading a scaffolding tool to set up a project structure and signing up with some service before even getting to the first line of code.
As CEO, since I have a “fiduciary responsibility to increase shareholder value” I think we should just focus on shipping asap. We can fix it after our next round of funding after we can hire a larger team.
Then, PL creators whose language isn’t even at 1.0 light the fuse.
Or others may say: "There are software, and there are things remind people of software".
Arguing against 10x complexity & abstractions, with 1x coding :-)
It's easy to get caught up in what you dislike about software, but you have to make yourself try new stuff too. There's always more delight to be found. Right now, I think it's good to embrace LLM assistants. Being able to sit down and avoid all the most tedious parts and focus purely on engineering and design makes every session much more enjoyable.
Software itself is better now than it has ever been. We're slowly chipping away at our own superstitions. Just because some people are fully employed building empty VC scams and software to nowhere does not damn the rest of the practice.
I think that writing software for an employer has always kind of sucked. There's never enough time to improve things to the state they should be and you're always one weird product feature from having to completely mess up your nice abstraction.
I do feel like writing hobby software is in a great state now though. I can sit down for 30 minutes and now with Cursor/LLM assistance get a lot of code written. I'm actually kind of excited to see what new open source projects will exist in a few years with the aid of the new tools.
Isn't this kind of ironic?
I believe we'll soon be looking for "the joy of programming" in a totally different way, far more outcome-oriented than it is today. (Which is, in my book, a good thing!)
In a world of mass hallucination (psychosis), doom-scrolling and international capital, software decay is a logical process. Your Leaders have no incentive to think systemically when they have guaranteed immunity.
A good software is a result of meritocratic system with accountability and transparency.
Just take a statistical view on investment in education vs investment in AI infrastructure and the picture becomes clear.
The designer fallacy. Techno-optimism. Detachment from the real problems of humanity. Desensitized obedience for career growth or social benefits.
We build software on the shoulders of giants with a sense of reality and human connection. We lost this skill.
You cannot abstract to infinity. You cannot complicate things just because and expect quality and maintainability to emerge from the ether.
We continue to add complexity for the sake of complexity, rarely because of necessity. We never question adding new things, yet there's always an excuse not to streamline, not to remove, not to consolidate.
We must deliver new features, because that is progress. We must never remove old systems, because that harms us. We must support everything forever, because it's always too costly to modernize, or update, or replace.
It doesn't matter if the problem doesn't exist, what matters is that by incorporating this product, we solve the problem.
We must move everything off the mainframe and onto servers. We must move every server into virtual machines. We must move every virtual machine into AWS. Every EC2 instance into a container. Every container into Kubernetes. Into OpenShift. We must move this code into Lambda. Do not question the reasoning or its value, it must be done.
How did our budget balloon in size? Why are our expenses always going up? Why is our cloud bill so high? We must outsource, clearly. We must hire abroad. We must retain contractors and consultants. We need more people with certifications, not experience.
Why is everything broken? Why is our data leaking into the public realm? How did we get hacked? We must bring in more contractors, more consultants. That is the only answer. We don't need internal staff, we need managers who can handle vendors, who can judge KPIs, who can identify better contractors at cheaper costs year after year.
Why is the competition beating us? What vendor should we go with to one-up our competition? We must consult the Gartner report. We must talk to other CIOs. We must never talk to our staff, because they don't understand the problem.
We don't like our vendor anymore. They raised prices on us, or didn't take us to that restaurant we liked for contract negotiations, or didn't get us box seats for that event this year. They must go. What do you mean we can't just leave AWS this quarter? What do you mean we can't just migrate our infrastructure to another competitor? That proprietary product is an industry standard, so just move to another one. What are we even paying you for?
We checked all the boxes. We completed all the audits. We incorporated all the latest, greatest technologies. We did everything we were told to. So why aren't we successful? Why aren't we growing?
...ah, that's why. We didn't incorporate AI. That must be it. That will fix it all.
Then we'll be successful. Then everything will work.
50 IQ: haha software is complicated whatever
100 IQ: (this post)
150 IQ: software is complicated whatever
Until the incentives change, the outcome won't change.
Pointless meetings and bureaucracy also doesn't help. Instead of giving engineers time and breathing room to build well-defined systems, organisations treat them like fungible workhorses that must meet arbitrary deadlines.
Semi-related: Start using profane variable names because apparantly it will cause Copilot to stop analyzing your code.
Even more fundamentally, it's built on the ubiquitous mistake made by those who make good money in the current status quo: it doesn't name the actual cause of rushed work et al., which is obviously capitalist cost-cutting, not lazy professionals.
Frequent job hopping: lack of pay upgrades because software is considered a cost center
I could go on but in reality it’s a disconnect between what business thinks the software is worth as opposed to what the engineer wants to do with it.
You can say software is an art but commodity art doesn’t make much money. In reality, the ad driven software has greatly inflated salaries (not complaining but it’s reality). Now it’s going to be an ai bubble. But your rank and file business doesn’t care what software bubble is happening but unfortunately they are bound by the costs that come with it.
Have you seen the process that happens in defense or medical equipment industries. You probably won’t complain.
FOSS doesn't have these problems.
> We are destroying software with an absurd chain of dependencies, making everything bloated and fragile.
> We are destroying software by making systems that no longer scale down: simple things should be simple to accomplish, in any system.
That's true and I'd say we've got proof for that with the fact that many software is now run in containers.
I always get downvoted for saying that it's not normal we now all run things in containers but I do run my own little infra at home. It's all VMs and containers. I know the drill.
It's not normal that to do something simple and which should be "dumb", it's easier to just launch a container and then interface with the thing using new API calls that are going to be outdated at the next release. We lost something and it's a proof we gave up.
This containerization-of-all-the-things is because we produce and consume turds.
Build complexity went through the roof so we have to isolate a specific build environment in a container file (or, worse, a specific environment tailored to be accept one build already made).
Criticize Emacs as much as you want: the thing builds just fine from source with way more lines of code (moreover in several languages) than most projects. And it builds fine since decades (at least for me). And it doesn't crash (emacs-uptime -> 8 days, 5 hours, 48 minutes and that's nothing. It could be months but I sometimes turn my computer off).
Nowadays you want to run this or that: you better deploy a container to deal with the build complexity, deployment complexity and interacting complexity (where you'll use, say, the soon-to-be-updated REST calls). And you just traded performance for slow-as-molasses-I-wrap-everything-in-JSON calls.
And of course because you just deployed a turd that's going to crash anyway, you have heartbeats to monitor the service and we all applaud when it automatically gets restarted in another container once it crashed: "look what a stable system we have, it's available again?" (wait what, it just crashed again, oh but no problem: we just relaunched another time)
It's sad really.
I just open sourced a CLI tool for income and expense tracking yesterday at https://github.com/nickjj/plutus and I'd like to think I avoided destruction for each of those bullets.
You have a choice on the code you write and who you're writing it for. If you believe these bullets, you can adhere to them and if you're pressured at work to not, there are other opportunities out there. Don't compromise on your core beliefs. Not all software is destroyed.