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…
The collapse of complex software
131–140 of 304 posts
Re: The collapse of complex software
#132This "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.
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
#133That 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
#134The 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…
Re: The collapse of complex software
#136I 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…
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
#137Re: The collapse of complex software
#138Earlier 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.
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
#139Earlier 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.
Re: The collapse of complex software
#140This "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…
The historical record disagrees. See for example RMS squashing better clang+emacs integration: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01...