Mar 8
Does good software need to be complex?
A lot of people tend to correlate good/robust/stable software with complexity and complicated terms that make the software sound very advanced and ahead of its time.
This article is basically me thinking loudly about the increased complexity in today’s software and whether all of it is really necessary or whether we can get to the same functionality with a simpler approach that really fits our needs.
Remember, end users don’t care at all about the written code, the only thing they care about is the user experience they get.
1. Does It Really Serve the Business?
The first thing that I would think of while coming across some overengineered/complex pieces of software is:
Does it really have to be that complex?
Is there any added value behind making it that complex?
If the answer is yes from a technical point of view, Does our business need this technical added value at the moment?
Or can we get away with a much simpler version of the software?
Better a diamond with a flaw than a pebble without. — Confucius
Use the right tool for the job
Think of DDD, TDD, BDD, or some of the advanced architectures like Microservices, SOA, etc… all of these methods are very solid and perfect ways of building software that strives for scalability, flexibility, and maintainability.
There is absolutely nothing wrong with these techniques and methods, but the issue is how and when we implement them. For example, if we were to use these methods in a simple CRUD application that would create a lot of unnecessary code and increases the cognitive load while maintaining it or onboarding new developers.
You would never use a chainsaw to simply slice bread,
a simple knife would perfectly do in this case. In fact, there’s nothing really wrong with a chainsaw, indeed it’s a perfect tool for cutting other stuff, but not bread. Using it to slice bread would be unnecessary overengineering and a burden that we don’t need.
Remember, before adopting any shiny new technology or technique ask yourself, is this the right tool?
Consider TTM (Time To Market)
In today’s very competitive and tech-oriented market, delays to delivery can negatively impact businesses. And it’s really a tradeoff between quick delivery and solid/stable software, we don’t want to keep perfecting our software forever and in this case, we’d never deliver to market nor do we want to rush into the market in a way that breaks when users use it. But the idea is if we can get rid of unnecessary complexity in our software that can save us a significant amount of unnecessary delays and achieve the balance between quick delivery and solid software. Thus we can get our MVP (Minimal Viable Product) to the customer's hands and kick off the feedback loop that will let us know if the customer's needs are really worth adding any further complexity or not.
The Only Constant in Life Is Change. — Heraclitus
2. Are We Really “Developing” Our Software?
Software Development is a continuous process hence the word “Development”. Users’ needs evolve and change, and so should our software.
Rather than trying to think of every possible scenario that a user might or might not come across and trying to cater for it, It would be much better if we deliver an MVP, and then based on the user’s feedback we can discover new needs, adapt to them and iterate. In other words, “Develop” our software.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. — Antoine de Saint-Exupery
3. Let Go of Unnecessary Stuff
Nothing feels better than deleting some unused code that’s been lingering in a repo for ages without any value or refactoring pieces of code in a simpler way that might lead to better performance and/or an easier understanding of what the code does.
Having lots of hard-to-read pieces of code really hurts developers while debugging and investigating issues. Simplifying this code or even getting rid of it if it’s not of much use, would save developers from getting insane while trying to find a bug or resolve an issue.
It’s also worth noting that if it works perfectly and there’s no real benefit of refactoring it, then keeping it as it is would be wiser in this case.
Lastly, always feel free to take a step back before chasing that shiny little technology that just came out or implementing that very advanced technique and ask yourself:
Is adopting this technology an end goal?
Or is it merely a method to serve the business?
Answering these questions would really save you from a lot of pain doing time-consuming and complex stuff that could have been done in a much simpler way.
