21 ms·

We are destroying software

• deleted 2y ago
  [deleted]
• skybrian 2y ago
  This seems rather alarmist because it's so focused on the bad things and ignores the improvements that come along with the churn. 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.
  • the_mitsuhiko 2y ago
    You can read it as alarmist, or you can read it as a rather sobering reflection on the current state of affairs. The world will not end, nothing will explode. What however I think will happen is that the next generation of engineers is going to judge us by our creations and learn from it.
    • pvg 2y ago
      I think CJ (Continuous Judging) is already the well-established, default practice.
      • the_mitsuhiko 2y ago
        I only take issue with the "alarmist" part of it.
• Trasmatta 2y ago
  > We are destroying software pushing for rewrites of things that work. 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.
• jmclnx 2y ago
  I agree and you are talking to the choir here :) 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!
• sirnicolaz 2y ago
  A bit of incoherence between this '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.
  • antirez 2y ago
    The rewrite line is about "Let's rewrite this big system from X to Y", not about experimenting creating new variants.
  • Trasmatta 2y ago
    I think that's actually pretty pragmatic. Sometimes the answer is to reinvent the wheel. Sometimes the answer is to keep improving the system that already works. The problem, IMO, is globally applying either rule.
• fouc 2y ago
  Reminds me of https://www.ultratechnology.com/1xforth.htm https://www.ultratechnology.com/1xforth.htm Arguing against 10x complexity & abstractions, with 1x coding :-)
• mewpmewp2 2y ago
  All the statements in that post are trade offs. In all cases you are sacrificing something to gain something else. Therefore in a way you are always "destroying" something. 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.
  • antirez 2y ago
    > Overall as a whole we are creating things, more than we are destroying. I don't see the need to take a negative stance. 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?
    • mewpmewp2 2y ago
      If we discard the AI, which I don't think we should, but if we do - my life has been enriched a lot in terms of doing things I want to do vs things I don't want to. Very quick deliveries, I never have to go to a physical store, digital government online services, never having to wait in any queue, ability to search and find answers without having to go to libraries or know specific people. Online films, tv shows on demand, without ads. There are tons of those things that I feel have made my life so much easier.
      • antirez 2y ago
        Why this is a result of software complexity? I'm not in favor of less capable software.
• zifpanachr23 2y ago
  These are all complaints specific to a particular attitude and kind of web software development that just happens to be most prevalent within a place like SV. 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.
  • Syzygies 2y ago
    Yes. There are better and worse ways to lead a team, just as there are better and worse ways to prompt AI. 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.
• talles 2y ago
  > We are destroying software mistaking it for a purely engineering discipline. This one packs a lot of wisdom.
  • ks2048 2y ago
    This was one of the few that didn't resonate. What does it mean?
    • mceachen 2y ago
      If I had to guess, antirez was describing engineering managers and tech leads that have (mis)read “clean code” or similar works, and take them as commandments from on high rather than tools and approaches that may be helpful or applicable in some circumstances. 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
    • JanneVee 2y ago
      In my view it is about design that requires taste and creativity. Engineering is about function, design is about form. If I build something that solves a problem but if it isn't well designed it can mean that no one actually uses even if it is good piece of engineering.
      • ks2048 2y ago
        Yeah, I guess that's what he meant. In my mind, though, good "engineering" would also include good design, simplicity, etc.
    • Doches 2y ago
      I think the final point illustrates this one pretty succinctly: 'what will be left will no longer give us the joy of hacking.' Personally I build my own version of almost every software tool for which I regularly (like, daily) use a UI. So for e.g. personal note-taking, continuous integration, server orchestration, even for an IDE: I could use Apple Notes, CircleCI, Chef, VSCode, but I instead build my own versions of these. 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.
• ahofmann 2y ago
  While I highly respect antirez, I think this post is full of good sounding, short statements, that wouldn't hold in a discussion. 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.
  • antirez 2y ago
    > When they want to tinker, they should write their own compiler. But they shouldn't use that in production. 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.
    • mukunda_johnson 2y ago
      the shitstorms usually have a community behind it. Even if it sucks, it's supported and will be maintained to a point of it "working." If someone writes their own thing, chances are they won't go the extra mile and build a community for it. Then, when it comes to maintaining it later, it might grow untenable, especially if the original "tinkerer" has moved on.
      • dpkonofa 2y ago
        This would be great if things like open source were more supported in the "real" world. Unfortunately, you're describing exactly why a community means nothing in this situation unless the community is giving back to the project. When the "original tinkerer" moves on, everything depending on that project breaks when everything else changes around it.
    • drawkbox 2y ago
      These systems also came from tinkering. Most programming languages even are really the investment of one person for a long time, doing apparently what you aren't supposed to do. 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.
• remoquete 2y ago
  To the list I'd add: We're destroying software when we think documentation does not matter.
  • antirez 2y ago
    Well put. And even when we think that writing doc is a less important thing.
  • JKCalhoun 2y ago
    There was the point about "comments" not mattering.
    • remoquete 2y ago
      Comments are just one bit of the docs.
  • contingencies 2y ago
    Came to post the same. I was going to phrase it: We are destroying software by neglecting to documenting it and its design decisions.
• recursivedoubts 2y ago
  lisan al gaib!
• nthingtohide 2y ago
  This reminds me of Jonathan Blow's talk. Software decays just like everything else if we don't tend to it. Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc) https://www.youtube.com/watch?v=ZSRHeXYDLko 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.
  • _hao 2y ago
    I think that talk might be Jonathan Blow's most important work to date actually. I love The Braid and The Witness, but "Preventing the Collapse of Civilization" managed to articulate what at least me and my circle of devs have talked about and discussed for long time, but were never quite able to put into words. I'm very grateful for people like him and others like Casey Muratori, Mike Acton etc. who continue to point this out very real danger in the (at least) last decade. 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!
    • bathtub365 2y ago
      Oftentimes there isn’t a need for something to work for the next 30 years as the business will change in a much shorter timeframe and software exists to serve the business. While I agree that software quality varies wildly if the business can’t get off, the ground because the software isn’t ready, the software team will quickly stop existing with the rest of the business.
• joeyguerra 2y ago
  Not I.
• deleted 2y ago
  [deleted]
• kibwen 2y ago
  The older I get the less stock I put in merely pointing out flaws without offering solutions. 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?
  • JKCalhoun 2y ago
    My rather broad solution has always been: let engineers own a part of a stack. Let an engineer own the UI for an app, own the database front-end. Let an engineer own the caching mechanism, let an engineer own the framework. 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.)
    • efrecon 2y ago
      But then... One of those engineers quit and another one becomes seriously ill and cannot work for a longer period of time...
      • JKCalhoun 2y ago
        Spoken like management, ha ha. It happens. People step in and take over. The company continues.
  • asadotzler 2y ago
    Defining or clarifying the specifics of the problem is a critical step in solving (or not solving) it. We don't have a good understanding of all of the factors and how they contribute to this problem so having more people take a stab at understanding the problem and sharing that is a net positive. You may think that "we all know it already" but we don't. I discover new and meaningful ways that systems and people are fucking up software just about every year and have been for 25-30 years so I take strong issue with your "we all know" when clearly we don't, and in fact very much still disagree on the details of that problem, the very things we need to understand in order to best solve the problem.
• snowstormsun 2y ago
  We are destroying software by letting non-technical people make technical decisions.
• neilv 2y ago
  We are destroying software with Leetcode interviews, resume-driven development, frequent job-hopping, growth investment scams, metrics gaming, promotion-seeking, sprint theatre, bullshitting at every level of the org chart, and industry indifference.
  • unification_fan 2y ago
    Literally all of that is because capitalism incentivizes short-term profit over meaningful, society-benefiting work. FOSS doesn't have these problems.
    • bawolff 2y ago
      I feel like resume-driven development is certainly a thing that happens in FOSS.
    • Ekaros 2y ago
      Just how many FOSS projects there are that are dead? Just how many different ways to do things have been invented? Say Linux desktop environments. Or parts of subsystems. FOSS is certainly guilty too.
      • unification_fan 2y ago
        Fair, but then again FOSS is born from individual hackers who want to learn how to build X, or who feel like the ecosystem doesn't provide the X they would like to have. It fosters a culture where everyone can hack something together, and where everyone is knowledgeable enough to make responsible use of technology. Working as a for-hire developer doesn't let you experience all of that because you're building a product that someone else wants you to build. No wonder one does not give a shit about writing good software at that point! You've taken all the fun and personal fulfillment out of it! We can build anything we put our mind to -- but most of us are too busy churning out CRUD boilerplate like factory workers. That's depressing.
      • _Algernon_ 2y ago
        How is FOSS guilty of the same? The code is there free for you to take, modify and fix, even if the project is otherwise abandoned.
• airstrike 2y ago
  We are destroying software by thinking the web is the only platform in which we can write GUIs
  • layer8 2y ago
    I can only hope that the tech stack for server-served apps will be much more sane in a couple of decades (for the developers of the future; it’ll be too late for me). We are really in a very bad place now in that regard.
  • scarface_74 2y ago
    What do you propose? Do you remember how bad it was trying to upgrade and maintain windows programs across a large organization?
• bdhcuidbebe 2y ago
  ”we are” not antirez. Semi-related: Start using profane variable names because apparantly it will cause Copilot to stop analyzing your code.
• kittikitti 2y ago
  “Don’t reinvent the wheel!” 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".
• austin-cheney 2y ago
  Holy fuck. I internally explode in anger every time I hear Don’t reinvent the wheel. 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.
  • ludston 2y ago
    The ones considered adults aren't so emotionally disregulated that they get angry about sometimes useful idioms.
    • austin-cheney 2y ago
      The grown ups do sometimes get angry at children that lie about their capabilities and equivocate with bullshit excuses.
• throwaway81523 2y ago
  destroyallsoftware.com is a excellent web site :).
• nurettin 2y ago
  We are destroying software by selling it to greedy corporates who try to monopolize all open source clients for that software on github.
• stmw 2y ago
  He is exactly right. Complexity is eating the world. Faster CPUs, larger memories and faster networks have brought great capability -- but removed the natural governor on software complexity.
  • agumonkey 2y ago
    the internet era also changed things - 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)
• cedws 2y ago
  Capitalism doesn't incentivise building quality software, it incentivises building as quickly as possible and covering up the flaws because "we'll fix it later" (spoiler: it doesn't get fixed later.) 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.
• moktonar 2y ago
  We are not destroying software, money is.
• uses 2y ago
  Yeah, 20 years ago when I started building websites I was still in my CS major. We didn't have these huge layers of libraries and frameworks. I wonder how much I would know now if I didn't have to just build everything myself. We would make all kinds of things and we did it all from scratch - upload files, log in, save stuff in databases using actual sql, entire ecommerce experiences, I would write the whole "front end" and "back end" by hand. And everything was really fast.
• thomastjeffery 2y ago
  We are destroying software to build on top of it over and over again. What could we do instead? 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.
• ChrisMarshallNY 2y ago
  These all resonate deeply with me: > 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.
  • LargeWu 2y ago
    I take "fast" here to mean "written to delivery business value as soon as possible"
• swaraj 2y ago
  I spent 10 hrs this week upgrading our pandas/snowflake libs to latest bc there was apparently a critical vulnerability in the version we used (which we need to fix bc a security cert we need requires us to fix these). The latest versions are not major upgrades, but completely changed the types of params accepted. Enormous waste of time delivering 0 value to our business
  • parasti 2y ago
    Security updates are probably the only type of updates that I wouldn't ever call a waste of time. It sucks when they are conflated with feature updates or arbitrary changes, but by itself I don't understand calling them a waste of time.
    • swaraj 2y ago
      They are when the only reason they are flagged as security updates is because some a single group deems a very rare, obscure edge case as a HIGH severity vuln when in practice it rarely is => this leads to having to upgrade a minor version of a library that ends up causing breaking changes. This is the recent thread I'm down. Pandas 2.2 broke SQLalchemy backwards compatibility: https://stackoverflow.com/questions/38332787/pandas-to-sql-to-sqlite-returns-engine-object-has-no-attribute-cursor https://stackoverflow.com/questions/38332787/pandas-to-sql-t... + https://github.com/pandas-dev/pandas/issues/57049#issuecomment-1916060301 https://github.com/pandas-dev/pandas/issues/57049#issuecomme...
• tptacek 2y ago
  At my first professional software job, where we wrote C, because that was all you could realistically write commercial software in, there was one person on our floor who could do software builds. He used some commercial build tool the company had licensed and he was the only one who knew how to use it or would be allowed to learn how to use it. His customers were every product team in our division --- about 12 of them. We had to petition to get beta releases done. The builds took hours. I think we're doing fine.
  • dgb23 2y ago
    This cracked me up. I love hearing those stories, also from my father, where he would talk about "we already did that in the 80's and it was called...", and then he would tell me about some obscure assembler tricks to patch binaries, in order to keep them compatible with some system I never heard about. But still, I think we can do better. That story you shared highlights a gross inefficiency and diminishing of agency that comes from dependencies.
  • phendrenad2 2y ago
    I kind of agree. I think software has a certain amount of "badness" that will always exist, it's a mathematical equilibrium. There are a myriad of things that can make your process bad, and if you fix all of them, you'll never ship. The list Pope gives here are the most common issues, but not all teams will check the whole list.
    • skydhash 2y ago
      > I think software has a certain amount of "badness" that will always exist 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.
  • YZF 2y ago
    What year are we talking about here? 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.
• bbor 2y ago
  IMO this is some quintessential false nostalgia mixed with uncritical, confirmation-bias driven cynicism. When exactly are we pointing to when we express these complaints? I get the sense that the answer is invariably either "my first job out of college" or "before React", whenever this comes up. 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.
• aredestroyoursz 2y ago
  What makes anyone think that anything in the universe is protected from the innate natural process of divide, conquer, exploit and hoard... 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...
• nickjj 2y ago
  The timing of this is pretty convenient. I just open sourced a CLI tool for income and expense tracking yesterday at https://github.com/nickjj/plutus 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.
• TacticalCoder 2y ago
  > We are destroying software with complex build systems. > 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.
• edanm 2y ago
  This seems like an interesting time to post this. With the rise of LLMs, Software development has changed more in the last two years than at any time I can previously recall. And I strongly suspect that's just the beginning. 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!)
  • layer8 2y ago
    I mean, you’re the CEO of an AI company.
    • edanm 2y ago
      Umm, yeah, so? What is the implication of this comment supposed to be?
      • SaucyWrong 2y ago
        The implication is that you’re fronting. It’s fine, I’m a technical founder of an AI company. The business demands that what you say is true. But for me, and many others, the joy of programming is in doing the programming. There is not a more outcome-driven modality that can bring us joy. And we either reject the premise or are grieving that it might eventually be true.
        • edanm 2y ago
          I've been a software dev for 27 years, professionally for 21 years. This idea is getting the causality arrows backwards. I'm not talking up AI because I'm in AI - I'm in AI because I believe it is revolutionary. I've been involved in more fields than most software devs, I believe, from embedded programming to 3d to data to (now) AI - and the shift towards Data & AI has been an intentional transition to what I consider most important. I have the great fortune of working in what I consider the most important field today. > But for me, and many others, the joy of programming is in doing the programming. There is not a more outcome-driven modality that can bring us joy. And we either reject the premise or are grieving that it might eventually be true. This is an interesting sentiment. I certainly share it to some extent, though as I've evolved over the years, I've chosen, somewhat on purpose, to focus more on outcomes than on the programming itself. Or at least, the low-level programming. I'm actually pretty glad that I can focus on big picture nowadays - "what do I want to actually achieve" vs "how do I want to achieve it", which is still super technical btw, and let LLMs fill in the details (to the extent that they can). Everyone can enjoy what they want, but learning how to use this year's favorite library for "get back an HTML source from a url and parse it" or "display a UI that lets a user pick a date" is not particularly interesting or challenging for me; those are details that I'd just as soon avoid. I prefer to focus on big picture stuff like "what is this function/class/file/whatever suppoed to be doing, what are the steps it should take", etc.
• thebiglebrewski 2y ago
  Interesting takes. I got a sort of "Yom Kippur Vidui" vibe from this if anyone else in the tribe is reading haha. 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
• hacker_homie 2y ago
  My take away is that packages were a mistake I have never heard anyone happy to deal with packages or versioning. Dependencies should be expensive to slow the bloat.
• revskill 2y ago
  Enjoying programming is harder than u think.
• kshri24 2y ago
  EDIT: should have read the comments first. Answered here: https://news.ycombinator.com/item?id=42983369 https://news.ycombinator.com/item?id=42983369 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)?
• semiinfinitely 2y ago
  this person must have never seen a bell curve meme 50 IQ: haha software is complicated whatever 100 IQ: (this post) 150 IQ: software is complicated whatever
• js4ever 2y ago
  Amen! I totally agree with Antirez
• IshKebab 2y ago
  These are just barely meaningful and dubiously accurate rants that are designed to make the author feel superior. > 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.
• davedx 2y ago
  Depends where you work and what on and who with. 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…
• stackedinserter 2y ago
  Maybe we are destroying software, but at the same time we can deliver product/services to customers.
• johannessjoberg 2y ago
  > We are destroying software trying to produce code as fast as possible, not as well designed as possible. Legacy systems are born from rushing into implementation to feel productive rather than understanding the problem. Slow is smooth. Smooth is fast.
  • YZF 2y ago
    Though it's not the only way to create legacy systems. Sometimes they are of sound design which deteriorates over time. Or the requirements shifted such that the design is no longer adequate. Or as the article mentions, rewrites for no good reason. 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.
  • caseyy 2y ago
    Also, simple is evident, smooth, maintainable, and fast. 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.
• foxhop 2y ago
  For somebody who cares about software why are you advertising for disqus comments? Link in bio to a public domain commenting system forn static sites.
• picafrost 2y ago
  I don’t disagree. But if you want to work as an artisan you don’t work at a factory. Similarly, you can’t expect the products coming out of a factory to be at the artisan level. 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.
  • futuraperdita 2y ago
    I think a lot of software engineers have been in denial that we have been working in factories as a lot of the ZIRP-era technical structures were constructed in such a way to make it seem like we were part of guilds. The average company cares about craft only insomuch as it feeds enough product reliability and productivity. 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.
• deleted 2y ago
  [deleted]
• kadushka 2y ago
  2 years from now 99.9% of all software will be written by AI. So just put those statements into your system prompt.
  • khana 2y ago
    [dead]
• ninkendo 2y ago
  > We are destroying software by no longer caring about backward APIs compatibility. 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.
  • debeloo 2y ago
    >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.” 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.
• ongytenes 2y ago
  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. 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.
  • sillysaurusx 2y ago
    But there have always been people who struggle to do basic math. It doesn’t seem true that people will be unable to debug “their own” code, even if it was generated by AI, because people already learn how to debug open source software not written by themselves.
  • layer8 2y ago
    Maybe we should restrict code generation to the dumber models so that we can still use the more lucid models for debugging. ;) (This is an allusion to Kernighan’s lever.)
  • scarface_74 2y ago
    Old folks (raises hand) said the same thing about “high level languages” like C when people don’t learn assembly.
  • fujinghg 2y ago
    People struggle at basic mathematics because they don't need it for daily use in society. And you forget things when you don't use them. 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.
  • epolanski 2y ago
    > Look at how after of calculators became common, we got generations of people who struggle to do basic math. 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?
• karmakaze 2y ago
  It's a good message with poor framing. If anything we're not destroying software, we're making much more than ever, of reduced quality and scope. Could be adjusted to destroying software quality.
  • mihaaly 2y ago
    Related: "We are not dying. That's how we live." Or others may say: "There are software, and there are things remind people of software".
• stefanos82 2y ago
  As soon as I finished reading the article, the very first thing that came in my mind is Dieter Rams' "10 Principles of Good Design"; I have been following his principles as much as I can, as they match, more or less, those of UNIX's philosophy: 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
  • avidiax 2y ago
    These don't sound like the UNIX philosophy. My impression is that UNIX is more like what's outlined here: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/worse-is-better.html https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
    • MonkeyClub 2y ago
      It's informally semi-codified: https://en.m.wikipedia.org/wiki/Unix_philosophy https://en.m.wikipedia.org/wiki/Unix_philosophy
      • pjmlp 2y ago
        A philosophy that gets worship like some cult, and yet most UNIX systems hardly follow up, or most tools when checking those endless man pages full of options.
      • mike_hearn 2y ago
        It's primarily just a statement of widely agreed principles everyone has always claimed to follow, even when UNIX was new, and others arguably followed them with more success e.g. > The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators Nobody says "we want to build complicated, sprawling, unclear, unmodular and rigid code", so this isn't a statement that sets UNIX apart from any other design. And if we look at the competing space of non-UNIX platforms, we see that others arguably had more success implementing these principles in practice. Microsoft did COM, which is a much more aggressive approach to modularity and composable componentization than UNIX. Apple/NeXT did Objective-C and XPC, which is somewhat similar. Java did portable, documented libraries with extensibility points better than almost any other platform. Many of the most famous principles written down in 1978 didn't work and UNIX practitioners now do the exact opposite, like: • "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features" yet the --help for GNU grep is 74 lines long and documents 49 different flags. • "Don't hesitate to throw away the clumsy parts and rebuild them." yet the last time a clumsy part of UNIX was thrown away and rebuilt was systemd, yielding outrage from people claiming to defend the UNIX philosophy. About the only part of the UNIX philosophy that's actually unique and influential is "Write programs to handle text streams, because that is a universal interface". Yet even this principle is a shadow of its former self. Data is exchanged as JSON but immediately converted to/from objects, not processed as text in and of itself. Google, one of the world's most successful tech companies, bases its entire infrastructure around programs exchanging and storing binary protocol buffers. HTTP abandoned text streams in favor of binary. Overall the UNIX philosophy has little to stand apart other than a principled rejection of typed interfaces between programs, an idea that has few defenders today.
• brian-armstrong 2y ago
  Seems like maybe antirez has lost the joy of coding, at least for a little while. 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.
  • antirez 2y ago
    I never lost the joy of coding since I simply do what I want and refuse to do what I don't enjoy. But unfortunately most people can't because of many reasons and I know many that are now very disappointed with the state of software.
    • brian-armstrong 2y ago
      Thanks for replying, and sorry for implying the wrong state of things. 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.
• scarface_74 2y ago
  Opposite anecdote, in the 2000s, I worked at a company that had dozens of computers running jobs, built out a server room with raised floors and built out a SAN to store a whopping 3 TB of data and we had a home grown VB6 job scheduler that orchestrated jobs across the computers running Object Rexx scripts. 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.
  • worik 2y ago
    > As far as backwards compatibility, worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is. Not entirely, there are other reasons too But we should respect semantic versioning. Python is a dreadful sinner in that respect.
    • foobiekr 2y ago
      Semantic versioning is an illusion. It's a human-managed attempt to convey things about the surfaces and behaviors of software systems. Best case, it isn't completely misleading and a waster of everyone's time. 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.
      • worik 2y ago
        > Best case, it isn't completely misleading and a waster of everyone's time You mean best case it is useful
• namuol 2y ago
  Who is “we”? The forces eroding software quality are disproportionately caused by short-sighted VCs.
• deleted 2y ago
  [deleted]
• portaouflop 2y ago
  The less software exists the better.
• sieve 2y ago
  Well, I agree with him to a great extent. 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 https://youtu.be/kZRE7HIO3vk
  • zzo38computer 2y ago
    I agree that you should avoid too many dependences. When I need dependencies, I usually try to reduce how many I need. Often, when I do need dependencies, I will include them with the program (which avoids the problem of breaking compatibility) and they should be small and should not have any of their own dependencies (other than possibly the standard library); often they will be programs that I wrote by myself. Dependencies will sometimes be optional, and those that cannot be included often should be made to be possible to replace with an alternative implementation.
    • chrz 2y ago
      My shop has lightweight template for a service that use spring. I cant change that. Guess how many dependencies spring has
• et1337 2y ago
  A lot of these points are opposites of each other, so much so that it seems intentional. We’re to maintain backward compatibility, yet eschew complexity. 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.
  • siev 2y ago
    It also reads to me like the contradictions are intentional. Something about software today feeling samey and churned-out.
    • abathur 2y ago
      I agree (and I think the ~point is that weighing and being thoughtful about how tradeoffs affect a given project is part of the process).
  • austin-cheney 2y ago
    The most direct resolution to the conflict you mention, and this works for just about everything in life is: 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.
• contingencies 2y ago
  Added to https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup ;)
• aorloff 2y ago
  A huge amount of software is not designed. In fact, simply actually designing software instead of just allowing people to go hack away at things requires a culture around it. 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.
  • icedchai 2y ago
    You are correct, but this goes against what is perceived as "agile." Today, we typically "fix it in the next sprint." It results in poor quality products. And it sucks.
• stego-tech 2y ago
  My own version, from the world of IT. 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.
• tqi 2y ago
  > We are destroying software by no longer taking complexity into account when adding features or optimizing some dimension. Yet: https://x.com/antirez/status/1885994950875046164 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.
  • antirez 2y ago
    If you read the post as: software should not evolve, you are not reading it right. 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.
• meltyness 2y ago
  Is adopting the manifesto a violation of the manifesto?
• FridgeSeal 2y ago
  > 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. > 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.
• nj5rq 2y ago
  > blog comments powered by Disqus Isn't this kind of ironic?
  • shlomo_z 2y ago
    Yes!!
• meltyness 2y ago
  You can't buy proprietary software. You can buy a specification. "my computer does this". If you're building software under agile, the outputs should be a hierarchical specification clearly traceable to code, the specification should remain clean, it could be simply the GUI in some rare, simple cases but that may be short lived, often the docs are an important part of the specification. Ideally, just a handful of high-level user stories that do not close. 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.
• rvz 2y ago
  Now we continue to destroy software due to the immediate need to off-load our thinking to LLMs that pretend to 'reason' and generate code that the engineer has little understanding of which then increases the risk of introducing hidden bugs and lowering software quality.
• cmgriffing 2y ago
  We are destroying software by directly contradicting ourselves when we describe how we are destroying software.
  • antirez 2y ago
    Sometimes, to write a post that makes people think about complicated processes, you need to write statements that may sound dissonant. Reality is complicated and multi-sided, and I want to ignite a reflection on the state of the software which is not specific of a given point of view, but more general: not a single, but a community.
• jumploops 2y ago
  We destroyed software when we stopped writing machine code by hand.
• jvanderbot 2y ago
  "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." 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.
  • deleted 2y ago
    [deleted]
  • Dansvidania 2y ago
    consider the other side too, general purpose "tools" make the engineers relatively interchangeable
• 0xbadcafebee 2y ago
  All of those things have been happening for over a decade. There is no actual discipline of software design today. It's just people googling shit, copy-and-pasting, and praying. 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.
  • rcxdude 2y ago
    The design work in fields which are heavily regulated like that is even more copy-and-pasted. Not only will the average angineer be afraid of solving problems themselves, anyone who is willing to do it will be actively discouraged by the processes from doing so, even if the copy-and-paste answers have severe, known flaws. The grass is not greener on the other side here. (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)
    • 0xbadcafebee 2y ago
• dewey 2y ago
  Today I was working on wrapping some simple Python library into a gRPC service so I can use it from some other Go services. The business logic is around 20 lines. 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."
• khana 2y ago
  [dead]
• braebo 2y ago
  My theory is that software has gotten easier to build, the barrier to entry lowered, the demand for more advanced functionality boomed, and the incentives promoting maintainability and longevity usurped by an ever increasing demand for rapid financial growth.
• nbzso 2y ago
  We are destroying humanity trough software. Someone driven by greed and social validation needs. Someone by technocratic dreams of transhumanism. The cult of acceleration brings inherited error. False productivity and systems for control of thinking and behavioral patterns. In a normal and truly rational world, software is a tool for intent and operation. 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.
• scotty79 2y ago
  We are destroying software by writing it. Perfect, bug-free software is the software that doesn't exist.
• alexashka 2y ago
  So much of life amounts to complaining that others don't think like you and don't value the same things you value :)
• ctrlp 2y ago
  Not a fan of screeds like this. "We" are not doing anything. Some software sucks. Some doesn't. You can choose not to follow practices that produce shitty software. The cream will rise. None of these items is necessary and anyone can simply opt out. Just don't do it that way.
• kreyenborgi 2y ago
  > We are destroying software by making systems that no longer scale down: simple things should be simple to accomplish, in any system. 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.
• DocTomoe 2y ago
  We are also losing the joy of hacking together software by not adapting - or sometimes abandoning - useful development paradigms. 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.
  • petepete 2y ago
    Would FileMaker have worked? It sounds like it's a good fit.
    • DocTomoe 2y ago
      Yes, but it appears that FileMaker only works with their cloud-based DB these days, and I really like my data to stay at home, in something like SQLIte or a NAS-hosted MySQL - mostly so I can directly interface my self-designed scanning/photography/sorting bot to it.
• andrewstuart 2y ago
  So, stop using dependencies, write everything yourself.
• BSDobelix 2y ago
  >We are destroying software telling new programmers: “Don’t reinvent the wheel!” This is such a perfect point, no one would have invented the "tank chain" if reinventing the wheel was not allowed.
  • k8sToGo 2y ago
    It's not that it's not allowed, but for example in security reinventing something goes wrong most of the time. By that I mean writing your own encryption etc. without having a deep expertise in security. 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.
  • marginalia_nu 2y ago
    I'd generalize the entire list to "we're destroying software with rules-based thinking". Almost everything bad in software derives from someone rigidly following rules like don't repeat yourself, don't reinvent the wheel, don't be clever, etc. There are instances where this is good advice, but when they turn into rigid rules, bad software is the inevitable result.
• deleted 2y ago
  [deleted]
• rcarmo 2y ago
  This is timely. I just spent a few hours rewriting my custom homepage/dashboard around a bit of JavaScript that takes a JSON file, fills a few tabs with icons and provides type ahead find functionality to quickly get to the services I want. 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”.
• kryptiskt 2y ago
  > We are destroying software pushing for rewrites of things that work. 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.
  • perfmode 2y ago
    Is someone pushing to rewrite Redis?
    • thom 2y ago
      Microsoft created a managed, wire-compatible alternative: https://github.com/microsoft/garnet https://github.com/microsoft/garnet
    • akshayshah 2y ago
      There’s the Valkey fork, which is now evolving independently. Microsoft’s Garnet and Dragonfly are independent implementations that are pretty different under the hood.
  • blueflow 2y ago
    It surely had better manpages and documentation tho.
  • dvhh 2y ago
    The software does not necessarily need to be written in C ( or C++) for these elementary security holes to happen.
  • lazystar 2y ago
    > The software of the 90s was generally janky in a way that would never be tolerated today. 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.
• ivanb 2y ago
  If this post was written by a non-celebrity, then it would have been immediately buried. But here were are at 771 points for some cheap maxims.
  • antirez 2y ago
    [flagged]
    • lucianbr 2y ago
      Ad hominem much?
      • antirez 2y ago
        [flagged]
        • decayiscreation 2y ago
          I got one. Failed novelist returns to industry, the world has moved past him. Sour grapes. Get off my lawn!
          • antirez 2y ago
            The word had moved past Redis already when I started it. Redis is an experiment in minimalism, and because of that was an industry anomaly. Wohpe is probably the novel that sold the most copies in the recent years italian sci-fi history. This summer a new short story of mine will be released by the most important italian sci-fi series. Meanwhile you need to post this from a fake account. What you can show me, of your accomplishments, with your real name? Here to listen, with genuine interest.
    • sublinear 2y ago
      We are destroying software by letting business pit devs against each other.
  • 2y ago
• ecocentrik 2y ago
  Most novice programmers reject the complexity created by others in favor of their own.
• gregors 2y ago
  >>>> We are destroying software by jumping on every new language, paradigm, and framework. The young grow old and complain about change. The cycle of life continues.
• anon-3988 2y ago
  Turns out writing software is hard? Actually no, its people that is hard. If we all can just agree on using whatever language X, framework Y or tool Z, then we would just be done with it.
  • oneplane 2y ago
    It's not only people that is hard, it's network effects that are very significant here. The article also describes all sorts of truths in isolation, but the processes where these things happen do not exist in isolation. 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.
• openrisk 2y ago
  Software is a cultural artifact. It reflects the society and economy that produces it, just as much as music, literature, urban design, or cuisine. 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.
  • nirui 2y ago
    Agreed with most part about cultural artifact, but some food is scientifically proven unhealthy, and there are unsafe way to create software. So maybe there are statically measurable way to create better software instead of just cave in to the trend.
    • openrisk 2y ago
      There is a certain amount of "convergence" of good practices thats happening despite the exhausting trend following. E.g. people happily(?) wrote c++ code for decades but today there is strong pressure from the success of ecosystems like rust and python. Open source accelerates that competitive evolution as it improves transparency and lowers the threshold for adoption.
• rednafi 2y ago
  When an ecosystem tries to go in the opposite direction, the mob shreds it to pieces, chanting, “Smart devs don’t use it,” “Only mid people like that,” and “The universe is memory unsafe, gotta rewrite.” Then, PL creators whose language isn’t even at 1.0 light the fuse.
• aiono 2y ago
  I am a bit confused because many things he criticise are opposite of each other. Such as adding complexity with new features and backward compatibility, or not inventing the wheel and using new tools.
• dartos 2y ago
  Unfortunately putting time and effort into quality software wasn’t in our pitch deck. 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.
• fennecbutt 2y ago
  We, or them?
• teucris 2y ago
  I’ve heard these statements before, and I agree with the general sentiment, but I’ve yet to hear a solid set of solutions. Many of these statements are contradictory, or at least hide opposing principles. For instance: > 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.
• neycoda 2y ago
  Yah, well, use AI and you won't have to worry about software much.
• AntonCTO 2y ago
  We are destroying software by believing we are right and others are wrong. 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.
• gofreddygo 2y ago
  > We are destroying software by no longer taking complexity into account 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