Alan Perlis' old motivational-poster slogan "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." has a fair bit going for it.
But you could be a some. But if you were a some it would mean that there was no possibility of actually removing the some from the statement because it actually did describe accurately that there were somes that could avoid it.
So it is sort of a Gödelian joke.
Charles H. Moore, e.g. -- the 25% pulls its weight.
"Some can manage to get the thing done by avoiding the complexity, geniuses remove the complexity for everyone"
That is why software engineers are seldom rewarded at their companies for "removing complexity", only for finishing projects.
But that doesn't mean you should always work on features. If anything, it only means that feature-bloat is doubly bad, not only adding logic and binary size, but imposing opportunity cost.
Most users hate features. Nobody has ever sworn at their computer because they had to make a mess in Excel to use VLOOKUP() before XLOOKUP() was invented (even though I love XLOOKUP()). Plenty of swearing happens because the computer just won't respond or it's taking whole minutes to send each email when you're trying to leave work on Friday night.
Of course, my point was that it is usually not beneficial to worry about performance until that happens. And when it does, improving the performance of the product becomes a project in its own right. Misbehaving parts of the software are diagnosed and fixed, usually by introducing even more complexity.
Of course it is, in fact it is pretty much all-pervasive in our field, even in very successful software companies - which makes me question whether removing it is as valuable as people make it out to be.
The only reason complexity is prevalent is due to a shortage and geniuses (and also a shortage of "Some" too, if we're going by Alan Perlis' quote).
You can spend 5 years customizing off the shelf ERP software to do insane things because John in accounting and Jane in HR won't budge from weird processes they built over the decades... Or you can use that opportunity for business transformation, simplify their processes and their program, save money, reduce errors, improve responsiveness and timeliness, and generally make it a win win win.
Not all complexity can be reduced of course. I can imagine self driving cars, rocket science, etc are all about critical edge cases.
But when it comes to business, and particularly back office processes (where a huge amount of IT goes) , a lot of complexity is unnecessary. Each company each department each person is certain they are special, unique, and their requirements are paramount and unchangeable. But if you move around a bit you'll come to believe otherwise.
Yes, and it's often the best feature of the software, as far as the sale teams is concerned, because it allows them to sell concultancy fees or because it satisfies the customer by matching 100% it's crappy requirements (which they don't really need).
Geniuses invent new ways to get both. Those ideas permanently move the trade off curve outwards.
In programming, some abstractions which have done this are: Operating systems (Abstracting away the hardware), Grace Hopper’s invention of program libraries, high level languages and compilers, HTTP and JSON, tcp/ip (replacing custom transmission protocols), and there’s lots more. Calculus and the Arabic numeral system are examples in mathematics. (It’s insanely difficult to multiply using Roman numerals!)
How many of us get to work at such lofty problems though?
>Calculus and the Arabic numeral system are examples in mathematics.
Eye roll. Of course reducing complexity is the very essence of mathematics. Let us not pretend that software engineers are mathematicians.
How many of us choose to work on such lofty problems? You can work on whatever you want, whenever you want. But lofty, unproven ideas don’t pay Google salaries. Your career is a choice, not a prison.
And of course most software engineers aren’t mathematicians. We’re talking about genius - and most of us are a long way from that. Most of us are lucky if we manage to invent a couple complexity reducing concepts in our entire careers.
But lots of great computer science ideas have “come down the mountain” from mathematics adjacent work. Functional programming wasn’t invented by C lovers like me. But I love closures, pure functions, and map / filter / reduce. This stuff makes certain problems lovely. And we wouldn’t have any of this without mathematically minded CS.
He made the point (I think) that you do want simplicity, you don't want simplistic. That is: it should be able to do all the things you want to, but in an easy to use manner.
Worth striving for I believe.
To me, simplicity means that there's clarity of purpose for each component and how it interfaces with other components. A large system can still be simple if the interactions and interfaces between the different components are reasonably well understood and justifiable. I think thoughtful UI design is how you prevent complexity. The UI for developers and software is the API.
When you start adding features and instead of generalizing you simply (heh) add a special case to allow two unrelated components to communicate, and then another, and another, until the two components become dependent on each other such that neither can do anything without the other; then you have a complex system, and the "UI" for the developer is worse because it's full of seemingly random elements in random places that only do one very specific thing.