Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The collapse of complex software

nolanlawson.com

Post reply on HN
Print view View original

241–250 of 304 posts

Re: The collapse of complex software

#241

Post by d--b »

Where I work, we kind of organically setup two different teams: the ones who move ahead, go fast and make new stuff, and the ones who stay behind slowly cleaning the mess the first ones did years ago.

Ideally you rotate people between the two teams. And you adjust the number of people when the ones ahead create too much to clean up.

The problem with complexity is that it doesn’t come out of nowhere, it mostly comes from changing requirements. So it inevitably is always cheaper to hack a system to do something it was almost meant to do than to figure out where in the original design things need to change for the new stuff to be supported.

Re: The collapse of complex software

#242

Post by seer »

daenz wrote: post #11

This is a problem I want to focus my life solving. I believe that software engineering can be made so simple and clear that it can be wielded by an extremely small team of engineers. I believe that there are finite and fundamental classes of problems, that underpin the vast majority of problems, that have a distinct visual representation, and that by representing these problems visually, you let your "visual coproces…

I definitely share this belief. When I started delving into functional programming I was immediately struck by how whole classes of problems just disappeared once people found some useful abstractions. Programmes that took thousands of lines of code to express could be written in hundreds or even tens.

But FP seems a bit stuck nowadays (to my untrained eye) with the breakthroughs from the greybeards of the last decade.

Do you have any progress thus far? Anything people can contribute to?

Re: The collapse of complex software

#243

Post by jsiaajdsdaa »

davidgay wrote: post #59
daenz wrote: post #11

This is a problem I want to focus my life solving. I believe that software engineering can be made so simple and clear that it can be wielded by an extremely small team of engineers. I believe that there are finite and fundamental classes of problems, that underpin the vast majority of problems, that have a distinct visual representation, and that by representing these problems visually, you let your "visual coproces…

> I believe that software engineering can be made so simple and clear that it can be wielded by an extremely small team of engineers. Not that I want to discourage you, but my view is that anything that makes software engineering simpler just leads us to tackling more complex problems until the complexity reaches the limit that people can handle. So in that view, you can't succeed at making software engineering alway…

Well no to be honest Spring Boot/Java really does make managing threads and web requests easier than doing it manually.

Similarly using an operating system/assembly is much easier than trying to control pulses of electricity yourself!

Re: The collapse of complex software

#244

Post by guiriduro »

daenz wrote: post #11

This is a problem I want to focus my life solving. I believe that software engineering can be made so simple and clear that it can be wielded by an extremely small team of engineers. I believe that there are finite and fundamental classes of problems, that underpin the vast majority of problems, that have a distinct visual representation, and that by representing these problems visually, you let your "visual coproces…

Congratulations, you just (re-)invented UML. Or perhaps the "no no, its not UML" semantically anemic C4 thing with lots of blue squares.

Re: The collapse of complex software

#245

Post by froh »

froh wrote: post #162
throw10920 wrote: post #138

Earlier quoted context omitted.

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

What would be counterexamples to that, i.e. great engineering? FOSS possibly?

Fossy and SQLite are engineering marvels.

Re: The collapse of complex software

#246

Post by popcorncowboy »

Forge36 wrote: post #103
popcorncowboy wrote: post #9

tl;dr premise = society is complex, software is complex; complex societies collapse... therefore complex software collapses, question mark, waggling eyebrows, surely makes you think etc etc. > ...Opinions expressed in this blog are mine *and frequently wrong*. Emphasis added. Equating the complexities of software with the complexities of societies (the premise of this post) is a fun and provactive blog post. Which is…

OS/360? https://sudonull.com/post/111636-IBM-System-360-A-Failing-St... I think we've seen this with the rise and fall of hardware vendors. Most recently with the Mobile OS ecosystem (symbian, windows mobile)

My issue lies with software engineers making associations that society is like software.

The causal factors behind why societies fail and why software projects fail are completely different. Complexity is a description of the system and a very bad measure to draw an equivalence between the two.

The risk with drawing this equivalence is it grants license to software engineers to think that similar enough models apply to "managing software" as "managing societies". Because when all you have is a hammer... But society is not a nail.

Re: The collapse of complex software

#247

Post by danielovichdk »

wtetzner wrote: post #168
0xFACEFEED wrote: post #136

Earlier quoted context omitted.

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

I think you and the parent are talking about two different things. Building products that are looking to the future is valuable, if risky. But I believe the parent comment was talking about software abstractions. i.e., don't build abstractions because you might need them later. Instead, build the software in the simplest possible way to solve the problems it needs to handle now. This is because you'll likely be wrong…

This. Thank you for clarifying

Re: The collapse of complex software

#248

Post by psychoslave »

"Can we do without?" is to my mind the single most precious question from an engineering point of view.

“It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.” Antoine de Saint Exupéry

Re: The collapse of complex software

#249

Post by danielovichdk »

0xFACEFEED wrote: post #196
wtetzner wrote: post #168

Earlier quoted context omitted.

I think you and the parent are talking about two different things. Building products that are looking to the future is valuable, if risky. But I believe the parent comment was talking about software abstractions. i.e., don't build abstractions because you might need them later. Instead, build the software in the simplest possible way to solve the problems it needs to handle now. This is because you'll likely be wrong…

We're talking about the same thing. Perhaps I was just speaking more broadly. > don't build abstractions because you might need them later ... [snip] ... This is because you'll likely be wrong about your assumptions about which abstractions you'll need, and ripping those abstractions out is going to be more expensive than just modifying simple code to do new things. At worst, this is dangerously wrong. At best, it cr…

I totally agree on validating ideas but that's IMO not looking in to the future. It's trying to find a fit for something you believe is a good idea. There is a big difference in testing whether something is needed in the near future or you simply stick to your guns and blindly dictate how you believe the future will look like.

Your ORM example is good and exactly what i am referring to. Too much abstraction/gold plating due to unknown requirements in the future is perhaps a better way to put what is a problem.

And you also say that "If you're designing new systems that need to scale quickly..." - if you know that it will scale quickly then of course you know you need to do certain implementations to cater that. But if you do not know whether it will scale quickly then you are looking into an unknown future - and then you should step back on abstractions.

Post reply on HN