That argument still doesn't make sense; writing a manual clone() implementation or renaming a function call isn't hard, but nobody would say that automatically doing either of those things isn't worthwhile.
I've also noticed that during parts of my life where I was typing much slower (switching keyboard layouts) I found myself a lot less inclined to experiment, and it negatively affected my development.
Conversely recently finished an LLM-assisted refactor that involved a fairly mechanical change that would have been an absolute nightmare to do by hand, not because it was difficult, but because it would have probably involved 3 hours of boring, mind-numbing "make this change, look at where the compiler errors are, propagate", repeated 5 times over. It's not hard, but I wouldn't have done it without LLM assistance because it was just so tedious. (Interestingly, the model wound up writing a god-awful Python script that covered 90% of the cases and then chasing down the rest "by hand".)
I just finished a multi-hour session of thoroughly auditing the asm of Zig's clone(2) syscall wrappers, and then opened Lobsters and read this comment as the very first thing...
Ah, sorry. What I mean is that something can be easy and still worth significantly automating (or doing faster or similar); I apologize for implying something you didn't say.
That argument still doesn't make sense; writing a manual clone() implementation or renaming a function call isn't hard, but nobody would say that automatically doing either of those things isn't worthwhile.
I think that misses the point. We've always automated or paid for the conduction of easy tasks. Nobody claims they aren't tasks. And tasks you want to automate.
Clicking a button once a day/week/month isn't hard, but a cronjob is still worthwhile.
I've also noticed that during parts of my life where I was typing much slower (switching keyboard layouts) I found myself a lot less inclined to experiment, and it negatively affected my development.
I have had the opposite in that if a thought lingered longer new better approaches came to mind (more performant, simpler, easier to read, more DRY code).
Your last paragraph I agree with, in the same sense that an editor/IDE with good regexp replace or refactoring related functionality can save you a lot of time. However, I think this isn't all that related to what "code was never was the hard part" means.
In the context of LLMs I think it means at times what people mean when they talking about "prompt engineering" (which I hate as a term, because it implies things that make no sense, but that's another topic). In that you first need to know what you actually want. A classic situation is when I as a programmer am ask to do X, when I know I will need to ask why they want to do X, because if I just implemented it I might make things worse rather than better. Eg. their goal might be achieved in a way that is less hassle for them, me and might even be a lot more reliable.
Also to be clear, I am not saying that LLMs are not or will never be capable of that. Just that I think coding as in "writing yet another endpoint that outputs something from the database" obviously was never something that a novice programmer couldn't do likely on the side. However because of that fact that also wasn't the thing that made people earn salaries or else there would only be junior programmers.
Writing code not being the hard part of software engineering is analogous to producing correct English prose not being the hard part of writing a novel.
Beautiful, compelling, evocative prose is another matter, for which the analogy continues to hold.
I would be insulted if I was told that producing compiling code that technically does what's in some ticket is the primary part of what I do, that's hardly engineering.
There's a lot of work happening in software development where this is exactly the main part of the job. It may not be everyone's job, but "here's a simple bug/feature, get it done" is a huge part of the system. There's also the "here's the new law/spec, update the systems" in a few industries. (Most of my clinic's software updates are data/rule updates related to billing) It's not a technically hard part either really - it just takes lots of time and resources which makes it overall a hard part of the process.
And the volume itself can become an issue as well - you can produce more test inputs, reviews, security checks, etc. just by volume. These are often things that are trivial to make but just need doing. If you can't type them fast enough, but want to achieve maximum reliability, that in itself is a hard problem too. We solved some of it with meta approaches like fuzzing and automated checks, but that's not nearly enough.
To be clear, that idea doesn't take anything away from actual software engineering being a hard task.
I can see that point, and I can also yield that there are some domains where programming in of itself is a valuable, difficult endevour, albeit mostly in low level, performance sensitive areas.
In the general case, my impression is that the hierarchy of software engineering (Junior->Mid->Senior->Staff) is setup that way for a reason, sort of in the same way academia has been setup where grad students solve time-intensive but otherwise easily solvable problems as part of their learning process, whilst still contributing to the overall corpus. This is falling apart in the same way, it is unfortunate.
The "bulk" work is/was done by people newer to the craft of engineering as part contribution, part education, and the point remains that this wasn't the "hard" part of the job. In the same way, the problems grad students solve are hard sure, but saying that those problems are not "the hard part" of frontier research isn't an insult to grad students everywhere, and it would be arrogant to assert that it was.
‘Code was never the hard part’ is the excuse some people are peddling to keep themselves employable.
One thing AI has revealed is how much of public software development, in blogs, at conferences, was, for some, a performative ritual to court the interest of potential employers and investors.
When expertise was rewarded, these people role played as experts. When Open Source was seen as a resume booster, these people loved Open Source. Now that these things have been devalued, these people will pretend that they were always the essential human element in software development.
Fine so far, I actually do think software development needs a human element. But these people also find it a convenient part of their story to minimize the importance of that other skill, software development, because it is no longer a career enhancing one.
This seems really negative. Do you earnestly believe that most conference activity is performative? That certainly hasn’t been my experience in the Python community or my perception of most peoples’ blogs.
(It seems to me like a lot of people enjoy sharing the things they learn, and if we’re to buy into a human-centric future we should encourage that, not demean it as performance.)
This blog post feels like a strawman argument. What to build is also about programmers (personally I like the term software engineers better) making decisions. For example they need to decide on a fitting tech stack. You need expert software engineers to know or at least understand all the footguns of that decision. AI will provide a tech stack, but that may very well bite you someday in the future and this happens with every larger application. Not generating tons of tech debt while implementing features is really hard and needs experience, just implementing a solution you just need to be smart.
Yes, you might say the one where they have the most experience with or they are experts in. So they hopefully know most of the foot guns.
The question now follows what if you don‘t have any tech stack you are familiar with. Which do you choose?
Also the tech stack includes many micro decisions in the middle
of a project about interfaces, boundaries, new dependencies, deprecations, etc. It is not one and done. These can also accumulate tech debt over time.
I've heard that argument a number of times and I think the author is reading it in a fairly uncharitable way. I'm not saying my understanding is more "correct", but in the context of LLMs, I understood it as "producing lines of code was never the bottleneck" - i.e., you can't be a 100x+ engineer just because you have Claude, even though it does produce code at 100x+ your speed.
Another way of putting it is that some amount of friction is good because it prevents you from creating software that's utterly unnecessary, unmaintainable, or otherwise useless.
I don't know if this will hold true in the long haul, but again, that's how I read the argument.
I think it's possible to objectively estimate the maximum speedup factor from coding agents for a given engineer, by just measuring the fraction of time that engineer used to spend on coding, and applying Amdahl's Law.
I do believe that talking to users, understanding their experience, empathizing with them, solving customers' problems and having all the stakeholders on the same page is critical to the success of a software project.
I also believe that creating good code is a craft that requires skill, patience, attention to detail, experience and wisdom, and that it will continue to be relevant in the times ahead.
I agree with this, which seems to be the heart of the article. But doesn't that just reinforce the argument that, "Code was never the hard part"? As the quote argues, It is good code that requires the non-AI craft of "skill, patience, attention to detail, experience and wisdom". Therefore, we can all slope code, even the machines. Is the article title just bait then?
If you're arguing that anti-AI sentiment is an "insult" to programmers, you really have to follow through with it.
If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?
Now that is an insult. It is not about copying, it is about attribution. I want my work to be copied. I want to be useful in this life. What I don't want is to be exploited. We are better together. Which I would suggest is the actual sentiment behind, "Code was never the hard part". How do we work with other people? How do I write code that is easy for other people to understand? How do I conduct myself in such a way that I make it easy for people to approach me and feel comfortable about contributing to my code? AI is fundamentally opposed to this perspective, both industrially by its capitalist owners and technically by being trained as a mere token prediction machine.
I'm reminded of the house shares I lived in when I was younger. It wasn't the fact that I did more chores than everyone else that upset me, it was the fact that certain housemates were annoyed when washing up wasn't done or rubbish wasn't taken out. Perhaps they were the budding AI enthusiasts? Unaware of how the world actually works, they think they're above menial tasks and therefore delight in confidently arguing that everybody else is too.
for a bigcorp that have a lot of software developers, code was never the hard part, and in this angle the sentence has a strong point: for such companies llm's seem like a financial optimization
if we take the sentence at face value then yeah its an insult, like alsmo any other sentence can be seen as an insult, but it is not intended a such, and the target of this sentence is those doing the layoffs and driving the narrative that llms will crush us all, the ones that have developers to the thousands and yet take the common falacy stance that those that produce the value are the ones that accumulate it (not the workers)
Another cliché comment is “most work in software development is talking to stakeholders, understanding the customer's needs, and having clarity on the priorities”.
This bit really resonated with me. My current project at work is a multi-month rewrite to get better performance out of a system that wasn't designed for all the things that was asked of it as we built features on top of it. There is very little of the "human-y" bits that I sometimes see brought up as the "true" essence of software development; it would be absurd to suggest that the true work is in figuring out that, shockingly, customers prefer fast responses to slow ones.
Your engineering task is to write a system that is more able to resist changing requirements and having features built atop of it, such that it does not readily require a multi-month rewrite in the future as this old system has. This is a very human thing to have happened, and will require a human-centric outlook, of both your current and future customers, as well the people who work and will work in your organization. You will predict the potential quantity and qualities of potential future requirement shifts, and balance these against delivery trade-offs and constraints of the present moment.
We already have the design of the system, which did take a while. The multi-month part is in implementing it, because there are a lot of moving parts, prototyping, and other such things involved. Even after all the work you mentioned, there is still a lot of "non-human-centric" work.
I read it as "99% of time immediately commercially significant code has never been the problem". As in fundamental science vs applied, research vs engineering.
This doesn't mean that engineering is easier or less respected in my eyes, it's just the actual thought density of a unit of code is lighter and there is a ton of economics and social interaction playing immediate role.
We sort of talk more than code because the market is ever changing, while academy solves long range more stable problems.
If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?
I will withhold comment on whether programming is easy or difficult. However, demand for software engineers was never about difficulty and always about time. In two ways.
First, a simple point: easy things can also take a long time. It is not difficult to figure out how to put together a jigsaw puzzle such that you are confident you will complete it. It still takes a very long time.
The more important point is about investment and the time value of money. The reason software engineers were in such demand is because there was a gigantic set of businesses that were ripe for digitization. They were in industries known to be profitable with clear management strategies for successful deployment of capital. The incumbents had fixed costs linked to pre-digital delivery. You could effectively borrow unlimited money from the future revenues of these businesses in order to be the first to secure the market lead in each industry. This was essentially the entire SaaS boom.
Software will be getting more complex. Software will always need maintenance: bit-rot is a fact of life. So is entropy. Technology (hardware and software) will move forward, for better or worse. The tower (skyscraper?) of abstractions grows ever higher.
This is depressing. Here we are, someone who cares about the craft deeply enough to write this blog post, only to hit me with this cynical take. Don't give up, dammit!
Let me break this down.
Technology (hardware and software) will move forward, for better or worse.
That one seems okay, obvious even, depending on what one means by "moving forward". My problem is the rhetorical trick this truism is used for: juxtapose a number of loosely related statements together, some of which will be perceived as obviously true by the reader, so the less obvious ones will appear truer, or more inevitable, than they actually are.
Software will be getting more complex. […] The tower (skyscraper?) of abstractions grows ever higher.
Those two are the same statement. And they might even be true. But they are in no fucking way desirable. Software complexity is a cost, that ought to be minimised. And in my experience, software is way more complex than it has any right to be. Everywhere I go, almost without exception, I see code that looks way more convoluted than the problem required. And when I actually put that to the test, I find out that most of the time I can indeed contribute serious simplifications.
Now, if this complexity was a necessary side effect of the associated achievements or capabilities, I would welcome it. But that's not what I'm seeing. Instead I seems we do pretty much the same things as before, only less efficiently. Computers have become so much faster, we just don't see it. We've become complacent.
Software will always need maintenance: bit-rot is a fact of life. So is entropy.
This is ridiculous. Widely believed, hardly ever contested, but still utterly ridiculous. There are two aspects to address here.
First, it's not the code that rots. It's the environment around it that's unstable. This can be mitigated in two ways: first is being serious about backward compatibility: DO NOT BREAK USER-SPACE! It's not always ideal. Coming up with the perfect API first time is really hard, and fixing mistakes can only bloat it. But it does reduces the bit rot of your dependencies.
Second, you can chose your dependencies more carefully. Instead of the latest framework, maybe you can write more things in-house, and stick to dependencies you know don't change much, if at all. And when you do depend on something substantial, write a wrapper, so that when it changes you only have to rewrite your wrapper, not sweep your entire code base for deprecated function calls.
This requires care and investment, sure. But we can be done. We can finish software. Or at least get close enough that it hardly matters.
grahamc | 16 days ago
I always heard this as "typing was never the hard part" which I feel pretty good about.
quasi_qua_quasi | 16 days ago
That argument still doesn't make sense; writing a manual
clone()implementation or renaming a function call isn't hard, but nobody would say that automatically doing either of those things isn't worthwhile.I've also noticed that during parts of my life where I was typing much slower (switching keyboard layouts) I found myself a lot less inclined to experiment, and it negatively affected my development.
Conversely recently finished an LLM-assisted refactor that involved a fairly mechanical change that would have been an absolute nightmare to do by hand, not because it was difficult, but because it would have probably involved 3 hours of boring, mind-numbing "make this change, look at where the compiler errors are, propagate", repeated 5 times over. It's not hard, but I wouldn't have done it without LLM assistance because it was just so tedious. (Interestingly, the model wound up writing a god-awful Python script that covered 90% of the cases and then chasing down the rest "by hand".)
tobin_baker | 16 days ago
LOL I read this as "writing a manual clone(2) implementation isn't hard"
alexrp | 16 days ago
I just finished a multi-hour session of thoroughly auditing the asm of Zig's
clone(2)syscall wrappers, and then opened Lobsters and read this comment as the very first thing...grahamc | 16 days ago
I mean, if you don't know how to type (which you didn't at the time) then I can imagine that being the hard part of the job.
In your example of the LLM-assisted refactor, the hard part wasn't typing then either.
I'm not sure what you think my position is.
quasi_qua_quasi | 16 days ago
Ah, sorry. What I mean is that something can be easy and still worth significantly automating (or doing faster or similar); I apologize for implying something you didn't say.
reezer | 15 days ago
I think that misses the point. We've always automated or paid for the conduction of easy tasks. Nobody claims they aren't tasks. And tasks you want to automate.
Clicking a button once a day/week/month isn't hard, but a cronjob is still worthwhile.
I have had the opposite in that if a thought lingered longer new better approaches came to mind (more performant, simpler, easier to read, more DRY code).
Your last paragraph I agree with, in the same sense that an editor/IDE with good regexp replace or refactoring related functionality can save you a lot of time. However, I think this isn't all that related to what "code was never was the hard part" means.
In the context of LLMs I think it means at times what people mean when they talking about "prompt engineering" (which I hate as a term, because it implies things that make no sense, but that's another topic). In that you first need to know what you actually want. A classic situation is when I as a programmer am ask to do X, when I know I will need to ask why they want to do X, because if I just implemented it I might make things worse rather than better. Eg. their goal might be achieved in a way that is less hassle for them, me and might even be a lot more reliable.
Also to be clear, I am not saying that LLMs are not or will never be capable of that. Just that I think coding as in "writing yet another endpoint that outputs something from the database" obviously was never something that a novice programmer couldn't do likely on the side. However because of that fact that also wasn't the thing that made people earn salaries or else there would only be junior programmers.
elliotmorris | 16 days ago
This seems like a misunderstanding of the point.
Writing code not being the hard part of software engineering is analogous to producing correct English prose not being the hard part of writing a novel.
Beautiful, compelling, evocative prose is another matter, for which the analogy continues to hold.
I would be insulted if I was told that producing compiling code that technically does what's in some ticket is the primary part of what I do, that's hardly engineering.
viraptor | 16 days ago
There's a lot of work happening in software development where this is exactly the main part of the job. It may not be everyone's job, but "here's a simple bug/feature, get it done" is a huge part of the system. There's also the "here's the new law/spec, update the systems" in a few industries. (Most of my clinic's software updates are data/rule updates related to billing) It's not a technically hard part either really - it just takes lots of time and resources which makes it overall a hard part of the process.
And the volume itself can become an issue as well - you can produce more test inputs, reviews, security checks, etc. just by volume. These are often things that are trivial to make but just need doing. If you can't type them fast enough, but want to achieve maximum reliability, that in itself is a hard problem too. We solved some of it with meta approaches like fuzzing and automated checks, but that's not nearly enough.
To be clear, that idea doesn't take anything away from actual software engineering being a hard task.
elliotmorris | 16 days ago
I can see that point, and I can also yield that there are some domains where programming in of itself is a valuable, difficult endevour, albeit mostly in low level, performance sensitive areas.
In the general case, my impression is that the hierarchy of software engineering (Junior->Mid->Senior->Staff) is setup that way for a reason, sort of in the same way academia has been setup where grad students solve time-intensive but otherwise easily solvable problems as part of their learning process, whilst still contributing to the overall corpus. This is falling apart in the same way, it is unfortunate.
The "bulk" work is/was done by people newer to the craft of engineering as part contribution, part education, and the point remains that this wasn't the "hard" part of the job. In the same way, the problems grad students solve are hard sure, but saying that those problems are not "the hard part" of frontier research isn't an insult to grad students everywhere, and it would be arrogant to assert that it was.
michiel | 16 days ago
‘Code was never the hard part’ is the excuse some people are peddling to keep themselves employable.
One thing AI has revealed is how much of public software development, in blogs, at conferences, was, for some, a performative ritual to court the interest of potential employers and investors.
When expertise was rewarded, these people role played as experts. When Open Source was seen as a resume booster, these people loved Open Source. Now that these things have been devalued, these people will pretend that they were always the essential human element in software development.
Fine so far, I actually do think software development needs a human element. But these people also find it a convenient part of their story to minimize the importance of that other skill, software development, because it is no longer a career enhancing one.
yossarian | 16 days ago
This seems really negative. Do you earnestly believe that most conference activity is performative? That certainly hasn’t been my experience in the Python community or my perception of most peoples’ blogs.
(It seems to me like a lot of people enjoy sharing the things they learn, and if we’re to buy into a human-centric future we should encourage that, not demean it as performance.)
JulianWgs | 16 days ago
This blog post feels like a strawman argument. What to build is also about programmers (personally I like the term software engineers better) making decisions. For example they need to decide on a fitting tech stack. You need expert software engineers to know or at least understand all the footguns of that decision. AI will provide a tech stack, but that may very well bite you someday in the future and this happens with every larger application. Not generating tons of tech debt while implementing features is really hard and needs experience, just implementing a solution you just need to be smart.
valenterry | 15 days ago
Sorry, but most will just pick the language and tech stack they are most familiar with...
JulianWgs | 15 days ago
Yes, you might say the one where they have the most experience with or they are experts in. So they hopefully know most of the foot guns.
The question now follows what if you don‘t have any tech stack you are familiar with. Which do you choose?
Also the tech stack includes many micro decisions in the middle of a project about interfaces, boundaries, new dependencies, deprecations, etc. It is not one and done. These can also accumulate tech debt over time.
lcamtuf | 15 days ago
I've heard that argument a number of times and I think the author is reading it in a fairly uncharitable way. I'm not saying my understanding is more "correct", but in the context of LLMs, I understood it as "producing lines of code was never the bottleneck" - i.e., you can't be a 100x+ engineer just because you have Claude, even though it does produce code at 100x+ your speed.
Another way of putting it is that some amount of friction is good because it prevents you from creating software that's utterly unnecessary, unmaintainable, or otherwise useless.
I don't know if this will hold true in the long haul, but again, that's how I read the argument.
tobin_baker | 15 days ago
I think it's possible to objectively estimate the maximum speedup factor from coding agents for a given engineer, by just measuring the fraction of time that engineer used to spend on coding, and applying Amdahl's Law.
tombh | 15 days ago
I agree with this, which seems to be the heart of the article. But doesn't that just reinforce the argument that, "Code was never the hard part"? As the quote argues, It is good code that requires the non-AI craft of "skill, patience, attention to detail, experience and wisdom". Therefore, we can all slope code, even the machines. Is the article title just bait then?
If you're arguing that anti-AI sentiment is an "insult" to programmers, you really have to follow through with it.
Now that is an insult. It is not about copying, it is about attribution. I want my work to be copied. I want to be useful in this life. What I don't want is to be exploited. We are better together. Which I would suggest is the actual sentiment behind, "Code was never the hard part". How do we work with other people? How do I write code that is easy for other people to understand? How do I conduct myself in such a way that I make it easy for people to approach me and feel comfortable about contributing to my code? AI is fundamentally opposed to this perspective, both industrially by its capitalist owners and technically by being trained as a mere token prediction machine.
I'm reminded of the house shares I lived in when I was younger. It wasn't the fact that I did more chores than everyone else that upset me, it was the fact that certain housemates were annoyed when washing up wasn't done or rubbish wasn't taken out. Perhaps they were the budding AI enthusiasts? Unaware of how the world actually works, they think they're above menial tasks and therefore delight in confidently arguing that everybody else is too.
HugoDaniel | 15 days ago
for a bigcorp that have a lot of software developers, code was never the hard part, and in this angle the sentence has a strong point: for such companies llm's seem like a financial optimization
if we take the sentence at face value then yeah its an insult, like alsmo any other sentence can be seen as an insult, but it is not intended a such, and the target of this sentence is those doing the layoffs and driving the narrative that llms will crush us all, the ones that have developers to the thousands and yet take the common falacy stance that those that produce the value are the ones that accumulate it (not the workers)
quasi_qua_quasi | 16 days ago
This bit really resonated with me. My current project at work is a multi-month rewrite to get better performance out of a system that wasn't designed for all the things that was asked of it as we built features on top of it. There is very little of the "human-y" bits that I sometimes see brought up as the "true" essence of software development; it would be absurd to suggest that the true work is in figuring out that, shockingly, customers prefer fast responses to slow ones.
elliotmorris | 16 days ago
Your engineering task is to write a system that is more able to resist changing requirements and having features built atop of it, such that it does not readily require a multi-month rewrite in the future as this old system has. This is a very human thing to have happened, and will require a human-centric outlook, of both your current and future customers, as well the people who work and will work in your organization. You will predict the potential quantity and qualities of potential future requirement shifts, and balance these against delivery trade-offs and constraints of the present moment.
quasi_qua_quasi | 16 days ago
We already have the design of the system, which did take a while. The multi-month part is in implementing it, because there are a lot of moving parts, prototyping, and other such things involved. Even after all the work you mentioned, there is still a lot of "non-human-centric" work.
southclaws | 15 days ago
I think picasso's famous "quick sketch" story "no, that took me 40 years" is very relevant here.
vegai | 15 days ago
In a way, it's also an insult to most LLMs too. As if coding was the only thing they can do.
peter-leonov | 15 days ago
I read it as "99% of time immediately commercially significant code has never been the problem". As in fundamental science vs applied, research vs engineering.
This doesn't mean that engineering is easier or less respected in my eyes, it's just the actual thought density of a unit of code is lighter and there is a ton of economics and social interaction playing immediate role.
We sort of talk more than code because the market is ever changing, while academy solves long range more stable problems.
dvogel | 15 days ago
I will withhold comment on whether programming is easy or difficult. However, demand for software engineers was never about difficulty and always about time. In two ways.
First, a simple point: easy things can also take a long time. It is not difficult to figure out how to put together a jigsaw puzzle such that you are confident you will complete it. It still takes a very long time.
The more important point is about investment and the time value of money. The reason software engineers were in such demand is because there was a gigantic set of businesses that were ripe for digitization. They were in industries known to be profitable with clear management strategies for successful deployment of capital. The incumbents had fixed costs linked to pre-digital delivery. You could effectively borrow unlimited money from the future revenues of these businesses in order to be the first to secure the market lead in each industry. This was essentially the entire SaaS boom.
Loup-Vaillant | 15 days ago
This is depressing. Here we are, someone who cares about the craft deeply enough to write this blog post, only to hit me with this cynical take. Don't give up, dammit!
Let me break this down.
That one seems okay, obvious even, depending on what one means by "moving forward". My problem is the rhetorical trick this truism is used for: juxtapose a number of loosely related statements together, some of which will be perceived as obviously true by the reader, so the less obvious ones will appear truer, or more inevitable, than they actually are.
Those two are the same statement. And they might even be true. But they are in no fucking way desirable. Software complexity is a cost, that ought to be minimised. And in my experience, software is way more complex than it has any right to be. Everywhere I go, almost without exception, I see code that looks way more convoluted than the problem required. And when I actually put that to the test, I find out that most of the time I can indeed contribute serious simplifications.
Now, if this complexity was a necessary side effect of the associated achievements or capabilities, I would welcome it. But that's not what I'm seeing. Instead I seems we do pretty much the same things as before, only less efficiently. Computers have become so much faster, we just don't see it. We've become complacent.
This is ridiculous. Widely believed, hardly ever contested, but still utterly ridiculous. There are two aspects to address here.
First, it's not the code that rots. It's the environment around it that's unstable. This can be mitigated in two ways: first is being serious about backward compatibility: DO NOT BREAK USER-SPACE! It's not always ideal. Coming up with the perfect API first time is really hard, and fixing mistakes can only bloat it. But it does reduces the bit rot of your dependencies.
Second, you can chose your dependencies more carefully. Instead of the latest framework, maybe you can write more things in-house, and stick to dependencies you know don't change much, if at all. And when you do depend on something substantial, write a wrapper, so that when it changes you only have to rewrite your wrapper, not sweep your entire code base for deprecated function calls.
This requires care and investment, sure. But we can be done. We can finish software. Or at least get close enough that it hardly matters.