Beware of The Merchants of Complexity

In a previous post, about earning your complexity, we talked about how we want to delay adding more complexity to our software application. In this post I would like to go into how we might procure complexity from different origins, so we can become more aware of these pitfalls.

One obvious origin for complexity are new features. These new features might be requested by the business or maybe the developers themselves come up with great ideas. The thing is, once we have built a Minimum Viable Product (MVP), any new feature that is to be added is likely a more complex one. Developers and architects should challenge these new ideas, to (1) see if they fulfill a functional need for the business and (2) if it belongs to the core problem the application is trying to solve. If the answer to these questions is no, then it right now might not be the time to work on these problems.

This is a fairly straight forward example, that undoubtedly we've all seen before. But what about the Merchants that sneak in Complexity under the radar? In this little paper I would like to highlight three additional Merchants.

Don't let the Astronaut Architect scare you

The Astronaut Architect, often times a very intelligent person, constantly looks for more layers of abstraction in every thing that is being built. The business wants a feature that lets users view a document that has been sent to them on a platform. The Astronaut Architect might fool you in to thinking you need a peer-to-peer sharing service, so users might watch their favorite cat videos together. And maybe send a text document too.

The Astronaut Architect is simply not connected to reality and what the business needs. They are too busy working out solutions that are never required. And worst of all, you might not even be aware you have one of these in your midst.

In other words, be carefull when abstracting or generalizing a solution too soon. Whatever you build needs to provide business value, and if we don't have a reason for reuse or abstraction, then we probably shouldn't invest in it right now. A huge trap in software development is building something for the future. If we don't need it now, we won't build it now. Be pragmatic.

Cutting-Edge Technology

Like most developers, I like learning about new technology. Maybe that's also one of the reasons we started looking intro Serverless at Draftsman.io. Although new technology might get us excited and we enjoy working with these technologies in our personal projects, we should think twice before implementing these into a larger (enterprise) software system.

It is not uncommon for larger businessed to hire consultants to solve a specific problem. These consultants usually favor the latest technologies that allow them to rapidly provide business value. When a business chooses to hire consultants on a project-basis, it might mean that the required expertise is not yet (widely) available within the business itself. This leaves us vulnerable for cutting-edge technology, that we won't be able to maintain without our trusted consultants. The next question that comes to mind, is the technology really battle-tested in complex enterprise environments?

The latest and greatest framework might be really good to use in a personal project or a startup, but does it really scale for enterprise usage. How good is the long-term support? And even if the support is solid, what about the recommended packages? I recently read an interesting article, that I think you might like, about choosing wrong front-end technology stack in a large enterprise company and the problems they faced, I Almost Got Fired for Choosing React in our Enterpise App.

Perhaps choosing to work with new technology or framework, might result in an undesired vender lock-in. This doesn't necessarily have to be a problem, but I bet you would like to know this before you start implementing and integrating in an existing system.

Resuablity is Overrated

I have already hinted towards this principle earlier in this post. Not too long ago, software systems were built to be resuable. This was a defining characteristic to measure if a piece of software was good or bad. Over the years, however, we have seen that resuable software components, more often than not, doesn't actually work for any real business requirements. The term Jack of all trades, master of none comes to mind.

I would always prefer a more pragmatic approach where we build exactly what is requested. When we get a similar feature request in the future, we can take time to decide if we reuse the existing solution, duplicate it or build it from scratch. The best decicion here depends on how closely related the features really are.

Do you know any Merchants of Complexity that we didn't talk about in this post? I woud love to hear your experiences with them.