Live data from Hacker News

The collapse of complex software

nolanlawson.com

131–140 of 304 posts

Re: The collapse of complex software

#131

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 s…

> 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 som…

Also, most of them have gotten a rewrite worth of upgrades during their life. The Linux kernel is a good example: most of the code you use today didn't exist in the kernel 15 years ago. A lot of code from back then still exists for compatibility purposes, but is rarely used in modern systems.

Re: The collapse of complex software

#132

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 s…

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.

> 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.

Re: The collapse of complex software

#133
> A software company with more modest aims, that has a stable customer base and doesn’t change much over time (does such a thing exist?) will be more like the humble tribe that follows the yearly migration of the antelope and focuses on sustainable, tried-and-true techniques. (Whether such companies will end up like the hapless Gauls, overrun by Caesar and his armies, is another question.)

That last part is the key: with the strong preference for short term gains in an economic system where finances are considered and reconsidered quarterly, sustainability is an afterthought. "Growth at all costs" aligns with the dominant ideology of imperialism, and it's just as prevalent in corporations and organizations as it is in nation states. Literal millennia of evidence for that approach out-competing others is hard to beat, and I think if we knew how to survive a different way even at the micro level we'd probably live in a much better society.

Re: The collapse of complex software

#134
Business assets depreciate over time, nearly all of them, it’s only the amalgam that can steadily appreciate, as assets are cycled in and out. Business is fine with that.

The problem with software is that software deprecation cannot be readily modeled in Excel. We’re back to the problem of quantifying Engineering Debt.

The best I can come up with number of WTF moments per unit of cyclomatic complexity. The second best is aggregate cortisol level of developers divided by the business value produced during a release.

Re: The collapse of complex software

#135

> Simplicity of design sounds great in theory, but it might not win you many plaudits from your peers. A complex design means more teams to manage more parts of the system, more for the engineers to do, more meetings and planning sessions, maybe some more patents to file. A simple design might make it seem like you’re not really doing your job. “That’s it? We’re done? We can clock out?” And when promotion season come…

Haha, this makes me want to work at your company.

Re: The collapse of complex software

#136

I will tell you this. It's based on my 20+ years, 50 different teams and many hundreds, perhaps thousands of encounters with software developers. It's almost never the domain complexity that is high. Sending a rocket to Mars is complex. And perhaps complex every time. Dealing with people that has to work together can only be simplified when agreements are made and agreements are kept. Otherwise you cannot trust and h…

> Don't look into the future. Because you cannot. And you are both naive and arrogant if you believe you can. Deal with what is known now!

NO!

This mentality is short sighted by definition and leads to stagnation. It may work within large financially healthy companies that aren't trying to rock to the boat.

Making assumptions about the future is incredibly important for us to move forward. But with these caveats:

1) Acknowledge that you are taking a risk and that you may be wrong.

2) Validate your assumptions as quickly and as often as you can.

3) Be prepared to change course whenever your assumptions are invalidated.

> Less experienced people are generally guided by their beliefs around their own ideas. If the mind is locked onto something it's hard not to thing it's a good idea. Usually in software there is simpler approach.

Less experienced people are frequently the driving force behind new ideas precisely because of their belief in it. As experienced people we should be encouraging them to carry forward responsibly instead of projecting our aged and jaded perspectives.

> I can go on because I help companies and teams for a living.

Honestly, that's a weird way to phrase what you do.

Re: The collapse of complex software

#138

Earlier quoted context omitted.

> 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 som…

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.

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/A...

Re: The collapse of complex software

#139
post #132

Earlier quoted context omitted.

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.

> 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.

That's disruption theory at work.

https://en.wikipedia.org/wiki/Disruptive_innovation

Re: The collapse of complex software

#140

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 s…

> 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/msg01...

Post reply on HN