5 ms·

I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. It's all about stuffing as many features in as q

I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. It's all about stuffing as many features in as quickly as we can and pushing it out to as many people as possible. Performance is always secondary. Not that I'm that nostalgic for the old days, we would have been doing the exact same thing if we were able to get away with it. But performance restrictions meant you had no choice but to care. Modern tech has "freed" us from that concern.

trealira 2y ago
Niklaus Wirth wrote about this in 1995, in his essay A Plea for Lean Software. About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much). An operating system had to manage with 8,000 bytes, and a compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary, were it not for a thousand times faster hardware, modern software would be utterly unusable. https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rRUwInv7E https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR... That said, as someone fairly young, I still don't think that makes it wrong or something only an old man would think. Software seems to perform exactly as well as it needs to and no more, which is why hardware advances don't make our computers run software much faster.
- joelwilliamson 2y ago
  “What Andy giveth, Bill taketh away”
- nextos 2y ago
  Aside from slowness, feature creep leads to poor quality, i.e. tons of bugs and user confusion with ever-changing graphical interfaces. If software was simpler, we could afford to offer some formal guarantees of correctness. Model check protocols, verify pre and post conditions à la Dafny, etc. There's too much change for the sake of change.
  - aylmao 2y ago
    > There's too much change for the sake of change. +1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally. The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's almost no other option but to introduce change for the sake of change.
    - etruong42 2y ago
      This is exactly what I see as well. At a general level, I believe there are other options - changes/features need to meet some level of usage or it is scrapped out of recognition that supporting all these features make bugs more likely, performance likely to degrade, increase difficulty of adding features, make the product more difficult to use, etc.
  - aylmao 2y ago
    > There's too much change for the sake of change. +1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally. The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's often almost no other option but to introduce change for the sake of change.
    - chipsrafferty 1y ago
      I once asked a man who worked in marketing why Oreos keep making crazy new flavors like "sour patch kids Oreos" when the normal kind is great and clearly has no issues being sold. I could see some upside - it gets people talking about them, it's fun, it reinforces the normal flavor as the best chocolate cookie, etc. but I was still dubious that those benefits outweighed the cost of developing new flavors in a lab, paperwork for food safety, a new manufacturing process, new ads, new packaging, etc. especially for something temporary. He said it's often just some new marketing exec wants to put something on their resume, and they have certain metrics that they target that don't necessarily align with long term profits of the company. I'm sure software has a similar problem.
- naikrovek 2y ago
  software authors that don't care about performance annoy me (and I am an old man.) The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today. I'm not talking about "write in assembly, duh" I'm talking about just doing things intelligently instead of naively. The developers I support often simply are not thinking about the problem they're solving and they solve the problem in the simplest way (for them) and not the simplest way for a computer. Software is an inefficiency amplifier, because the number of developers for a piece of code is much smaller than the number of computers that run that code; how much coal has been burned solely because of shitty implementations? I'd wager that the answer is "a LOT!" Even if you don't care about coal usage, think about how much happier your users would be if your application was suddenly 5x faster than it was previously? now think of how many customers want their software to be slow (outside of TheDailyWTF): zero. languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. JS and Electron are great for developers, and horrible for users because of that amplification I described above. I am dead tired of seeing hustle culture overtake everything in this field, and important things, to me, like quality and performance and support all fall straight down the toilet simply because executives want to release features faster. things like copilot could help with this, i hope. presumably copilot will help introduce better code into applications than a daydreaming developer would, though the existence of vibe coding sort of nulls that out probably. one thing that AI will do quite soon is increase the amount of software that exists quite dramatically. and I am kinda concerned about the possibility that it's all going to suck horribly.
  - ralphc 2y ago
    What's your proposal for a "compromise" language between programmer productivity and performance, especially for multiple threads and CPUs? Go, Rust, a BEAM language?
    - t917910 2y ago
      [flagged]
- vacuity 2y ago
  I'm also young and heavily favor simple, quality software. Age is a highly coarse proxy for one's experiences, but in this case I think it has more to do with my personality. I have enough experience in computing that I don't think I'm making demands that are unrealistic, although they are certainly unrealistic if we maintain current incentives and motives.
- etruong42 2y ago
  > Software seems to perform exactly as well as it needs to and no more The cynical spin I would put on this idea is that software performs as poorly as it can get away with. MSFT is feeling the need/pressure to have Office load faster, and they will try to get away with preloading it. Otherwise, there is a strong pull towards bloat that different people will try to take credit for as features even if the cumulative experience of all these "features" is actually a worse user-experience.
gwbas1c 2y ago
It was always like that
ysofunny 2y ago
we don't have software engineering anymore than the romans had civil engineering we now DO have civil engineering but that is it
mapt 2y ago
I saw the writing on the wall when I had to install a couple 150MB IDEs to run 101-level Java programs in the mid 2000's. 150 megabytes. MEGABYTES. I could consume about 1 kilobyte per minute of fantasy novel text in uncompressed ASCI, call it 1/8th that fully compressed. That means this compressed binary you're handing me is around 1.2 billion minutes of work (more if ingesting a novel is faster than writing/testing/debugging a program) for what is functionally a text editor, file manager, syntax library, compiler, and debugger. Pretty sure that got done in 150 kilobytes a generation earlier. A generation later, maybe it will be 150 gigabytes.
- netsharc 2y ago
  I looked it up, you want an illegal taxi? 168 MB: https://apkcombo.com/uber/com.ubercab/ https://apkcombo.com/uber/com.ubercab/
- reaperducer 2y ago
  install a couple 150MB IDEs Not Java, but an IDE in 4K: https://en.wikipedia.org/wiki/BASIC_Programming https://en.wikipedia.org/wiki/BASIC_Programming Having used it quite extensively (Well, five solid days over two weeks, which is about 1000x longer than most people gargling on the internet), it's surprisingly capable. Imagine if someone with the same talent and motivation was working on today's hardware. <aside> Someone on Atari Age wrote a LISP for the same machine.
MisterTea 2y ago
> I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. Indeed. I am sure many of us here are burnt out on bloat. I am also sure many of us want to move to smaller stuff but cant simply because of industry momentum. BUT that doesn't mean the dream is dead, only that we must work towards those goals on our own time. I found Plan 9 and haven't looked back. I can rebuild the entire OS in seconds on a fast machine. Even my little Celeron J1900 can rebuild the OS for several supported architectures in minutes. I can share a USB device seamlessly across my network, PXE booted from a single disk without installing anything. Cat(1) is just 36 lines of C. There's still hope. Just ignore the industry hype noise and put in the effort ourselves.
- ryandrake 2y ago
  And just when we think we can't make software any more inefficient, slow, and bloated, they release things like Electron, where you ship an entire browser with your app! And then when we think it can't even get worse, we have Docker and containers where we ship the entire OS with the application. I'm looking forward to when app developers ship you an entire computer in the mail to run their text editor.
  - bloomca 2y ago
    The problem with Electron is that business-wise it is an excellent decision. You can get by with a few people to wrap the web app and integrate it with the OS, and then get updates pretty much for free. Yet for the user it is bad -- bloated, slow, feels non-native, has specific bugs which are hard to address for the devs, etc. I don't see any light for the desktop UI development unless there is some lightweight universal rendering engine. Tauri with WebView is somewhat promising, but it has problems on Linux and it is hard to target older systems.
    - bigstrat2003 2y ago
      It's an excellent business decision... right up until your customers abandon you because you make bad quality software. Like many businesses have found time and again, deliberately sacrificing quality for profit is a short term gain for a long term loss.
zer00eyz 2y ago
>> It's all about stuffing as many features in as quickly as we can... The problem isn't "engineering" the problem is the culture of product management. (Note: NOT product managers per se). I ask this basic question, how many Directors, VP's or CPO's do you know who got their job based on "cutting out unused features"? If you can find one, it will end up being the exception that proves the rule. The culture of "add", "new" and "shiny" doesn't reward keeping things lean and effective. T In the tangible world we look to accountants for this sort of thing (because they tend to have costs). Think cheap Costco hotdogs and free cookies at Double Tree. No one in product, dev and accounting is going to sit down and try to justify loosing some code, features and maybe a few customers to make it faster when you can just "engineer" you way out of it and not have to sell less is more.
- zero_bias 2y ago
  > I ask this basic question, how many Directors, VP's or CPO's do you know who got their job based on "cutting out unused features"? Google goes a step further and kills entire apps
  - LuciOfStars 2y ago
    Moment of silence for Play Music. YT Music isn't any less awful now than it was a decade ago.
- bigfatkitten 2y ago
  Ford does. They look at connected vehicle telemetry to strip out features nobody uses in order to save software maintenance, hardware and third party IP licensing costs. https://www.slashgear.com/1513242/ford-gets-rid-of-self-parking-feature-reason-explained/ https://www.slashgear.com/1513242/ford-gets-rid-of-self-park...
ambicapter 2y ago
I really don't think we've "lost it", I think performance has just not been a consideration in the engineering of Office for a long time, if ever.
- deleted 2y ago
  [deleted]
Salgat 2y ago
It's a matter of resource allocation. Lowering your design requirements for performance can save significant developer cost. Also, Word in 2025 is doing a lot more under the hood than 97.
acdha 2y ago
How does someone get promoted at Microsoft? How do they avoid being seen as a low performer? Performance just isn’t on that list, and it’s often more and harder work than a given new feature took to create. Office users are getting what Microsoft is designed to deliver.
- deleted 2y ago
  [deleted]
gregates 2y ago
I love that I work at a place (Row Zero) where caring about performance is baked into the culture, and I can spend days fixing weird perf edge cases our users discover without management asking why I'm wasting my time. And it's office software, no less!
90s_dev 2y ago
> we've lost the art of software engineering Yes! This is what all my projects are geared towards restoring. The big one is not quite ready to announce yet, but I am very proud of it, and extremely excited to release it, to solve exactly that: it makes engineering fun again!
- makapuf 2y ago
  Well that username matches
lispisok 2y ago
My personal theory is there is a threshold of performance. Below the threshold the experience is bad enough it affects revenue so getting the program up to speed becomes a priority. Above the threshold only features are prioritized to drive more revenue. That's why despite computers getting orders of magnitude faster computer programs seem to run about the same speed.
- nativeit 2y ago
  I think the threshold is more about how much more rent can we seek to collect from users, and making things more performant or ergonomic doesn’t do anything to allow sales to add another 10% to the per-user subscription pricing (I assume this is a product with per-user subscriptions, even though it’s almost certainly unnecessary). But adding yet another gateway to ChatGPT’s API…that’s a $15/mo/user add-on right there, and not just a monkey, but one of the slower intern monkeys, could write the code for such an incredibly innovative and, there’s no other word for it, powerful new feature that everyone should be thrilled to pay for at a 200-300% (or more!) markup. So guess who gets that VP of New Bullshit Development position, and guess what kind of choices get reinforced? (EDIT: grammar)
trinsic2 2y ago
> I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. Absolutely this. I think this is evidence that points to modern civilization starting to collapse. When we can engineer correctly, we're fucked.

trealira 2y ago

Niklaus Wirth wrote about this in 1995, in his essay A Plea for Lean Software. About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much). An operating system had to manage with 8,000 bytes, and a compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary, were it not for a thousand times faster hardware, modern software would be utterly unusable. https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rRUwInv7E https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR... That said, as someone fairly young, I still don't think that makes it wrong or something only an old man would think. Software seems to perform exactly as well as it needs to and no more, which is why hardware advances don't make our computers run software much faster.

joelwilliamson 2y ago
“What Andy giveth, Bill taketh away”
nextos 2y ago
Aside from slowness, feature creep leads to poor quality, i.e. tons of bugs and user confusion with ever-changing graphical interfaces. If software was simpler, we could afford to offer some formal guarantees of correctness. Model check protocols, verify pre and post conditions à la Dafny, etc. There's too much change for the sake of change.
- aylmao 2y ago
  > There's too much change for the sake of change. +1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally. The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's almost no other option but to introduce change for the sake of change.
  - etruong42 2y ago
    This is exactly what I see as well. At a general level, I believe there are other options - changes/features need to meet some level of usage or it is scrapped out of recognition that supporting all these features make bugs more likely, performance likely to degrade, increase difficulty of adding features, make the product more difficult to use, etc.
- aylmao 2y ago
  > There's too much change for the sake of change. +1 to this. Like a lot of issues, I think the root is ideological, but this one in particular very clearly manifests organizationally. The companies building everyday software are ever bigger— full of software engineers, designers and various kinds of managers who are asked to justify their generous salaries. At an individual level I'm sure there's all sorts of cases, but at a general level there's often almost no other option but to introduce change for the sake of change.
  - chipsrafferty 1y ago
    I once asked a man who worked in marketing why Oreos keep making crazy new flavors like "sour patch kids Oreos" when the normal kind is great and clearly has no issues being sold. I could see some upside - it gets people talking about them, it's fun, it reinforces the normal flavor as the best chocolate cookie, etc. but I was still dubious that those benefits outweighed the cost of developing new flavors in a lab, paperwork for food safety, a new manufacturing process, new ads, new packaging, etc. especially for something temporary. He said it's often just some new marketing exec wants to put something on their resume, and they have certain metrics that they target that don't necessarily align with long term profits of the company. I'm sure software has a similar problem.
naikrovek 2y ago
software authors that don't care about performance annoy me (and I am an old man.) The amount of things a computer can do in a single thread are amazing, and computers now have a dozen or more threads to do work. If developers cared about performance, things would easily be 20x as performant as they are today. I'm not talking about "write in assembly, duh" I'm talking about just doing things intelligently instead of naively. The developers I support often simply are not thinking about the problem they're solving and they solve the problem in the simplest way (for them) and not the simplest way for a computer. Software is an inefficiency amplifier, because the number of developers for a piece of code is much smaller than the number of computers that run that code; how much coal has been burned solely because of shitty implementations? I'd wager that the answer is "a LOT!" Even if you don't care about coal usage, think about how much happier your users would be if your application was suddenly 5x faster than it was previously? now think of how many customers want their software to be slow (outside of TheDailyWTF): zero. languages like javascript and python remove you so much from the CPU and the cache that even if you were thinking of those things, you can't do anything about it. JS and Electron are great for developers, and horrible for users because of that amplification I described above. I am dead tired of seeing hustle culture overtake everything in this field, and important things, to me, like quality and performance and support all fall straight down the toilet simply because executives want to release features faster. things like copilot could help with this, i hope. presumably copilot will help introduce better code into applications than a daydreaming developer would, though the existence of vibe coding sort of nulls that out probably. one thing that AI will do quite soon is increase the amount of software that exists quite dramatically. and I am kinda concerned about the possibility that it's all going to suck horribly.
- ralphc 2y ago
  What's your proposal for a "compromise" language between programmer productivity and performance, especially for multiple threads and CPUs? Go, Rust, a BEAM language?
  - t917910 2y ago
    [flagged]
vacuity 2y ago
I'm also young and heavily favor simple, quality software. Age is a highly coarse proxy for one's experiences, but in this case I think it has more to do with my personality. I have enough experience in computing that I don't think I'm making demands that are unrealistic, although they are certainly unrealistic if we maintain current incentives and motives.
etruong42 2y ago
> Software seems to perform exactly as well as it needs to and no more The cynical spin I would put on this idea is that software performs as poorly as it can get away with. MSFT is feeling the need/pressure to have Office load faster, and they will try to get away with preloading it. Otherwise, there is a strong pull towards bloat that different people will try to take credit for as features even if the cumulative experience of all these "features" is actually a worse user-experience.

gwbas1c 2y ago

It was always like that

ysofunny 2y ago

we don't have software engineering anymore than the romans had civil engineering we now DO have civil engineering but that is it

mapt 2y ago

I saw the writing on the wall when I had to install a couple 150MB IDEs to run 101-level Java programs in the mid 2000's. 150 megabytes. MEGABYTES. I could consume about 1 kilobyte per minute of fantasy novel text in uncompressed ASCI, call it 1/8th that fully compressed. That means this compressed binary you're handing me is around 1.2 billion minutes of work (more if ingesting a novel is faster than writing/testing/debugging a program) for what is functionally a text editor, file manager, syntax library, compiler, and debugger. Pretty sure that got done in 150 kilobytes a generation earlier. A generation later, maybe it will be 150 gigabytes.

netsharc 2y ago
I looked it up, you want an illegal taxi? 168 MB: https://apkcombo.com/uber/com.ubercab/ https://apkcombo.com/uber/com.ubercab/
reaperducer 2y ago
install a couple 150MB IDEs Not Java, but an IDE in 4K: https://en.wikipedia.org/wiki/BASIC_Programming https://en.wikipedia.org/wiki/BASIC_Programming Having used it quite extensively (Well, five solid days over two weeks, which is about 1000x longer than most people gargling on the internet), it's surprisingly capable. Imagine if someone with the same talent and motivation was working on today's hardware. <aside> Someone on Atari Age wrote a LISP for the same machine.

MisterTea 2y ago

> I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. Indeed. I am sure many of us here are burnt out on bloat. I am also sure many of us want to move to smaller stuff but cant simply because of industry momentum. BUT that doesn't mean the dream is dead, only that we must work towards those goals on our own time. I found Plan 9 and haven't looked back. I can rebuild the entire OS in seconds on a fast machine. Even my little Celeron J1900 can rebuild the OS for several supported architectures in minutes. I can share a USB device seamlessly across my network, PXE booted from a single disk without installing anything. Cat(1) is just 36 lines of C. There's still hope. Just ignore the industry hype noise and put in the effort ourselves.

ryandrake 2y ago
And just when we think we can't make software any more inefficient, slow, and bloated, they release things like Electron, where you ship an entire browser with your app! And then when we think it can't even get worse, we have Docker and containers where we ship the entire OS with the application. I'm looking forward to when app developers ship you an entire computer in the mail to run their text editor.
- bloomca 2y ago
  The problem with Electron is that business-wise it is an excellent decision. You can get by with a few people to wrap the web app and integrate it with the OS, and then get updates pretty much for free. Yet for the user it is bad -- bloated, slow, feels non-native, has specific bugs which are hard to address for the devs, etc. I don't see any light for the desktop UI development unless there is some lightweight universal rendering engine. Tauri with WebView is somewhat promising, but it has problems on Linux and it is hard to target older systems.
  - bigstrat2003 2y ago
    It's an excellent business decision... right up until your customers abandon you because you make bad quality software. Like many businesses have found time and again, deliberately sacrificing quality for profit is a short term gain for a long term loss.

zer00eyz 2y ago

>> It's all about stuffing as many features in as quickly as we can... The problem isn't "engineering" the problem is the culture of product management. (Note: NOT product managers per se). I ask this basic question, how many Directors, VP's or CPO's do you know who got their job based on "cutting out unused features"? If you can find one, it will end up being the exception that proves the rule. The culture of "add", "new" and "shiny" doesn't reward keeping things lean and effective. T In the tangible world we look to accountants for this sort of thing (because they tend to have costs). Think cheap Costco hotdogs and free cookies at Double Tree. No one in product, dev and accounting is going to sit down and try to justify loosing some code, features and maybe a few customers to make it faster when you can just "engineer" you way out of it and not have to sell less is more.

zero_bias 2y ago
> I ask this basic question, how many Directors, VP's or CPO's do you know who got their job based on "cutting out unused features"? Google goes a step further and kills entire apps
- LuciOfStars 2y ago
  Moment of silence for Play Music. YT Music isn't any less awful now than it was a decade ago.
bigfatkitten 2y ago
Ford does. They look at connected vehicle telemetry to strip out features nobody uses in order to save software maintenance, hardware and third party IP licensing costs. https://www.slashgear.com/1513242/ford-gets-rid-of-self-parking-feature-reason-explained/ https://www.slashgear.com/1513242/ford-gets-rid-of-self-park...

ambicapter 2y ago

I really don't think we've "lost it", I think performance has just not been a consideration in the engineering of Office for a long time, if ever.

deleted 2y ago
[deleted]

Salgat 2y ago

It's a matter of resource allocation. Lowering your design requirements for performance can save significant developer cost. Also, Word in 2025 is doing a lot more under the hood than 97.

acdha 2y ago

How does someone get promoted at Microsoft? How do they avoid being seen as a low performer? Performance just isn’t on that list, and it’s often more and harder work than a given new feature took to create. Office users are getting what Microsoft is designed to deliver.

deleted 2y ago
[deleted]

gregates 2y ago

I love that I work at a place (Row Zero) where caring about performance is baked into the culture, and I can spend days fixing weird perf edge cases our users discover without management asking why I'm wasting my time. And it's office software, no less!

90s_dev 2y ago

> we've lost the art of software engineering Yes! This is what all my projects are geared towards restoring. The big one is not quite ready to announce yet, but I am very proud of it, and extremely excited to release it, to solve exactly that: it makes engineering fun again!

makapuf 2y ago
Well that username matches

lispisok 2y ago

My personal theory is there is a threshold of performance. Below the threshold the experience is bad enough it affects revenue so getting the program up to speed becomes a priority. Above the threshold only features are prioritized to drive more revenue. That's why despite computers getting orders of magnitude faster computer programs seem to run about the same speed.

nativeit 2y ago
I think the threshold is more about how much more rent can we seek to collect from users, and making things more performant or ergonomic doesn’t do anything to allow sales to add another 10% to the per-user subscription pricing (I assume this is a product with per-user subscriptions, even though it’s almost certainly unnecessary). But adding yet another gateway to ChatGPT’s API…that’s a $15/mo/user add-on right there, and not just a monkey, but one of the slower intern monkeys, could write the code for such an incredibly innovative and, there’s no other word for it, powerful new feature that everyone should be thrilled to pay for at a 200-300% (or more!) markup. So guess who gets that VP of New Bullshit Development position, and guess what kind of choices get reinforced? (EDIT: grammar)

trinsic2 2y ago

> I know this is such a stereotypical "get off my lawn" statement but we've lost the art of software engineering. Absolutely this. I think this is evidence that points to modern civilization starting to collapse. When we can engineer correctly, we're fucked.