Watch Out for this One Software Company Killer

I worked for a start-up many years ago that was brought down by this One Thing.

The company didn’t go out of business, but it was so affected that it lost its market leadership and has never regained it. Giving up being the frontrunner in a market to a competitor is terrible for a start-up. It means that customers prefer a competitor’s product. Another company is eating your lunch.

It’s a bad rap. What is one to do? Compete on price? Then your margins are going to come under pressure. You’re making less money than before. There is less cash to invest in fixing your product. Your start-up valuation drops. It’s harder now to catch up and overtake the new market leader. A vicious cycle if ever there was one — and to be avoided if at all possible. Losing the competition war is not a pleasant situation.

This start-up had been around for a few years before I joined the software development team. It seemed, its product was popular with customers. To begin with, the company grew in leaps and bounds. I had done my research. I deliberately wanted to work for a fast-growing start-up that was the leader in a product niche. It appeared I had found a business that met my criteria.

Once I took up my new position though, I quickly realised all was not as it seemed. Customers were generally not happy with our software product. The two main reasons were:

• A large number of bugs in the system. Fixed bugs frequently reappeared.
• No significant feature had been released in months. Some much-asked-for features had been promised but not delivered.

Dissatisfied customers will scout for products that serve their needs better. They will let you and others know what they think of your product; especially its flaws. Our product reviews were trending downward.

Understandably, the leadership team harangued developers to fix these problems. Unfortunately, whatever we did, nothing seemed to work. The defect count remained stubbornly high. The code was convoluted and confusing to work with — it was hard to develop new features or even change existing ones.

The One Thing we were facing in our source code was ‘Unnecessary Complexity’.

Once endemic in a system, Unnecessary Complexity, requires immense effort to remedy.

All software systems contain complexity. Exceptional systems hide complexity behind intuitive user interfaces. After all, they exist to solve complex problems for their users.

Now, there is a difference between Necessary Complexity and Unnecessary Complexity in systems.

Necessary Complexity, as its descriptor states, is required. No further simplification is possible without changing the intended function of the system. It’s as per Einstein’s quote: “Everything should be made as simple as possible but not simpler”. By making it simpler still, something necessary and required is lost.

Necessary Complexity’s evil brother is Unnecessary Complexity. It’s the extra Complexity that developers unintentionally introduce. Why is it unnecessary? Because the code could be more straightforward without loss of function. Easier to understand, simpler to change.

How does Unnecessary Complexity come about?

I do not believe that developers intend to cause harm to their software systems. In my experience, it is a state of affairs that invariably creeps up on people. Therefore it is that much more insidious.

Agile to the Rescue

Businesses want to move quickly. Speed-to-Market has become the catchcry of ambitious leaders. It’s a perverted reversal of Aesop’s fable; it’s the hare that wins the race, not the steady tortoise. Or so the misguided thinking goes.

Software delivery teams are often in the firing line for faster and faster feature releases. To relieve the pressure, the first thing that developers will often jettison are sensible development practices.

I am also guilty of this. I have done this myself often enough. But with effort, I have trained myself to hang onto my Agile technical disciplines even under pressure. I believe that is what makes a professional.

What are these practices?

Primarily it’s the Agile Methodology. Not just project management aspects but also technical practices, like

• Writing unit tests first,
• Pair programming,
• code reviews
• Continuous Integration & Delivery
• Following clean, pluggable architecture,
• Learning from mistakes individually and as a team,
• Constantly striving to get better at development.

If we were to adopt a broader range of the Agile Manifesto’s principles, our industry could reduce the degree of Unnecessary Complexity in our software. Simpler code does not only have greater longevity; it is also more enjoyable to work with it.

Conclusion

Let’s put the spotlight on Unnecessary Complexity in our source code. The Agile Methodology’s technical practices are not as prevalent in our industry as they deserve to be. They should be adopted more widely to create a world where systems not only work reliably today but will also perform tomorrow, next week, next year.

If you enjoyed this article, please leave some claps — and a bunch of claps if you loved it! :) Thank you kindly.

Join my email list to fast-track your software engineering career.

When signing up, you’ll get my guide, ‘The Road to Master Progammer’, containing 3 powerful ideas to help you shorten your journey to expert programmer.