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

221–230 of 304 posts

Re: The collapse of complex software

#221

Post by qwertyzxcvmnbv »

daenz wrote: post #68
davidgay wrote: post #59

Earlier quoted context omitted.

> 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: th…

I think Tudor Girba has a similar vision. E.g. check out https://gtoolkit.com/ and his talks on software environmentalism, such as https://m.youtube.com/watch?v=N3l3eB62oSw

Re: The collapse of complex software

#222

Post by fragmede »

yellowapple wrote: post #130
perlgeek wrote: post #37

Earlier quoted context omitted.

I want to believe you, but there are just so many complicated problems IN REALITY that we have to model in software that I don't really see complexity going down. Just an example: around here, most people have a first (given) and a last (family) name. If I don't model that as separate, I have trouble interfacing with other software. If I do, I have trouble with people from other cultures that don't follow that conven…

> What's the "right" way to store person names? Store both a unified name field and separated given name / surname fields and let the user manage both. Yeah, this risks going out of sync, but that's the user's problem, not yours. Yeah, three fields are technically more complex than one or two, but it produces less complexity down the line.

So what happens when someone doesn’t have a surname?

Falsehoods programmers believe about name: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Re: The collapse of complex software

#223

Post by tesseract »

a1369209993 wrote: post #185
fmakunbound wrote: post #177

Earlier quoted context omitted.

Works for email, phone numbers and addresses, too.

Actually, it doesn't. All of those are, well, addresses , and have some mechanical structure necessary for routing (admittedly, for phone numbers, the structure amounts to "any sequence of 0-9, #, *, and possibly those four wierd extra symbols with the fourth DTMF column tone"). You probably don't (or least shouldn't) care about that structure as long as it routes correctly, but it does exist. (Ie, you'd still use a…

I think the point is that someone else cares about the structure and sets its rules - which may change without warning or have complexity you are unaware of - and therefore if you are not the telephone company or the post office you are likely overstepping if you try to enforce structure rather than merely passing along what you were given.

Re: The collapse of complex software

#224

Post by Ericson2314 »

While there is much good work to be done on making simple shorter code more expressive there is also tones of low hanging fruit.

These

https://en.wikipedia.org/wiki/Law_of_Demeter https://en.wikipedia.org/wiki/Principle_of_least_privilege

We just need to do this again and again and again.

For example, we all know there should be / and everything should be done via file descriptors by now. Great, but who is making it happen?!?

Re: The collapse of complex software

#225

Post by kirubakaran »

appleflaxen wrote: post #97
loudmax wrote: post #28

I highly recommend Rich Hickey's "Simple Made Easy" talk as a way to think about software complexity. We all know that complex systems are hard to work with, but I've found his presentation very useful in understanding the nature of complexity. Understanding complexity helps being able to avoid or minimize it. For example, easy is not the same as simple, and simple changes to one part of a system can introduce great…

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 :/

The solution to losing weight is simple: eat fewer calories than you burn. It's not easy though.

Re: The collapse of complex software

#226

Post by shkkmo »

pphysch wrote: post #72
perlgeek wrote: post #37

Earlier quoted context omitted.

I want to believe you, but there are just so many complicated problems IN REALITY that we have to model in software that I don't really see complexity going down. Just an example: around here, most people have a first (given) and a last (family) name. If I don't model that as separate, I have trouble interfacing with other software. If I do, I have trouble with people from other cultures that don't follow that conven…

> Names Don't try to force schemas onto schema-less data. Store the "name" as a JSON string/blob representing the various possible attributes (given, middle, family, title, etc) and provide a variety of functions for representing that data. IF you really need to do this at all (for an internal app, you probably don't). > Physical links Include an Hardware Asset FK in your Link M2M table. Model each binary link explic…

Your solution assumes atleast a dozen incorrect things from the classic https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Re: The collapse of complex software

#227

Post by brandall10 »

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…

Sounds like the work of Bret Victor.

Re: The collapse of complex software

#228

Post by bluedino »

vlovich123 wrote: post #212
ItsMonkk wrote: post #88

Earlier quoted context omitted.

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

This seems like a fantasy considering how big the development teams for these projects are. Multics did not have thousands of developers. Linus was just more practical about software development, was maybe better at building a community, and more importantly focused on x86 commodity HW which was a bet that only Microsoft also happened to make.

It was also already built. The clone is easier to make

Re: The collapse of complex software

#229

Post by jareds »

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…

Although it may have only taken a week to create the initial version of Git the amount of polish and documentation required to get it to something someone like me who's not a kernel developer was a lot more than a week's worth of work. You may be able to get 80% of the functionality in 20% of the time but it's that last 20% of functionality that gives software enough polish to actually be used by someone who doesn't have an incredibly specific reason to figure out how to use the unpolished software.

Re: The collapse of complex software

#230

Post by edmcnulty101 »

daenz wrote: post #68
davidgay wrote: post #59

Earlier quoted context omitted.

> 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: th…

This is a very cool comment. I agree with you. We've made operating systems extremely simple from a UI standpoint then we host web frameworks on top of those operating systems. And then we make clusters on top of those frameworks and then we make datacenters out of cluster, etc.

All still manageable by humans but at continually higher and higher levels of complexity.

Post reply on HN