This is a massive change from my first software industry job in 1997.
I was essentially a “design intern who knows HTML” on a team that built a shrinkwrap Windows application for enterprises. The core of the design team was a graphic designer, a cognitive scientist, an industrial designer, and a product manager with industry experience in the customer domain.
The application was Windows native. User research was conducted on site with scientific rigor. Adhering to platform guidelines and conventions was a priority. I think I spent a few weeks redrawing hundreds of toolbar icons so they’d be in line with the Office 97 look (the kind of boring job you give to the junior). If the app stood out on the Windows desktop, that would have been considered problematic.
Today a similar design team would only have a graphic designer and a PM, and neither of them would care the slightest about platform guidelines or customer domain. The UI is primarily an extension of the corporate brand. Hiring a cognitive scientist? Forget about it…
Everything certainly wasn’t perfect in the Windows/Mac desktop golden era. But the rise of the web wiped out a lot of good industry practices too.
THANK YOU!
None of the current SaaS apps I use can come close to the experience of using softwares from that era.
Take a simple list view of a typical Windows/Mac software?
1. Command clicking selected multiple objects
2. Shift clicking selected a range.
3. Right clicking brought up selection actions.
4. Double clicking opened an object.
This pattern was followed in almost list views and there was no re-learning and surprises.
Now can you say the same about the list views of modern web apps?
Can you apply the same list selection experience across Google Drive and Microsoft OneDrive and Apple iCloud? Nope.
That's were we failed as an industry. We let a lot of designers run too wild with their ideas, to put it bluntly.
Maybe the list of docs in https://docs.google.com?
Best example: Gmail is one of the only webapps I'll ctrl click a few items at the top of the list, ctrl click a few in the middle, and then shift click to the bottom and it works exactly how I'd expect - everything stays selected and the shift+click selects from your previous click to the next item. I think it gets wonky if you change directions but I can't imagine how I'd expect ctrl+click item 1, 2, 9, 10, then shift click on 4 would work.
Having just checked, this is indeed what the file explorer on my desktop does, and I'm pretty sure windows file explorer does the same.
Animations may seem fine and fun the first time you encounter one, but when you think you'll have to suffer through it every time an action is taken, it becomes a whole different story.
Not to mention that with SaaS being more profitable than selling, a lot of apps also have backends, and webapp versions, which can share a lot of HTML/CSS/JS code with the desktop version. Sure: Qt, Flutter, etc have web versions, but they just don't look/feel good.
If you want a "Premium" native look and feel, people gotta go directly to the source and Qt won't cut without a lot of work. Lots of companies have separate Android and iOS teams. Or they go directly to HTML (or things like Flutter, which look ok in mobile). High-quality macOS apps, like those made by Panic, Rogue Amoeba, etc, use Cocoa directly.
Standardized controls and shortcuts are a secondary concern to all this.
If you want a "Premium" native look and feel
It is things like Qt that only HN and online nerds care about.
Don't get me wrong: I really like well made native apps and I think they're great. But Qt isn't as great as software made with native toolkits directly.
The primary advantage of web apps is "zero install", which is a major point of friction at large corps.
Citation needed. Currently working in a jQuery+Coffeescript app that still works like a charm.
No it doesn't, the HTML spec hasn't changed, whereas QT has. The issue is how the webapps were built in the first place. You don't need Nextjs and all it's friends to post a form to a backend once an hour but somehow that is becoming the standard approach...
For macOS check apps made by Apple (Logic, Final Cut), Panic, Rogue Amoeba, or apps like Pixelmator, Affinity, Pixelmator, TablePlus, Tower, Dash... there's more.
There's even open source ones like IINA providing a premium look+feel.
Perhaps Cordova/Ionic, when it tried to imitate the look iOS/Android's native controls.
I've seen this regurgitated a hundred times, but I don't really know any more what that "native look and feel" is. On Windows, it might be the old Windows 95 controls, but those are quite limited. What system today is made of dropdowns, checkboxes and OK buttons?
But by Premium yeah, I'm talking more about macOS, iOS and Android here.
For macOS apps made by Apple, Panic, Rogue Amoeba, or apps like Pixelmator, Affinity, Pixelmator, TablePlus, Tower, Dash.
Windows, or MacOS, both have design guidelines that was produced, and they expected native apps to follow. Most native apps do (the few that doesn't have either good reason, or were unique enough that their customers don't care - think photoshop).
With the advent of the web, such a guideline for software no longer mattered, because the controls and UI elements are all custom - since html is not an application GUI library!
So every man and their dog has a different UX and UI interaction built for their own app, because the web encourages it. The designers are also at fault for not standardizing on a set of common UI widgets, but i cannot blame them as this isn't the easiest path.
It almost sounds old-fashioned in 2023 to talk about usability, affordance, and user-experience.
Part of being a native application was/is for the application to look and behave like the rest of the user interface. Standards are important because learning how to use a tool is important. Users are important.
Software has become a way to make users miserable. Oh, and while confusing them, throw some advertising at them too. ^_^
CTRL+A selects all
CTRL+Shift+End selects all from where you are to the end
CTRL+Shift+Home selects all from where you are to the top
One of the (many) problems of web UIs is they often ignore the keyboard completely.
>CTRL+Shift+Home selects all from where you are to the top
Those two don't need CTRL, just so you know.
>One of the (many) problems of web UIs is they often ignore the keyboard completely.
They are also starting to ignore the mouse.
Well, yes they do, only it's different with and without CTRL. For example in a text editor (or a normal webpage without any fancy JS):
- Shift+End goes to the end of the line
- CTRL+Shift+End goes to the end of the document
and the same is true for Home (substitute "end" with "beginning").
I have seen people, even "technical" people, select a text with the mouse from the middle of a large Word document to the end, because they didn't know this.
They also had to do it often (several times a day) and it had become a significant part of their workload...
I'm afraid you're looking at the past with rose-tinted glasses. In general software back then sucked hard. User experience did not existed at all. Developers bundled stuff around, and users were expected to learn how to use software. Books were sold to guide desperate users through simple user flows. Forms forms forms forms everywhere, and they all sucked, no exception. Forget about localization or internationalization. Forget about accessibility. Developers tweaked fonts to be smaller to shove more controls into the same screen real estate, and you either picked up a magnifying glass to read what they said or you just risked it and clicked on it anyway.
Software back then sucked, and sucked hard. Atrocities like Gimp were sold as usability champions. That's how bad things were.
It’s sad just where we are now compared to the design goals of old.
Even in Linux there were tools to sync gnome with QT look so you could have one theme applied to every app for nice and consistent look, all the way to how the common icons look.
Nowadays ? Every fucking app gotta have their own different styling. Will the setting icon be three dots, gear, or honey badger ? WHO FUCKING KNOWS. You'd be lucky if you even get a choice between light and dark theme
But hey, we can write same code to work on windows, mac and mobile ! It will work shit in all of them and be slow but we don't care!
There are still such tools, you don't have to use the past tense here.
Total flashbacks to windows 95 and every so often changing the windows color, text font etc. for the entire system
Good times
Multiple hamburger menus with a scattering of cryptic icons stuck at arbitrary places on the screen. What does the swirly icon with up arrow do? No text label for you!
Oh and let's move the next button to the top left of the screen and not highlight it. Mmmm that's some good UI design.
Have you considered that the average user never cared and never will?
Having ultra consistent styling across all apps ruins the ability to... you know... sell the software. It gives far too much power to some group of annoying elitist nerds in denial of their opinions preaching UI/UX pseudoscience.
> But hey, we can write same code to work on windows, mac and mobile ! It will work shit in all of them and be slow but we don't care!
Ain't nobody got time for reading even shittier documentation for badly written OS APIs.
This has more to do with the current state of GUI frameworks than with developer mindset. Microsoft is between GUI frameworks and rumoured to have deprecated everything between win32 and WPF, and in the meantime they are pushing React Native. Apple doesn't seem to know what to do with desktop environments and is stuck between their legacy objective C frameworks which they seem to purposely hide any form of documentation and swift-based frameworks which are broken out of the box. Linux has a couple of options which are ugly as sin since ever. There's Qt, but their licensing scares away anyone with two brain cells to rub together.
So where are we left?
Well, with webview-based frameworks, which is the worst of both worlds but at least they don't look half bad.
Except that webview-based frameworks are a far lower-level abstraction than any native widget-based framework. Developers are forced to reinvent the wheel, and this means dropping any standard look-and-feel because that's already ugly to start with but takes even more work to get into a working state.
And all you want to do is to provide a GUI for users to click around.
The indie scene is looking excellent however, a lot of programmers who have already made their money seem to be pushing excellent hobby projects out.
Now you don't have to. So no one does.
I’m all for craftsmanship, but having four top guys fiddling with design.. it all depends on the domain I guess.
Yes, absolutely necessary cost.
In the former you make money from selling the result, in the latter you make money from selling the hours spent creating the thing.
If the former is unusable it will lead to bad sales. In the latter it might even lead to additional hours sold in change requests.
The former is bought often after evaluation and comparison by the user of the software. The latter is sold to an executive that will never have to use the software as a project.
I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high.
I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.
I have seen low level parts that are managed well, because employees have skin in the game
But I’ve also seen a lot of what this post is talking about
I am the lead because I know, from experience, not to allow this kind of nonsense to happen.
It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me.
But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time reviewing PRs.
Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so.
It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it works, it stays, however ugly and costly.
That isn't to say some things don't get refactored, but there's a strict business case that needs to be met. Usually if the system is under performing, error-prone or end-users want features/performance that can't be accommodated without a refactor.
It's nice. The latest framework isn't being integrated year after year, there's no microservices, nothing fancy.
It's java. It's tested. It works. It makes money. It pays.
Stability is something that must be culturally hammered and enforced by leadership.
Much of the same reasoning and even more extremely applied, is medtech - hence why you see many medical imaging setups still obviously running a version of Windows XP.
The cost (financial, legal, reputation) of certain classes of bugs is so high that avoiding those risks becomes top concern.
One calculation issue, one buggy float operation means millions or billions in damage and the loss of your clients ... never to return ... because your name is tarnished.
I actually think this is _wrong_ and we need better resiliency in finance to being able to roll-back transactions and rewind and replay with adjustments.
Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft).
If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary.
On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).
If I were a client, I wouldn't want these perverse incentives to exist. I would want a razor sharp focus on _my_ needs, and assurance that _my_ needs are modelled in the billing.
And for that, I would pay more.
... and well paid.
In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/...
Like most other engineering in the world really.
Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
We _do_ have instances where target systems for deployment become ABI/API incompatible with the libraries, which is rare and happens roughly every 5 years.
The project was structured to put stability at the core, rather than being cutting edge.
My Product Manager is competent both in technical and product/design matters and is also able to call BS on complexity for complexity sake. I ensure that the development part is focused.
New developers have to prove with technical arguments any new paradigm or random refactoring they want to do. I'm pretty chill, though.
I think your experiences may be skewed by the position you find yourself in?
That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.
The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.
I can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight.
A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.
However, a large and insidious cadre of B tier engineers was constantly writing docs proposing meaningless arbitrary system changes and new designs for the sake the changes themselves. These new projects were the only way to get promoted. The entire e4->5->6->7 track was written in such a way that it only ever encouraged “TL”/“architect”types to grow.
This led to constant churn, horrible codebases, and utter bullshit self made problems which could only be solved by digging a deeper hole.
There are companies who handle this well. Ultimately it comes down to engineering culture.
Until we figure out a nice metric for "removing complexity" and then rewarding for it, it's not likely to change, IMO.
From my view, that and pressure from the analyst racket are the main drivers behind feature bloat with self promotion a distant third.
We also get slower with so many people. The coordination overhead is killer and losing context as the product is sliced up into small parts that move on without you
I half-disagree with this. My take is significantly more top-down: senior management has a deficient concept of how product development works. They believe Manpower is to be spent to achieve revenue, either by directly selling the result as a product (e.g. airplanes selling wifi to passengers) or by it being a differentiating feature for the sales department. This causes every allocation decision (like hiring) to fundamentally be biased around getting a tangible return: by creating new projects, new features, and new buggy microservices.
Further, since management only has two knobs (manpower and timeline) to play with, they like to move them to feel like they're optimizing the project. It's always the same fallacies, too: "we hired more people so we can create explosive growth", "we created ambitious timelines, now we're striving to fill them" etc.
I don't have a solution for this, except to note that it can be mitigated by managing up. Construct your own narrative, and take advantage of the fact that the non-technical people above you govern almost entirely by gut feeling.
If we had a smaller and more competent team, the initial build might have been marginally slower, but we wouldn’t have to spend a permanent 50% to just keeping down the technical debt.
Is cost efficiency an effective perspective for innovation or revenue growth? Mostly, no. As long as your risk-of-ruin is low, then you want to fail. Sometimes people misinterpret this as “doing the wrong thing”. But it takes doing a lot of wrong things to do the right thing.
The difference between right and wrong, if there ever was such a simple dichotomy, is so marginal and only understood in hindsight.
Ultimately you end up in the same spot, but one choice is fairly suboptimal there.
But this is why some executives are better for some kinds of businesses and others are better for other kinds. Some executives don't understand your parent comment's point (or just don't find it comfortable), and will be very allergic to the "waste" necessary to experiment and iterate on poorly understood projects. Other executives will be uncomfortable just constantly figuring out how to optimize costs without damaging revenues.
A very tricky part of the lifecycle of many companies that get gigantic is to figure out when to flip this and start switching out the executive team to focus on a different model.
everything about engineering group decisions are about creating a reason to use a newer framework in a way other people can vouch for.
He also holds a grudge against me for having dared to rewrite a sacred C library he wrote (that was a constant source of segfault and I rewrote in 1 afternoon).
The problem with "given more authority" I see is that management plucks these engineers out to make their day job basically "sit in meetings" if you're even slightly effective at simplifying life for everyone else.
Because that is the place of most leverage to place those people, but then those people are in a constant tug-of-war with the first group of "fresh ideas".
Eventually, the people who are in charge of the "prevention of bad architecture" become the bad guys because they (or me, I'm projecting) get jaded into just finding out what's wrong with something as fast as possible to be able to keep up with that workload.
You go from a creative role to a fundamentally sieve role with destructive tendencies, where you are filtering out the good from the bad as fast as possible, be.
First of all, not all new ideas are bad and "there's something bad about X" is not a "let's not do X".
Secondly, going from making things to shooting down things is intellectual suffering if you have a bit of empathy.
Some people on the "committee" with you don't have empathy & literally enjoy it - you're either trying to damage control on a case-by-case or building a "these assholes need to be fired" doc out of the meetings.
I realized what I would become if I conflated authority and respect ("respect my authoritah!").
Quitting was really the only way out of it. But it wasn't hard to explain to my spouse that i needed to leave for a job a level down and which paid half as much, because she could see me bringing my "why the hell do we have to do this" attitude home & to family decisions.
I’ve found the opposite. The young engineers are generally willing to listen to reason. The older Enterprise Architects are the ones that want to keep making things more complicated, or want to keep using suboptimal solutions because we’ve been using them for years.
Now that I write it down it’s kind of curious how on one hand it’s complicating things with stuff they already know, and on the other hand it’s absolute rejection of stuff they don’t.
Maybe I’m the same?
I hope that I live to see a time when software applies modern algorithms to classic designs and produce “hand tools” in software.
Please.
And also why the most frequent request from the users is: Please don't change anything.
The principal-agent problem looms large in software.
I think it is: "Please don't change anything I did not request"
(who does not hate updates that break your workflow?)
But they usually very much like changes, that makes life easier for them. Best way to find out, is to watch them using your tool and talk with them.
FOSS software has vastly different incentives than commercial software, yet suffers from many of the same problems: bugginess, poor performance, lack of documentation, feature misprioritization, bad UI.
That alone indicates that the problem is not merely "misaligned incentives".
Actually, you can reduce most problems down to "misaligned incentives" if you're overly reductive enough. That doesn't mean that it's a useful way to think about the world.
Some other incentives are balanced, though. Persistent low performance or bugginess affects the author and end users equally; the more the author uses their own software, the more this will hurt. Sometimes the low performance is a design trade off; Python isn't Rust, and the users seem to be okay with that. It was done on purpose. Sometimes low performance is a factor of the author's needs; you're trying to run the thing on 1 billion machines, they only have 1; something has got to give. But that's not misaligned incentives so much as it is lack of suitability for a particular purpose. A screwdriver is terrible for hammering in nails. That's not the screwdriver's fault.
It's really hard to tell what the motivation of any given free software author is. That makes it really hard to even know what incentives matter to any give author, team or community. It's just really diverse.
> That's true! But there is almost no incentive to have users; you pay a cost, but they pay nothing in return.
It's fascinating to see free software with huge user bases getting on with a tiny number of contributors. It seems like good code + near zero support cost + near zero support expectation seems to work.
In retrospect - it was recognized that they built or took good care of money making systems with little drama and that was well appreciated by the companies.
In FAANGs I see now more of "what will get me promoted" versus "what is gonna make the company money" ethos.
(The correct solution, obviously, is that universities should be sustainably state-funded and not require mega-donors with their associated insanities, etc. to survive.)
The alternative is often paying $1K for some barely maintained triplex basement shared bedroom off of campus, from a negligent landlord.
I’ll say one thing though: all of those skills you mentioned as not being valued are extremely useful for indie dev/taking ownership. Shipping simple + correct code frequently is extremely possible with sufficient practice and discipline.
More to your point, this is why I switched toward being a research engineer. There is a higher barrier of entry, projects are quite technically challenging, and constraints often force thinking of a world of computing beyond the tiny sphere of the web browser.
It’s hard work, but I love it.
If this resonates, you are in the US, and looking for a change, drop me a note (see profile).
Not gonna convince anyone but hopefully someone reads this and starts thinking about such options. They are not as impossible as those in power would have us believe.
- There is bias towards rewarding more lines of code or more code commits (which is often the exact opposite of what characterizes good software design).
- There is bias towards rewarding speed of initial implementation (which often goes against medium-term and long term maintainability and ability to handle requirement changes which is usually far more important). The costs of this tends to fall on other developers who come in later and act as scapegoats for the 'apparent 10x developer'.
- The industry keeps dismantling narratives which would otherwise help to reward talent. For example, many companies dismiss the idea of a '10x developer' - Probably because they are aware of the previous point about the fast developer who cuts corners and creates technical debt for others. 10x developers do exist, but they're not what most people expect because paradoxically, they may be slow coders when it comes to LOC metrics and speed of implementation for new features; their code really only shines in the medium and long run and it improves the productivity of their colleagues too so it's hard to properly allocate credit to 10x devs and they only really matter on greenfield projects.
I feel like I've fallen into this hole at my current gig, where I just churn shit out to solve a problem as quickly as possible
I get away with it just bc general code quality was already not good to begin with
Biggest mistake was going fast the first time, now I'm getting assigned way more shit
Word of advice to readers: don't make the same mistake I made. You'll just get taken advantage of
Unfortunately, for my money, I think the only real way you can create an incentive structure which emphasizes stability and change is by offering some kind of form of insurance.
My father was an electrician who often complained about how he never got paid adequately for the stellar, stable work he did, and one day I asked him whether he ever thought of raising his rates but providing a kind of service guarantee, where if a problem occurred that could be traced back to his own work, he would step in and perform the additional work at a reduced fee. Naturally he laughed out loud, because that's not how business works.
Ownership of an already-mature product is sort of like providing an insurance policy by default, of course. And sticking with conventional designs can be a solid business strategy if you use their slow-changing nature to e.g. build the thing faster than you could otherwise. That's the strategy I'm using for my consulting: Stick with what we know best (Hugo+Bootstrap for a napkin sketch UI demo as fast as possible, then SQLite+Django+React to build out the main functionality ASAP too). Emphasize solving the _business_ problem over the shiny tech.
An ex-director of a French national security agency complained about exactly that during an interview, that you get more budget after a terrorist attack, or after you stop one that was well under way, but never if you avoided the condition to create a terrorist cell altogether, or nipped it in the bud.
It was quite telling that after 1.5 years of that project, where all staff had already been replaced once, all they had to show for was a fancy product name and a presentation. And that the manager that led the project for ~2 years left right before or right when it went live - and he did that in a previous project too, where a working .NET backend for ecommerce was replaced with a Scala microservices on AWS system.
I did hear about the latter; I heard they went back to .NET, but the Scala services are still up and running and a maintenance nightmare.
But the lead developer got to play with his favorite tool and landed a job at lightbend because of it. Career-driven development, and I don't even believe he did it for his own career, but for self-gratification. Ecommerce is boring; REST APIs and a front-end are boring. But Scala, distributed systems, AWS, that's all cool and new.
I'm so tired.
I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational.
If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).
Worse, you’ll be blinded by survivability bias. One easily notices the good rewrites and can easily ignore the bad ones.
Even worse, bad rewrites may be noticed in a place that a year or two ago was deemed a success story. I’ve seen many such cases due to misunderstandings or just political dynamics.
And lastly, don’t let that Engineer do Scala, they’ll brush off the compilation time regression and make all developers lives slightly worse (assuming the project is big enough)
Like choosing GraphQL just because it's new, even if your data doesn't have the structure for it.
Will have to disagree with you on Scala for several reasons I won't go into here--but the point was just that, in order to make these arguments in the first place, you need to do your research. Seems commonsense, but surprisingly many people don't do it (including younger me).
This. I recall the case of a couple of FANGs who on one hand expect their engineers to deliver simple, maintainable and robust systems to minimize operational costs, but on the other hand they demand engineers operate at the next level to be considered for a promotion, which means they are expected to design non-trivial systems which have a certain degree of complexity and require significant amounts of work to pull off. Therefore, as an unintended consequence, the pressure inexperienced engineers to push needlessly complex projects where they are required to design solutions well above their level of expertise, and put them in a position where their career is personally threatened if anything gets between them and their promotion-driven project.
I blame Career-Driven Development for a lot of "shiny toy" (i.e. failed and complicated) projects.
Whether that's wrong is a deeper question - if it leads to better salary through job-hopping and promotions, despite a catalog of failures, is it actually the wrong approach from an individual engineer perspective?
I still say yes, FWIW; I enjoy seeing my projects succeed and thrive. But I know others may disagree.
1. No designer is given promotion for sticking to conventional designs. It's their creative & clever designs that get them attention and career incentives.
2. No engineer is paid extra for keeping the codebase without growing too much. It's re-writes and the effort he puts in to churn out more solutions (than there are problems) that offers him a chance to climb the ladder.
3. No product manager can put "Made the product more stable and usable" in their resume. It's all the new extra features that they thought out, which will earn them reputation.
Our industry thrives on producing more solutions than needed. Efforts are rewarded based on conventional measurements, without thinking through- in what directions were the efforts pointed at.
Unless the incentives of everyone involved are aligned with what's actually needed, we'll continue solving imaginary problems, I guess.