Modern cars work, let’s say for the sake of argument, at 98% of what’s physically possible with the current engine design. Modern buildings use just enough material to fulfill their function and stay safe under the given conditions. All planes converged to the optimal size/form/load and basically look the same. Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance. Everybody just seems to be ok with it. People are often even proud about how much inefficient it is, as in “why should we worry, computers are fast enough”:

Software engineering shifted from craftsmanship to being an industrial process without learning any lesson from other… industries.

Now it’s easy to hate on Electron’s inefficiency or blame overengineering becoming standard practice in “modern” software development, but if we really want to tackle the issue, we should focus on changing the perception of the underlying economics that push businesses to accept the tradeoffs between performances and the ability to ship products faster. Nothing comes for free, and today’s competitive advantage is tomorrow’s technical debt.

It’s totally acceptable to build products that are “good enough”, but we should never stop challenging how good is good enough.

via tonsky.me

Complexity bias is a logical fallacy that leads us to give undue credence to complex concepts.
Faced with two competing hypotheses, we are likely to choose the most complex one. That’s usually the option with the most assumptions and regressions. As a result, when we need to solve a problem, we may ignore simple solutions — thinking “that will never work” — and instead favor complex ones.
To understand complexity bias, we need first to establish the meaning of three key terms associated with it: complexity, simplicity, and chaos.

Nice piece on the risks of being seduced by unnecessary complexity, especially in the broader context of language. It reminded me of an old essay by Italo Calvino, “L’antilingua”—literally: “the anti-language”—in which he comically shows the effects of replacing simple words with increasingly grotesque jargon. To paraphrase Calvino, the anti-language is the language of people who prefer saying “utilize” instead of “use”, people who are scared of showing familiarity with the subject of their talk. According to him, speaking the anti-language is a sign of being out of touch with life, and ultimately represents the death of language itself.

via fs.blog

People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall.

Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.”

But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted. (…)

If a team works to a spec, there’s no point in iterating. The purpose of working iteratively is to change direction as you go. Defining the project in advance forces the team into a waterfall process. If every detail of the plan must be built, teams have no choice when they discover something is harder than expected, less important than expected, or when reality contradicts the plan.

Fundamental read on some of the most common misconceptions about product management and software development.

via m.signalvnoise.com