Avoid complexity

“Genius can be recognized by its childish simplicity” ― Chinese proverb

Do you know the term “unnecessary complexity”? I know it very well. I have even participated in building some. It is so easy to ride in the sunset happily with your team and design something beautiful that solves all the issues we foresee. But this is a straight path to unwanted and unnecessary complexity. Not only takes it a lot of time to develop and maintain this complex solution, but also you could’ve found simpler ways to achieve your immediate goals.

Today let’s try to understand some of the most common pitfalls (anti-patterns) that might lead you to such accidental complexity. So that you know what are the signs to keep an eye on the next time you’re hopping on your horse.

You’re only thinking inside your box

I always hated it when I heard the American buzzword: “Think outside of the box”. It seems so artificial and it is being thrown in for all challenges, even if it’s fully inappropriate in the given situation. But there is a reason the saying is being overused: it is an extremely powerful tool. The best ideas and inventions in the history of mankind came from someone who was able to think outside the box - use an unexpected tool, turn things upside down, or try a completely different approach. We should get inspired by these geniuses and fly 10,000 feet above our problem space to see if there is a shorter and straighter way to our destination. Or maybe to see if the destination can be adjusted so that it’s easier to reach.

Practical advice:

• Discuss your goals in detail, and understand the driving forces behind them. What is it that we truly desire?

• Read about the topic, or god forbid, ask AI. You can run into unexpected inspos that can open up possibilities.

• Brainstorm with others: make sure you consider all ideas and you’re opening your mind to unusual thoughts as well.

Jump to conclusion early

This is quite a controversial one. A good leader can make decisions using sparse data by detecting underlying patterns and tendencies, no matter how faintly those are visible. This is one of the superpowers of visionary leaders. But this is a double-edged sword. Our mind works in a way that once we’ve arrived at a conclusion, it becomes a belief and we’re doing everything and anything to stay by it. It requires a lot of effort to avoid this cognitive trap and stay open to adjust our conviction if new, conflicting information is available. And we didn’t even mention looking for alternative information actively (see the previous point on our boxes)!

Practical advice:

• Actively seek all available extra input, information, and data that you can use to challenge your stance.

• Validate your hypothesis or idea with all kinds of available data you collected. Don’t dismiss the results with “Oh, those are just outliers!” but understand what’s behind the mismatch. A small hump in the chart can lead to important discoveries that’ll turn your world upside down.

Build for future use

This is a typical startup behavior. When the path for your product is not paved yet, it’s easy to wander around and come up with future use cases and features to be taken into account with your current design and architecture. This goes against the agile way of building things, but everyone who has burned themselves with a bad design that caused a lot of tech debt is getting overly cautious about not doing it again. But here is the deal: The future you’re imagining might not come at all. Your ship might take a very different turn at one point and all the work you’ve done preemptively was just superfluous. So be very aware of what is a must and what is only your wishlist item.

Practical advice:

• Stay in the present, and focus on the development that is needed right here and right now. Can you tie this exact development to an existing feature on your backlog? Or is this something that might come up since you discussed it casually by the water cooler?

• Work with Product on verifying if what you want to build is indeed needed. They’ve invested a great deal of energy into determining the scope for the next release, so don’t hijack their efforts just because you think better.

Note: If you really want to work on some extra features or improvements that are not in the current scope, you can do it in your spare time without impacting the committed deliverables. Only come forward with it once it is ready to be added to the system. And be ready to accept if it doesn’t fit on this train, only the next one.

Emotional attachment to your work

When you have invested a lot of time and energy to familiarize yourself with a problem, come up with different solution ideas, and arrive at one that you finally implemented, then it’s easy to get emotional about your work product. It’s a natural process, you have been living and breathing with this piece of product for days, weeks, months (years?). But this can lead you to get defensive towards your work - and keep it around even if it would be better to throw it away and start from scratch.

Your value is not measured by the number of lines of code you wrote. The measure is the quality of the software you created. A negative pull request means you’ve eliminated unnecessary complexity from the code - just like when you’re getting rid of all the junk you’ve collected over the years. Marie Kondo’s rules are not only for keeping your house tidy, they can be applied to keep your product and your repository tidy as well. ;)

Practical advice:

• Be honest with your judgment: is it worth keeping and patching the old solution? Or a starting with a clean slate would be cheaper?

Food for thought: What are your best practices to avoid unnecessary complexity? How do you keep yourself aware and open-minded to avoid the pitfalls? As a leader, how do you guide your team to avoid the pitfalls? Do you feel yourself both empowered and able to put a brake on the stud that is about to go wild? I would love to hear from your personal experiences.