Comment by Sharlin | Hacker News Reader

Comment by Sharlin | Hacker News Reader

Parent Full thread

When talking about software complexity I'm always reminded of the old quote by German general Kurt von Hammerstein-Equord but attributed to various military leaders:

  I divide my officers into four groups. There are clever, diligent,
  stupid, and lazy officers. Usually two characteristics are combined. Some 
  are clever and diligent – their place is the General Staff. The next lot
  are stupid and lazy – they make up 90 percent of every army and are 
  suited to routine duties. Anyone who is both clever and lazy is qualified 
  for the highest leadership duties, because he possesses the intellectual 
  clarity and the composure necessary for difficult decisions. One must 
  beware of anyone who is stupid and diligent – he must not be entrusted 
  with any responsibility because he will always cause only mischief.

Clever and diligent developers devise complex solutions to complex problems, which may often be good enough.

Stupid and lazy developers can be entrusted to come up with simple solutions to simple problems.

Clever and lazy developers are able to find simple solutions to complex problems, a very desirable trait.

But stupid and diligent developers, given the chance, manage to implement complex solutions to simple problems!

I confess I also fear the clever and diligent when the are put in a situation which rewards complexity. The role of architect, for example.

At large companies the output of architects is generally things like directives, white papers, and other agglomerations of words. They are expected to be smart. Can non-technical executives judge the actual smartness of the work? Not really. So architects often get judged by sounding smart. Confidence. Complexity. Negative judgment. Performing intellectual toughness.

That's the opposite of what I really want in a technical leader, whose job is generally best done with humility and subtlety. The best technical leaders I've worked with are quiet and make a lot of small interventions that add up to big long-term results. But that's rarely what executives are impressed by.

But laziness is only good if its long term laziness. E.g. a clever lazy person that job hops a lot and/or only do greenfield dev tends to leave huge messes for maintenance programmers to untangle.

At least, in my experience.

This implies that complexity is something that is only arrived at by putting in more "work", while a lazy person, that puts in less effort, comes up with a simpler solution. I disagree. Simplicity is extremely hard; much much harder than complexity. Simplicity takes many hours of design and redesign, to realize which parts are out of the scope of the problem domain and which parts are not.

In my mind, as a trait, it's about how a person thinks rather than how they necessarily act.

A diligent person may be someone where creating more work isn't a blocker to an acceptable solution, whereas a lazy person has reduction of work as a requirement for theirs.

So a lazy person might work more at their solution, so long as it helps them avoid more work in the future.

I try to cultivate what I like to think of as strategic laziness. It is good to achieve something with the minimal amount of work, but it is better to find a way where the thing does not need to be done in the first place.

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....

I have been saying for many years that overengineering is the plague of modern software. Almost everything seems far more complex than it needs to be.

Yes, definitely. There are too many diligent and too few lazy programmers. Too many devs take pride from coming up with complicated, overengineered abstractions – after all, if they can manage the complexity they must be really smart, right?

Eh. Sometimes over-engineering is a matter of perspective.

Take JSON API, a standardization of HATEOAS / REST principles around JSON and HTTP, for example. If you just naively walk up to it you think to yourself:

> Wait, what? Can't we just return the simple data we know we want? Why complicate this all with relationships, links, and meta data?

But after a while you realize that 90% of what you're doing could be abstracted if only you had a predictable output. So EmberData comes along and you write a Rails backend that has the nice advantage of not needing to worry about HTML (outside of OAuth / emails, anyway) and you harmonize your API. You use Ember Fastboot for slow clients and call it a day.

Someone else looking at what you've done may say:

> Wait, what? Why don't I just create static HTML pages instead of using your over complicated service?

And they're not completely off-base. In fact it's what I do for my own personal site. It's just that the context of their situation has different tradeoffs.

The same thing is true for a lot of software. Excel is "over-engineered" for most people. So is HTML. So is Unix. But in general what happens is that the person with the most complex requirements usually wins because they usually have the fattest wallet and everyone else papers over the complexity with abstractions or uses something less complex that meets their needs.

> So is Unix.

The Unix Hater’s Handbook [1] is a pretty good read (or skim). It’s healthy to remind oneself that, even though unix-likes are a savior from the deeply unpleasant alternatives, warts are present.

[1]: https://homes.cs.washington.edu/~weise/unix-haters.html

>Too many devs take pride from coming up with complicated, overengineered abstractions

This is what I feel about the current JavaScript ecosystem. I feel like web development became popular so programmers from other disciplines (C, Java, etc.) jumped in and found it to be too simple so they've hijacked the ship and created a new JS ecosystem that is as complex as their old environments.

Coming from a (primarily Windows) desktop development background, I can definitely tell you that JS/HTML/CSS and the DOM is some of the most complex, over-engineered stuff to ever see the light of day. It seems simple, but that's because it was simple initially, and now it's grown into this monster that has very little design at all and is just piles and piles of APIs and code added on top of other APIs and code.

Desktop development is blessedly simple, in contrast. The problem is that desktop development APIs and UI toolkits have been neglected for many years in favor of web and mobile, so now desktop development is also a fractured mess because much of it is outdated or hasn't kept up with current graphic design and UI standards. But, at its core, desktop development doesn't struggle with oddball concepts like promises and other bizarre features that were introduced to overcome issues with the overall design of the language/environment.

It's more like this: all the work that was previously accomplished just on desktop apps is moving to the web and all the various camps that previously lived in their own language/framework silos are reinventing themselves in within the js ecosystem. If that happened in the historical silos, nobody would notice. But since it all happens on the common js substrate, we see the big mix.

jumped in and found it to be too simple so they've hijacked the ship and created a new JS ecosystem

No, no, it’s that webdevs looked at other areas of programming and thought “we have to be complicated as them in order to be taken seriously”.

We need to establish a rigourous and quantifiable definition of software complexity otherwise we can confuse complexity for misunderstanding the difference between essential complexity and accidental complexity. Remember intuition is not the same as simplicity!

From my experience, complexity to me means how many combinations of states are possible a program, how many paths one can take at any point, how many side effects are possible... etc. An abstraction is supposed to manage complexity, if it doesn't, that doesn't necessarily mean the abstraction is too complex, but that the abstraction may just not fit the problem or cover all the edge cases. Thus a leaky abstraction.

Reply on news.ycombinator.com