You don’t need that complexity: A fresh look at your project

When you’re working on a project for a long time, you might start to believe that a lot of complexity is needed when it really isn’t. Sometimes, you might even stop noticing it. How can you stop assuming things have to be complex and start finding ways to make your work easier?

Definitions

First, here are definitions of some terms I’ll be using. Feel free to skip them if you’re already familiar with them.

The definitions of essence and accidental parts are paraphrased from No Silver Bullet—Essence and Accident in Software Engineering by Frederick P. Brooks, Jr. (1987).

Software entity

The term software entity refers to any software product or artifact. This could be a full application, a software library, a module, or even a single function or method, depending on the context. It’s an entity in the sense that it exists as a distinct, identifiable object.

Essence of a software entity

The essence of a software entity is an abstract construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.

The essence is abstract, in that the construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

It’s the essence because it’s inherent to the nature of the software entity. It can’t be eliminated or simplified by any technology or technique.

Accidental aspect of a software entity

Accidental aspect of a software entity is the specific representation of the essence and the mapping of it onto machine languages within space and speed constraints. Where essence is an abstract construct, the accidental aspect is a concrete representation.

It’s accidental because it’s not inherent to the nature of the software entity. You can eliminate or simplify it by different technologies and techniques. You can come up with a representation that is less complex, but you can’t make the essence less complex.

Essential complexity and difficulties

Essential complexity and difficulties that are inherent in the nature of the software.

Accidental complexity and difficulties

Difficulties and complexity that accompany software production but that are not inherent.

Fred Brooks (1987) believes that the hard part of building software is the specification, design, and testing of the essence, not the labor of representing it and testing the fidelity of the representation.

Looking at complexity in a new way

Reading through this topic made me think about how, sometimes, when we work on a project for a while, we start to believe that many things are essential complexity when they actually aren’t.

What if we periodically looked at our projects like they’re brand new? Consider if you could start your project over. What would you do differently? What choices would you make? What would you not do?

Sure, some things are accidental complexity, but you can’t practically change them. Be it for technical, political or other reasons. For example, it’s not very realistic that you’ll avoid using CSS as a frontend developer. But even then, when was the last time you checked? Maybe it’s now possible to actually do something about it?

Or perhaps you’re using a tool because everyone else is, but it’s making your work harder. Everyone suggests using Redux? You don’t necessarily have to. Everybody advocates strict TypeScript rules? That’s not a mandate either. JavaScript is making things complicated? Maybe you could use ClojureScript?

No supreme deity of programming will penalize you for venturing off the beaten path. Carefully weigh the pros and cons, understand why the established tools are there, and then make your own decision.

Let’s not be caught in the illusion that certain complexities are unavoidable when they are indeed optional. Take a step back sometimes. Look at your work as if it’s new. You might find a way to make things simpler.

References