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

61–70 of 304 posts

Re: The collapse of complex software

#61

Post by nightski »

notriddle wrote: post #58
nightski wrote: post #42

Earlier quoted context omitted.

As you implied, I don't think the answer is to make the perfect abstractions that can handle any scenario. But where software does fail in my humble opinion is making it easy to pull in tried and true tested solutions to the problems that we do face, even if they are not as common. Because even though they may not seem common, I'm absolutely certain many face the same scenario. The amount of duplication solving the s…

> Back in the day in Haskell I dreamed of a system where you could type out a type signature and a fully tested rated implementation would be imported from an "open source" service. The type signature of GPT-3 is `string -> string`

Well I'd argue it's more Model => String => String if you are talking about using a fully pre-trained model. Even then you could probably expand on the type signature of the model to make it more useful.

But if you look at like co-pilot for example, if that was given the ability to have type signatures serve as input you might get a lot more powerful results than what it does with raw text (which is very impressive).

But this comes down to type signature design. You can encode any function using simple types like int -> int which aren't very useful. Where Haskell shines is when using types to limit the scope of inputs & outputs. What I am getting at is that you can still write uninformative type signatures in Haskell, but it also gives you the power to write more informative ones.

I don't think Haskell is the answer, so please don't take that as what I am saying. I do think however using richer type systems could be a stepping stone towards a solution to this problem.

Re: The collapse of complex software

#62

Post by bitwize »

chasd00 wrote: post #43
bitwize wrote: post #18

> One thing working in complexity’s favor, though, is that engineers like complexity. Admit it: as much as we complain about other people’s complexity, we love our own. We love sitting around and dreaming up new architectural diagrams that can comfortably sit inside our own heads Where does this yutz work? Because he doesn't speak for me. Generally, I write a complex program because I don't have time to write a simpl…

didn't Mark Twain say something like "i'm sorry this letter is so long, i didn't have time to write a shorter one". I feel like that with some of my code at times.

I believe it was Blaise Pascal, to whose missive I was making a deliberate reference.

Re: The collapse of complex software

#63

Post by danielovichdk »

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 have faith in people.

It comes down to far and near organization leadership, mandate and empowerment in small teams with few communication links outwards, clear expectations from whomever is asking for something and process management.

Writing code is rarely hard if you know the expectations and the boundaries of the task.

Empowerment gives the team the possibility to act on what they discover and encounter.

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!

One thing is complexity in code. Another is complexity in business. Some things are not made for software to solve.

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. Look for it

I can go on because I help companies and teams for a living. But I will stop here

Re: The collapse of complex software

#64

Post by gtowey »

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.

I think one thing missing from this line of thinking is that these are people. They have their own motivations and egos. They get sick, have families, take vacations, quit.

I think part of the way large teams and large companies are structured is a hedge against changing teams with highly variable capacity. It's hard to overstate how much it can hurt a project to lose a someone who has a ton of experience locked up inside their head.

The alternative is that I have worked for places that try to treat thier engineers like fungible tokens that can be shuffled and replaced at will. That environment feels extremely dehumanizing and demotivating.

Re: The collapse of complex software

#65

Post by an9n »

I seem to be in drastic opposition in that I hate complexity, and will do anything to avoid it. I shudder with horror when I look at the teetering stacks all over the place these days.

Re: The collapse of complex software

#67

Post by randomsearch »

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 agree with you. I have other things to do, but good luck to you.

There’s an awful lot of cultural baggage in coding. Many of the concepts that seem essential - powerful text editors, devils tooling - can be completely removed. It requires rethinking from first principles and being willing to upset the Apple cart, but I believe it is possible.

Re: The collapse of complex software

#68

Post by daenz »

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…

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: they let you organize complexity into well-defined areas and put a pin in them, easing the cognitive load. Then you can handle those abstractions more easily. But yes, to your point, because frameworks typically only tackle a few levels of complexity, you still get that complexity back when you use the framework to advance the problems to the edge of what your framework is designed to address.

A recursive/fractal management of complexity will allow all levels of the hierarchy to feel similar, so you are never increasing complexity, only looking at a different resolution. I think the key to this is mapping out the fundamental organizational problems and how they relate to each other at different resolutions.

Re: The collapse of complex software

#69

Post by jv22222 »

> It takes a lot of discipline to resist complexity, to say “no” to new boxes and arrows.

If we refactor a very large function into smaller sub functions we are essentially adding new boxes... but are we creating complexity, or simplicity?

Re: The collapse of complex software

#70

Post by strix_varius »

chrisweekly wrote: post #53
WaxProlix wrote: post #10

Earlier quoted context omitted.

If anything were going to do it, it'd be the labor crunch that we're seeing here. Without a constant influx of fresh-faced college coal lumps to burn in the tech debt engines Amazon would have a harder time of it. They've done a good job of pivoting though, and I think they'll weather the storm here (and be better off for it). See the increased comp to boost hiring rates - especially of non college hires - and an int…

> "constant influx of fresh-faced college coal lumps to burn in the tech debt engines" made me literally LOL. That turn of phrase is gold.

Or even diamond, with enough pressure!
Post reply on HN