Simplicity in Software Architecture is Underrated


16 Flares 16 Flares ×

fight hard against complexity

“Simple is better than complex.
Complex is better than complicated.” – Zen of Python

So what makes something Simple, Complex or Complicated?

It varies – A problem could be simple if you are Einstein but unfathomable for many of us. In case you are on the other side: hi Einstein!

Generally speaking, a problem is simple if it has just a few components and our mind grasps it easily. A complex problem can have many components and our mind takes some time to understand it, say, 20 minutes or more just to understand the problem. A complicated problem is a beast (sometimes beasts). You will keep missing few parts of the problem even after you get it. It is very difficult for our mind to keep the entire context of such a problem.

Why bother about it?

We are software developers and we love solving problems once and for all so that other humans won’t have to. The more complex a software becomes, the more difficult it becomes to maintain. This makes the software more likely to break due to changes and difficult to debug. It can cripple the team and bring the development pace to crawl.

Complexity is inevitable

Every non-trivial and useful software will gain weight as it keeps expanding its problem horizon. That is to say, complexity is inevitable for such a software because we will keep adding features and enhancements to make it more useful to our dear users.

Why should we fight against architectural complexity?

Since architectural complexity of a software already depends on the complexity of the problem it solves, what we should not do is make the software unnecessarily complex. As obvious as that sounds, it is important to keep it in mind, because it’s very tempting to step over the line and make something more complex than it should be. Why? Kendra Cherry has explained it better in this article. Though all the four “obstacles in problem-solving” listed in that article are very relevant for software developers, I must mention two of them right here. These are faced very frequently in our field:

Assumptions: When dealing with a problem, people often make assumptions about the constraints and obstacles that prevent certain solutions.”

You bet. We assume 100,000 users are going to sign up within a couple of days after we launch. We assume that a simple network call will take so long that we have to keep the data prefetched and maintain a cache. We assume a lot of such constraints and add unnecessary complexity to the architecture which is not needed right at this moment. According to Kendra the second obstacle is:

Irrelevant or Misleading Information: When you are trying to solve a problem, it is important to distinguish between information that is relevant to the issue and irrelevant data that can lead to faulty solutions. When a problem is very complex, the easier it becomes to focus on misleading or irrelevant information.”

I couldn’t agree more. It is easier to focus on these questions instead of the real problem at hand: should I be using NoSQL or MySQL? If NoSQL, will it be MongoDB or CouchDB. Enlighten me but I have never heard of a software that failed because it was using CouchDB instead of MongoDB (or vice versa).

Keeping things simple is hard, but important. While architecting and developing a software, you have to be careful about everything you are adding to it. Always ask yourself – Is that absolutely necessary? I would like to end this post with the following quotation:

“It is not a daily increase, but a daily decrease. Hack away at the inessentials.” – Bruce Lee

P.S. Please go and read the whole Zen of Python if you have not already.

Image Credit: dno1967b on flickr.

16 Flares Twitter 6 Facebook 5 Google+ 0 Reddit 0 Buffer 0 LinkedIn 5 16 Flares ×
CloudMagic - The email app with magical search
0 comments