Less Is More

What’s true for design in general certainly is true for software design in particular: Less is more – or paraphrasing Dieter Rams – “Write less software in order to write better software.”

A few weeks ago I read this interesting article by web accessibility consultant Heydon Pickering. In this blog post he argues that the only foolproof way of writing performant web applications is to write less code. Sure, all that fancy minification, transpiling, JIT / AoT compilation and optimisation stuff might make your app perform better but is much of your app’s code and features even necessary in the first place?

Heydon argues from a web and specifically a web accessibility perspective. Much of the stuff we’ve come to know in websites and web applications could nowadays just as easily be accomplished using native components provided by the browser. However, we often use non-native or even bespoke solutions to tweak browser behaviour to the extreme. Heydon mentions checkbox behaviour, which in many web applications is a particularly bad offender in that respect. That kind of control we try to exert over predictable, native behaviour (i.e. behaviour that’s provided by the user’s browser or OS out-of-the-box and hence doesn’t incur additional costs – performance- or otherwise) comes at a price:

It requires additional dependencies. Dependencies that need to be maintained and that can break at any time.

It requires writing more code. More code means more potential for errors.

As a consequence, your application will inevitably be more complex. An increase in complexity will make your software both more difficult to understand and less maintainable.

While all of this might be true for modern web development in particular it applies to software development in general, too. In the enterprise software development world there’s a veritable cargo cult around using certain frameworks (Hibernate, Spring, you name it), which are often used in a blanket fashion for everything without thinking twice. Now, don’t get me wrong. I’m an avid user of many of these “enterprisey” frameworks – where using them makes sense. Oftentimes what we see however is a large number of dependencies being used without measure just because “It’s always been done this way.”.

Not only does this kind of behaviour lead to massive accumulation of cruft over time but it also keeps you from thinking about novel ways and solutions! This latter aspect very likely is one of the reasons why software development despite all its inherent progress and modernity at times seems woefully stuckin the past.

As software developers, designers and product owners we need to always be thinking:

Is the additional complexity I’m about to add to my software worth the trade-off?

Does this really help me achieve my goals?

What do I want to achieve with this in the first place?

Are the answers expedient to my problem or do I maybe need to ask different questions or frame them in a different manner?