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

201–210 of 304 posts

Re: The collapse of complex software

#201

Post by vinyl7 »

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…

> A well designed abstraction could save you weeks (even months!) of time when you most need it.

Or it could cost you a lot if your guesses are wrong. It goes both ways.

It's better to write code the simplest way to do what it needs to do now, but in a way that can be pulled out into a new system/abstraction later in an easy way. This is generally done by writing data-oriented code (focus on what the data is and how it needs to be transformed) rather than object-oriented code.

Re: The collapse of complex software

#202

Post by pjscott »

ItsMonkk wrote: post #88
daenz wrote: post #68

Earlier quoted context omitted.

If history is a guide, then you are correct. But I believe complexity is fractal (I think we all know this: "turtles all the way down..."), and that you can structure and manage complexity with recursive rules, so that you only see the resolution that you care about, for the areas that you care about, and everything else is a low frequency representation. Frameworks approximately do this, but for specific domains: th…

> tackling more complex problems This is the 'induced demand' argument. As perfection seems impossible, and mistakes inevitable, this seems likely. However, the more I look into issues, the more I realize that a very small number of errors introduced early on is what ultimately causes a plethora of them. Just fixing a very small amount of these mistakes would have untold effects on computing over the long-term. That…

> As teams get bigger, communication sales factorially,

That sounds a bit drastic. Surely at worst the scaling is quadratic?

Re: The collapse of complex software

#203

Post by dstroot »

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…

Software complexity in most cases is a direct reflection of business complexity. Changing requirements, overly complex processes, “approval” steps, etc., etc. if you can build it faster and cheaper - great! But you will end up in the same place eventually.

Re: The collapse of complex software

#204

Post by eschneider »

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…

Nothing on the language side fixes the problem of people just not knowing/understanding the project requirements.

Re: The collapse of complex software

#205

Post by msmenardi »

wvenable wrote: post #77
rileyphone wrote: post #20

Earlier quoted context omitted.

Me too, and I definitely agree that it is time to move past thinking in "languages" to a more holistic view of programming systems. The fact that as of now, only ~1% of people can access programming and wield the magic of the computer is a tragedy akin to the comparable levels of literacy in the medieval era. At the present, there seems to be a minor renaissance of thought along these lines stemming back to the pione…

> The fact that as of now, only ~1% of people can access programming and wield the magic of the computer is a tragedy akin to the comparable levels of literacy in the medieval era. I don't know why programmers think this way. We don't expect everyone to be a doctor, a botanist, a novelist, or a musician but for some reason we think anyone can be a programmer. That's just not the case -- programming is a skill like an…

I think they're saying we should make the tools to program more accessible and allow people to play music easier. Sorta like an electric keyboard vs a grand piano.

Re: The collapse of complex software

#206

Post by honkler »

aidenn0 wrote: post #104
appleflaxen wrote: post #97

Earlier quoted context omitted.

I've watched that video at least three times, but I still can't articulate the exact distinction he is making between simple and easy :/

Add two 10000 digit numbers by hand. That's quite simple to do, but it's certainly not easy.

it's easy but mundane. If you pay me, I'll do it.

Re: The collapse of complex software

#207

Post by collaborative »

Some systems, such as mainframes, resist being crossed with a big X for a long time. Their simplicity (raw tcp bytes that no REST API or HTTP website can outperform) and the big name (IBM) make it extremely resilient. Users' AHTs can't afford an extra 500ms between screens/pages. Users simply will refuse using any other system

Re: The collapse of complex software

#208

Post by yourapostasy »

lr1970 wrote: post #197
daenz wrote: post #68

Earlier quoted context omitted.

If history is a guide, then you are correct. But I believe complexity is fractal (I think we all know this: "turtles all the way down..."), and that you can structure and manage complexity with recursive rules, so that you only see the resolution that you care about, for the areas that you care about, and everything else is a low frequency representation. Frameworks approximately do this, but for specific domains: th…

> If history is a guide, then you are correct. But I believe complexity is fractal Actually, "combinatorial" or "exponential" would be better words to describe complexity explosion. The number of possible cases/scenarios/logic flows/etc grows exponentially as a system's complexity increases. It is a curse and a blessing at the same time keeping so many SWEs gainfully employed.

"Fractal" is used to describe the property of not resolving the complexity detail until you get up close ("zoom into" the complexity). The amount of use cases does expand alarmingly, but even combinatorial and exponential use cases imply they are inventoried and are thus amenable to prioritization.

In a lot of human work (not just software, but any endeavor involving technology even as "simple" as building a tunnel or simply involving many people coordinating together), complexity emerges this "unknown unknowns" property. This has happened since time immemorial. If you don't believe me, go master how to live out a subsistence life in an agrarian area of $nation during the 1500's with their tools but modern knowledge, then try to convince yourself complexity did not exist back then.

Re: The collapse of complex software

#209

Post by wvenable »

msmenardi wrote: post #205
wvenable wrote: post #77

Earlier quoted context omitted.

> The fact that as of now, only ~1% of people can access programming and wield the magic of the computer is a tragedy akin to the comparable levels of literacy in the medieval era. I don't know why programmers think this way. We don't expect everyone to be a doctor, a botanist, a novelist, or a musician but for some reason we think anyone can be a programmer. That's just not the case -- programming is a skill like an…

I think they're saying we should make the tools to program more accessible and allow people to play music easier. Sorta like an electric keyboard vs a grand piano.

We already have those tools for just about every age range. But like with music, just because you can play twinkle twinkle little star doesn't mean you're going to be able to join the orchestra. And if you do, you're going to need to able to play that grand piano.

Re: The collapse of complex software

#210

Post by 0xFACEFEED »

vinyl7 wrote: post #201
0xFACEFEED wrote: post #196

Earlier quoted context omitted.

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…

> A well designed abstraction could save you weeks (even months!) of time when you most need it. Or it could cost you a lot if your guesses are wrong. It goes both ways. It's better to write code the simplest way to do what it needs to do now, but in a way that can be pulled out into a new system/abstraction later in an easy way. This is generally done by writing data-oriented code (focus on what the data is and how…

The problem is that everyone's definition of "simple" and "in a way that can be pulled out" is different. And in any case... just about everything you write is an abstraction to some degree; the question is, where is the line?

It's not hard to write abstractions defensively. For example you can limit access to your abstraction to a small and strict interface. What you do behind that interface can be the wild west; as long as you can just lop it off later.

> It goes both ways.

It does, but the word "simple" is often used in a deceptive way. A cacophony of "simple" systems are actually very complex in aggregate.

There are many cases (eg: something is your core business) where you'd want to put a lot of thought into an abstraction ahead of time. You'd then want to validate that abstraction's effectiveness and adjust as you go.

Post reply on HN