Live data from Hacker News

Simple Software Manifesto

arewesimpleyet.org

61–70 of 90 posts

Re: Simple Software Manifesto

#61
post #9

Every new generation of programmers starts a crusade to simplify without first trying to understand why we're not "simple" despite the previous generation having done the same. Of course, one possible explanation could be that without a constant crusade for simplicity we'd be in a far worse place; the "permanent revolution" explanation. But is this the right explanation? Turing Award winning computer scientist Fred B…

There is also very much accidental complexity in software. Mainly the plethora of OSes, programming languages, build systems, package managers and what not. For maximum simplicity there should exist only one of the things I mentioned in the previous sentence. Whenever one runs into one of these things and one happens to not be very familiar with it, one is in big trouble, and not the kind of trouble that, at least I, enjoy. Also, for simplicity there should not be the difference between software that runs on local machines and software that runs on the web.

The reason this plethora exists may well the be crusade that you mention. Instead of solving the problems with the current programming language, let us just invent a new one instead. The former thing is much harder to pull of, of course but should limit the amount of complexity in the long run.

Re: Simple Software Manifesto

#62
post #60
post #48

Earlier quoted context omitted.

I've yet to watch Kay's talk, but I take issue with the fundamental claim that rules necessarily lead to "simplicity". If there is one thing computer science tells us is that this is not the case. For example, orbit equations are very simple, yet if you put more than 2 objects in gravitational interaction, their behavior is completely unpredictable (and very complex) even though the rules that govern it are simple. I…

If you don't like videos, you can also look up his papers from STEPS circa 2010. I think the 3 body problem is indicative of what Kay says. One simple rule produces very rich behavior. Why not have something like that for your network stack?

> Why not have something like that for your network stack?

In a way, it is like that already. After all, all computation can be described as a repeated application of, say, the very simple reduction rules of the lambda calculus. How does that help? Does the fact we know what the gravity equation help us predict the system's behavior (e.g. to ensure that some bad state is never reached)?

Re: Simple Software Manifesto

#63

Ugh, I don't share this sentiment. Each new generation of programmers creates new tools to replace the 'complex' ones that came before without even bothering to understand them. In my 25 year career I've seen it multiple times. We are all going downhill. Attention spans in the smartphone era might be preventing people from reading the f*ing manual. This means that any system or library which has an operating model th…

And no one even writes the manual anymore. Software project documentation is a disaster.

Re: Simple Software Manifesto

#64
> Constraining the user to simple tools encourages creativity and allows the system to be more quickly understood. This supports the removal of complicated features.

Oh god, no. This horrible idea escalated so far that there is now a billion dollar industry (RPA) automating braindead tasks just because software can not be arsed any more to include API, code/CLI based access or, to steal the wording, complex tools at all.

IMO this is another round of weirdly religious adherence to "UX" schemes which ends in massive damage, like the unconditional love for whitespace everywhere.

Please stop using "simplicity" as a cop out to prevent having to build software that, for example, has basic things like stack deletion. The result will just suck.

Re: Simple Software Manifesto

#65

Earlier quoted context omitted.

> If there is one correct way, then software writers are fungible I don't believe that follows. For example, there is one 'correct way' to unscramble a rubiks cube, but humans unscramble them in a much more roundabout manner. Just because there is one correct way to do it doesn't imply that all rubiks cube solvers are fungible. This is because of the very high cognitive load of finding the correct way. Math, especial…

> For example, there is one 'correct way' to unscramble a rubiks cube Thats not true from a mechanical standpoint. From start, rotate an edge 180degrees. Now you can turn it right 180 or left 180. Making 2 coins show the same face (when they differ) doesnt have one correct algorithm, in the same vein. Developers necessarily interact with apis at this level and generalize from these choices.

The integrity of my rubik's cube analogy isn't critical to my argument, but...

Even allowing for equivalent rotations as you mention, the method humans use to unscramble a rubik's cube is far far from optimal because we can't grok a scrambled rubik's cube then just execute the optimal solution.

Also this is just pedantry because WLOG you could just name those equivalent 180 rotations as a single operation anyway.

Re: Simple Software Manifesto

#66

> There is only one correct way to do something .... so take great care in doing it right the first time. I hear this a lot, in various contexts, and I even used say it a lot. But this has actually stopped making sense for me. I don’t think I’ve ever genuinely seen a case where there is only one obvious way to do something, or that there’s a way that is obviously the “right” way. Everything non-trivial is chock full…

The thinking that there is only one correct way is very damaging. In reality there are almost several ways to do something. And each of these ways can be successful if done well or be a disaster if done wrong. So instead of constantly adjusting to reality (which is what Agile should be) we spend a lot of time on ideological discussions and less time on action.

Re: Simple Software Manifesto

#67
post #50
post #25

Earlier quoted context omitted.

I think that all else being equal, simplicity is to be preferred over complexity. You're pointing out that all else is never equal; ok, cool; but it's hard to imagine anyone finding value in deliberately complicating things. Simplicity seems to be an inherently valuable trait in system design/maintenance. Can you oversimplify? Sure. Does that justify not striving to reduce to the simplest functionally complete, scala…

My points are: 1. Even software with no "accidental" complexity is necessarily complex (in fact, that's why it's useful). 2. If the manifesto's point is that we should stop over -complicating things, then wouldn't it better to first examine whether, and if so why, things are overcomplicated now, given that the previous generation also went on a crusade to abolish (over)complication? If the point is to declare "don't…

Yep, now that we have lots of version controls histories publically available there is no excuse for this.

Re: Simple Software Manifesto

#68
> Simple software manifesto

Excellent!

> There is only one correct way to do something

!!! The correct way to do something depends on what else you're doing at the same time.

> Simple software in practice > C

Dear God

Re: Simple Software Manifesto

#69
I suggest the biggest problem we have in the industry is a laziness towards engineering and an unwillingness by business to accept the law of fast, good and cheap.

Very few organizations use real data and the scientific method to make decisions on architectures and design. Most rely on anecdotes, gut feel, politics and software cults to make these decisions.

Consequently, there's rarely real proof on the advantages of one approach over another. The rigor, and thus cost, needed to make those determinations is perceived to be too great but the reality is, those perceptions are often unfounded when considering the total cost of software.

This all hit me years ago when working for company that had to go through CMMI certification. As part of the effort, a consultant would come out quarterly to coach us along and monitor our progress. During that time period I noticed a significant portion of my time was now spent on the implementation of the process. When the consultant was out for a visit I told him I had concerns because we did not have a charge number for the extra time it was taking to implement the process. He asked why that would be necessary and I asked, how else could you make an objective determination on the benefit/cost ratio of implementing the process being greater than one. Disappointingly, the blank stare ensued.

Re: Simple Software Manifesto

#70
post #9

Every new generation of programmers starts a crusade to simplify without first trying to understand why we're not "simple" despite the previous generation having done the same. Of course, one possible explanation could be that without a constant crusade for simplicity we'd be in a far worse place; the "permanent revolution" explanation. But is this the right explanation? Turing Award winning computer scientist Fred B…

Yeah what you said.

There probably are exceptions. Software can sometimes be complex for no good reason except maybe its architects didn’t have a good plan and folks just added more bad code on top of existing bad code. I’m just not sure if that’s as common as the crusaders want it to be, and when folks say they want to simplify, I think that most of the time it’s because they don’t understand what they’re getting themselves into.

Post reply on HN