5 ms·

This "software grows too complex" is certainly a culture issue, and not a software problem. It mostly comes from businesses throwing a bunch of under-skilled la

This "software grows too complex" is certainly a culture issue, and not a software problem. It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly. Of course it will outgrow the ability of that team to work with, reason about, keep clean, and extend. They will get frustrated and move on, and a new group comes in, re-writes it from scratch, and so it goes. Look at software that has been around for decades, continues to improve, never "needs" a re-write, and will never be re-written. It exists and is not uncommon. Things like the linux kernel, all the GNU utils, emacs, vim, apache, nginx, postgres. The list goes on. We know how to write software that lasts for decades, continuously improves, and doesn't need constant re-writes. You give it to skilled people who care about it, and don't put artificial corporate constraints or impose fad architectures on them. I'm not saying the corporate model is "wrong" - it works. "Works" means it builds companies and generates profit. That is the goal. But it will not generate stable long lived well designed software. That's okay though because that isn't the goal. Sure, the poor quality cuts into the margins a bit, but not enough to matter.

sethetter 4y ago
I'm curious how big of a factor a consistent core team is to having long-term sustainable and stable software. When companies have people rotating on projects constantly and the original vision and design principles of the product are lost or changed, I can only imagine that contributes to the problem.
- phendrenad2 4y ago
  I think that's a big factor. This is what RSUs and bonuses are supposed to solve: You entice employees to stay rather than job hop. However, companies have gotten too greedy and RSUs amount to a pittance, a vestigial perfunctory play act mimicking a bygone era.
  - amenghra 4y ago
    It's common for tech companies to give RSUs which vest over 4 years with annual refreshers being comparatively quite small. The financial incentives can dwindle after just 4-6 years at a given job.
  - regularfry 4y ago
    The gotcha to that, of course, is that while you're enticing people to stay in the company, you're doing nothing necessarily to keep them on a single project within that company.
  - Gigachad 4y ago
    The developers have also gotten too greedy and most of them will job hop every year for the maximum income.
    - rjbwork 4y ago
      Sounds like if they can job hop every year for maximum income, then the companies they work for are being greedy by underpaying them.
      - Gigachad 4y ago
        Everyone is greedy, that's how markets work. Every employee is trying to maximize their income and every employer is trying to minimize their expenses. But somehow one of these is seen as "greed" while the other is not. As a software developer I get paid far above most workers and my job is easier than most other jobs. And yet I could still switch jobs frequently to squeeze out even more money.
turminal 4y ago
> Things like the linux kernel, all the GNU utils, emacs, vim, apache, nginx, postgres. The list goes on. We know how to write software that lasts for decades, continuously improves, and doesn't need constant re-writes. At least half of the items on that list are still here purely on momentum and reputation from the time there were no alternatives, not because they were really that marvelous. I use and even enjoy some of them, but they're far from great engineering.
- DoneWithAllThat 4y ago
  I would disagree with that sentiment for every single item on that list. All those tools are amazing and have improved steadily over decades and I would absolutely put them in the “great engineering” category.
  - throw10920 4y ago
    GNU utils are incredibly primitive and their text-driven APIs are fragile and cause tons of issues in shell scripting. I love Emacs, but it's a slow, crufty mess. Vim is a huge pile of code with a lot of complexity in its codebase and hilariously bad design decisions like VimScript. Apache is a mess from a security perspective (1.7k listed CVEs[1]), and still slower than Nginx. Want to guess at the amount of lost productivity due to Apache vulnerabilities? [1] https://www.cvedetails.com/vulnerability-list/vendor_id-45/Apache.html https://www.cvedetails.com/vulnerability-list/vendor_id-45/A...
    - froh 4y ago
      What would be counterexamples to that, i.e. great engineering? FOSS possibly?
      - nextos 4y ago
        seL4. Simple and formally verified. I think it's time to pour VC money on a fully verified stack. Perhaps not everything needs to be proven, integrity for some components can be ensured more informally with e.g. refinement types. Lots of governments and organizations need more robust software.
astrange 4y ago
I think nginx is a rewrite of apache, just as busybox is a rewrite of coreutils. Linux tends to rewrite itself but just keep the userspace ABI.
- donatj 4y ago
  > nginx is a rewrite of apache I mean not really. It does a tiny fraction of what Apache does, it just happens to do that specific fraction better.
  - astrange 4y ago
    That's disruption theory at work. https://en.wikipedia.org/wiki/Disruptive_innovation https://en.wikipedia.org/wiki/Disruptive_innovation
- yyyk2 4y ago
  Busybox is not a rewrite of coreutils, it serves a completely different purpose.
pablok2 4y ago
Allowing projects to fail is important too, it just happens that complexity plays a big role in these failures.
dale_glass 4y ago
Many of those did need something approaching a rewrite and even got one of sorts, but just were big enough that there was plenty that was unaffected by whatever big change was needed. The Linux kernel for instance gets big changes. The BKL took a very long time to fully remove. The GNU utils needing a rewrite would be weird since most of them implement a pre-existing standard, so the need for a huge rewrite is very unlikely.
bezospen15 4y ago
Odd I thought it was caused by every little piece of software being tied to giant product teams full of MBA majors that want to add 50 features a week
bigbillheck 4y ago
> emacs, ... don't put artificial corporate constraints The historical record disagrees. See for example RMS squashing better clang+emacs integration: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01877.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01...
- jacobsenscott 4y ago
  Weather you agree with this decision or not, it is consistent and clear. Something you generally won't get in corporate decision making. That is worth a lot. You know RMS isn't going to come back six months later and reverse it.
throwaway894345 4y ago
> It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly. Even if you have plenty of skilled engineers, it doesn't mean that the business won't impose unrealistic timelines (and insist the timelines be met even if it means taking on loads of tech debt which never gets paid down) or change the requirements abruptly or even demand things that are inherently complex (without understanding the complexity). In other words, there are plenty of ways that management can create complexity, and in my experience management-induced complexity is the most common kind (note that I'm faulting "management" for things that include "communication between engineers and management" because management ultimately owns the software development process).
- lytefm 4y ago
  Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.
  - miscaccount 4y ago
    Well probably you have never met management that is keyword drive. We need 100 percent scalable system with zero downtime upgrade and support thousand customers update. Current number of customers : 0 Number of customers in pipeline: 0
  - throwaway894345 4y ago
    Maybe. I've never worked in an organization where engineers were driving the complexity, nor have I worked in an organization where microservices introduced complexity (I've heard people complain in vague terms about microservices, but I don't relate to their experiences). However, I have worked in an organization that transitioned from monoliths to microservices, and the overall complexity was reduced because (I didn't mean for this to turn into a monolith/microservices thread, but oh well): 1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system 2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons) Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators). My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.
jinwoo68 4y ago
In the corporate world, "leaders" are incentivized by having more people in their orgs. It makes them have more "power". So they constantly broaden the scope and try to hire more people. The leaders in software orgs never benefit from finishing projects early with less engineers. Nor do they benefit from maintaining stable and robust software. Making the project take longer with more engineers with complicated architectures makes them gain more power. Yeah, this makes me sad.
theteapot 4y ago
> Look at software that has been around for decades, continues to improve, never "needs" a re-write, and will never be re-written. It exists and is not uncommon. Things like the linux kernel, all the GNU utils, emacs, vim, apache, nginx, postgres. They don't get re-written because they can't be re-written without tearing down everything built on top. In every case though there is some newer software out there is inspired by but aiming to "fix" all the short comings of the predecessor.
- Glavnokoman 4y ago
  Half of software you mentioned is just garbage inside. And it will never be rewritten simply because it happens to work good enough to discourage any serious investment in rewriting it.
likortera 4y ago
Best comment I've ever read on HN.
331c8c71 4y ago
Vim was rewritten after all (neovim) and not without a reason.
mike_hock 4y ago
Linux doesn't rewrite? Is writing a completely new I/O scheduler from scratch and replacing the old one not a rewrite? How much does a 5.14 kernel have in common with a 2.6.8 one? If anything, Linux isn't afraid to rewrite the parts that need to be rewritten, and that's one of its strengths. Apache, Vim, and Postgres have been "rewritten." Nginx is an httpd written from scratch that sort of has the same features as Apache. Neovim exists. And newer database technologies that care about performance have been written.
- jacobsenscott 4y ago
  With well designed software parts are re-written all the time. When people say rewrite they mean literally rewriting everything from scratch. Stating over. So if you diff 2.6.8..5.14 course you'll get a massive diff. But they got there by a long series of relatively small changes, with regular releases in between.
  - mike_hock 4y ago
    Nginx, Neovim and Linux 2.6 were written from scratch to start over from Apache, Vim and Linux 2.4. The rewrite isn't the issue. The tech debt amassed between the rewrites and then rewriting not to learn from past mistakes but to repeat them, is the issue.

sethetter 4y ago

I'm curious how big of a factor a consistent core team is to having long-term sustainable and stable software. When companies have people rotating on projects constantly and the original vision and design principles of the product are lost or changed, I can only imagine that contributes to the problem.

phendrenad2 4y ago
I think that's a big factor. This is what RSUs and bonuses are supposed to solve: You entice employees to stay rather than job hop. However, companies have gotten too greedy and RSUs amount to a pittance, a vestigial perfunctory play act mimicking a bygone era.
- amenghra 4y ago
  It's common for tech companies to give RSUs which vest over 4 years with annual refreshers being comparatively quite small. The financial incentives can dwindle after just 4-6 years at a given job.
- regularfry 4y ago
  The gotcha to that, of course, is that while you're enticing people to stay in the company, you're doing nothing necessarily to keep them on a single project within that company.
- Gigachad 4y ago
  The developers have also gotten too greedy and most of them will job hop every year for the maximum income.
  - rjbwork 4y ago
    Sounds like if they can job hop every year for maximum income, then the companies they work for are being greedy by underpaying them.
    - Gigachad 4y ago
      Everyone is greedy, that's how markets work. Every employee is trying to maximize their income and every employer is trying to minimize their expenses. But somehow one of these is seen as "greed" while the other is not. As a software developer I get paid far above most workers and my job is easier than most other jobs. And yet I could still switch jobs frequently to squeeze out even more money.

turminal 4y ago

> Things like the linux kernel, all the GNU utils, emacs, vim, apache, nginx, postgres. The list goes on. We know how to write software that lasts for decades, continuously improves, and doesn't need constant re-writes. At least half of the items on that list are still here purely on momentum and reputation from the time there were no alternatives, not because they were really that marvelous. I use and even enjoy some of them, but they're far from great engineering.

DoneWithAllThat 4y ago
I would disagree with that sentiment for every single item on that list. All those tools are amazing and have improved steadily over decades and I would absolutely put them in the “great engineering” category.
- throw10920 4y ago
  GNU utils are incredibly primitive and their text-driven APIs are fragile and cause tons of issues in shell scripting. I love Emacs, but it's a slow, crufty mess. Vim is a huge pile of code with a lot of complexity in its codebase and hilariously bad design decisions like VimScript. Apache is a mess from a security perspective (1.7k listed CVEs[1]), and still slower than Nginx. Want to guess at the amount of lost productivity due to Apache vulnerabilities? [1] https://www.cvedetails.com/vulnerability-list/vendor_id-45/Apache.html https://www.cvedetails.com/vulnerability-list/vendor_id-45/A...
  - froh 4y ago
    What would be counterexamples to that, i.e. great engineering? FOSS possibly?
    - nextos 4y ago
      seL4. Simple and formally verified. I think it's time to pour VC money on a fully verified stack. Perhaps not everything needs to be proven, integrity for some components can be ensured more informally with e.g. refinement types. Lots of governments and organizations need more robust software.

astrange 4y ago

I think nginx is a rewrite of apache, just as busybox is a rewrite of coreutils. Linux tends to rewrite itself but just keep the userspace ABI.

donatj 4y ago
> nginx is a rewrite of apache I mean not really. It does a tiny fraction of what Apache does, it just happens to do that specific fraction better.
- astrange 4y ago
  That's disruption theory at work. https://en.wikipedia.org/wiki/Disruptive_innovation https://en.wikipedia.org/wiki/Disruptive_innovation
yyyk2 4y ago
Busybox is not a rewrite of coreutils, it serves a completely different purpose.

pablok2 4y ago

Allowing projects to fail is important too, it just happens that complexity plays a big role in these failures.

dale_glass 4y ago

Many of those did need something approaching a rewrite and even got one of sorts, but just were big enough that there was plenty that was unaffected by whatever big change was needed. The Linux kernel for instance gets big changes. The BKL took a very long time to fully remove. The GNU utils needing a rewrite would be weird since most of them implement a pre-existing standard, so the need for a huge rewrite is very unlikely.

bezospen15 4y ago

Odd I thought it was caused by every little piece of software being tied to giant product teams full of MBA majors that want to add 50 features a week

bigbillheck 4y ago

> emacs, ... don't put artificial corporate constraints The historical record disagrees. See for example RMS squashing better clang+emacs integration: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01877.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01...

jacobsenscott 4y ago
Weather you agree with this decision or not, it is consistent and clear. Something you generally won't get in corporate decision making. That is worth a lot. You know RMS isn't going to come back six months later and reverse it.

throwaway894345 4y ago

> It mostly comes from businesses throwing a bunch of under-skilled labor at the problem, and demanding more and more too quickly. Even if you have plenty of skilled engineers, it doesn't mean that the business won't impose unrealistic timelines (and insist the timelines be met even if it means taking on loads of tech debt which never gets paid down) or change the requirements abruptly or even demand things that are inherently complex (without understanding the complexity). In other words, there are plenty of ways that management can create complexity, and in my experience management-induced complexity is the most common kind (note that I'm faulting "management" for things that include "communication between engineers and management" because management ultimately owns the software development process).

lytefm 4y ago
Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.
- miscaccount 4y ago
  Well probably you have never met management that is keyword drive. We need 100 percent scalable system with zero downtime upgrade and support thousand customers update. Current number of customers : 0 Number of customers in pipeline: 0
- throwaway894345 4y ago
  Maybe. I've never worked in an organization where engineers were driving the complexity, nor have I worked in an organization where microservices introduced complexity (I've heard people complain in vague terms about microservices, but I don't relate to their experiences). However, I have worked in an organization that transitioned from monoliths to microservices, and the overall complexity was reduced because (I didn't mean for this to turn into a monolith/microservices thread, but oh well): 1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system 2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons) Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators). My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.

jinwoo68 4y ago

In the corporate world, "leaders" are incentivized by having more people in their orgs. It makes them have more "power". So they constantly broaden the scope and try to hire more people. The leaders in software orgs never benefit from finishing projects early with less engineers. Nor do they benefit from maintaining stable and robust software. Making the project take longer with more engineers with complicated architectures makes them gain more power. Yeah, this makes me sad.

theteapot 4y ago

> Look at software that has been around for decades, continues to improve, never "needs" a re-write, and will never be re-written. It exists and is not uncommon. Things like the linux kernel, all the GNU utils, emacs, vim, apache, nginx, postgres. They don't get re-written because they can't be re-written without tearing down everything built on top. In every case though there is some newer software out there is inspired by but aiming to "fix" all the short comings of the predecessor.

Glavnokoman 4y ago
Half of software you mentioned is just garbage inside. And it will never be rewritten simply because it happens to work good enough to discourage any serious investment in rewriting it.

likortera 4y ago

Best comment I've ever read on HN.

331c8c71 4y ago

Vim was rewritten after all (neovim) and not without a reason.

mike_hock 4y ago

Linux doesn't rewrite? Is writing a completely new I/O scheduler from scratch and replacing the old one not a rewrite? How much does a 5.14 kernel have in common with a 2.6.8 one? If anything, Linux isn't afraid to rewrite the parts that need to be rewritten, and that's one of its strengths. Apache, Vim, and Postgres have been "rewritten." Nginx is an httpd written from scratch that sort of has the same features as Apache. Neovim exists. And newer database technologies that care about performance have been written.

jacobsenscott 4y ago
With well designed software parts are re-written all the time. When people say rewrite they mean literally rewriting everything from scratch. Stating over. So if you diff 2.6.8..5.14 course you'll get a massive diff. But they got there by a long series of relatively small changes, with regular releases in between.
- mike_hock 4y ago
  Nginx, Neovim and Linux 2.6 were written from scratch to start over from Apache, Vim and Linux 2.4. The rewrite isn't the issue. The tech debt amassed between the rewrites and then rewriting not to learn from past mistakes but to repeat them, is the issue.