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

My recommendation is to go for replaceability instead of re-use. Replaceability leads in the right direction: you think about how to separate responsibilities in order to make them replaceable, which gives you loose coupling. You think about separating clients from the implementation in order to keep it replaceable, which gives you client-driven APIs.

And, if you might realize after a while, that a component tends to be used several times, you go the extra mile to make it really re-usable in terms of additional testing, documentation and hardening. Therefore I would like to add one more line to the learnings: strive for replaceability, not re-use. It will lead you the right way.

Premature abstraction really is the worst type of evil in engineering, as well as in any other design discipline.

via blog.codecentric.de

Without beautiful, precise pictures of the product we wish to create, how do we gain resources to actually make them a reality? This new approach would turn the process on its head: it makes building and designing something one and the same. Rather than creating and presenting a design prototype, only to dismantle it in order to build and present a functional prototype (often at a lower quality), the functional prototype itself becomes the presented artefact, greatly reducing the cost of making it a stable, complete product.

The burden and responsibility of precise, perfect design should be shared between designers and engineers. The fact that this is true for every other related industry—architecture, industrial design, printed matter—and not for digital product design is indicative of nothing but the immaturity of our tools, processes, and philosophy.

Daniel Eden on the current state of design tools and workflows, short and on point.

I have always believed we need to stop treating design and development as two distinct disciplines and start following a more cohesive and authentic approach.

via daneden.me

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

It all happened in six months from May to December 1995. Netscape Communications Corporation had a strong presence in the young web. Its browser, Netscape Communicator, was gaining traction as a competitor to NCSA Mosaic, the first popular web browser. Netscape was founded by the very same people that took part in the development of Mosaic during the early 90s, and now, with money and independence, they had the necessary freedom to seek further ways to expand the web. And that is precisely what gave birth to JavaScript.

Nice post on the history of JavaScript, or how a scripting language that was initially designed and developed in a few weeks has become one of the most successful programming languages of all time.

via auth0.com