“Everything should be made as simple as possible but no simpler”
– Albert Einstein
Is there any benchmark for software complexity? We guess no. Still, it’s worth sticking to the principle that the architecture and code shouldn’t be more complex than they have to. And although product designers and engineers are well aware that less is better, it’s often difficult to achieve that coveted code simplicity.
So why does it happen? Common reasons behind the unnecessary complexity are ambition and poor communication within the development team – everyone wants their project to be perfect. However, this is hardly possible to achieve and leads to overengineering – building unnecessarily complex software products that are challenging to maintain.
What is overengineering?
Overengineering means developing a software product with more functionalities and features than the business actually needs. It goes without saying that such an approach is highly inefficient, making it vital to identify the symptoms of overengineering as early as possible.
With many ways to overengineer, however, two are the most common:
- Making something unnecessarily extensible, that doesn’t need to be extended, for example, your project proposes some rare but priceless value for companies. You are paid with a fee for this each time your service is used. It happens more or less randomly once or twice per week. Your desired expectation is 10,000 companies you serve in 10 years in the best case to become a billionaire. This fee payment is not the main value you sell, just a possible option.
At some moment, your developers asked for more time to resolve some frequent requests outages. When you dig into details just asking how many requests the system can handle currently, their answer is 100,000 per second. Just think, your system already handles 10 times more requests per second than you will need it to handle in 10 years. - Automatical handling of extremely rare cases.
Just a very simplified example, the same kind of project mentioned above. One of the values the service provides is instant payments. The typical payment is around $5,000. Your expectation is not to have payments of more than $10,000. Your banking provider allows up to $30,000 instant payment (otherwise, there will be time-consuming security checks etc).
Now, let’s imagine a payment that exceeds $30,000. It’s an extremely rare case and not more than a theoretically possible payment. In this case, there are 2 optimal ways to avoid overengineering: process transactions over $30,000 manually or not allow instant payments exceeding $30,000.
Overengineering vs. underengineering
In simple terms, you’re overengineering when you’re doing too much design to solve a basic problem, while underengineering means you’re not doing enough.
Identifying an underengineered product is not complicated. It’s generally done through testing based on verification and validation criteria. Underengineered solutions are of poor quality since not all specified requirements are fulfilled, and one or more system elements are unavailable.
An overengineered product can also fail, so it’s essential to find a middle point, avoiding under- and overengineering.
What are the consequences of overengineering?
Higher costs
First and foremost, overengineering is notorious for increasing software development costs. Unless a software engineering team opts for the simplest solution to tackle an issue, expect expenses to grow and, not to mention, iterations to get less frequent.
In addition, overengineering also means higher maintenance costs. Simple code is easier to deal with while complicating it, developers assume the extra burden of complicated maintenance.
Accumulation of technical debt
Software development is often associated with building products in fast-paced, dynamic environments, missed deadlines, and engineers continuously pushing quick code changes. Frequent code modifications and high pressure are incompatible with sound decision-making, leading to technical debt.
Unattended for too long, the technical debt decreases the productivity and efficiency of the whole team. For instance, unnecessarily increased code complexity makes it harder for developers to understand, leading to even more complex problems in the future.
Delayed time-to-market
At its core, overengineering means writing too much code and building more than necessary. Consequently, there’s no wonder that an overengineered solution takes longer to deliver than initially planned.
Why do developers overengineer?
Software development teams tend to overengineer due to some simple reasons:
Striving for perfection – software development is an intensely competitive niche, so there’s no wonder that engineers try to use their skills and talent to the fullest extent, which often leads to an overengineered product.
Excessive speculation about future needs – developers sometimes go too far into the future with their expectations for software products, clearly exceeding project requirements and specifications.
Inefficient management – poor communication within the team and between the team and the client can significantly feed into overengineering. For example, if there are too many go-betweens between the team and the business, it’s easy to misinterpret project requirements and business needs, making engineers spend effort and time on excessive rounds of development.
Focusing too much on innovation – developers are innovators by nature and can’t do without experimenting and keeping up-to-date. However, businesses often need fast-to-market products, not ones jam-packed with modern technology.
Lack of expertise – the same product can be built in different ways in terms of budget, timeframe, and code readability. If the team can’t come to a single decision and put combined effort into developing a simpler solution due to the lack of expertise, they risk overengineering and writing code that can’t be reused.
How to recognize overengineering?
Identifying overengineering is the first step to handling it and preventing it from recurring in the future. The best and the easiest way to spot overengineering is to look at the project from the end user’s or customer’s perspective, asking yourself if the product solves the problems it is supposed to solve.
Questions to help you identify excessive engineering
- What is the problem, and how does this product solve it?
- What are the user stories behind the product? Does the product have any features that aren’t related to them?
- Is this the simplest way to implement business requirements?
- How can we achieve simplifying things but still fulfilling requirements?
Typical indicators of overengineering
- writing code that solves problems that don’t exist;
- developers striving to be ahead of their teammates and showing it with the help of code;
- ignoring the team/company rules
- there is a gap between the problem’s complexity and the effect of the solution;
- failing to prioritize tasks;
- using wrappers and adapters for everything.
How to prevent overengineering?
Fighting excessive engineering is all about changing organizational culture and enhancing engineering practices. To prevent overengineering, software development companies need qualified CTOs, who can guide the product design in the right direction, and business-oriented product managers to help align product design with business needs.
Here are some other critical points to take into account if you’re determined to minimize overengineering within your team.
1. Make sure objectives are clearly defined
The development team members should have a clear understanding of what they have to build. Therefore, a product manager must discuss the project with the team, explaining its scope, goals, context of use, types of users, and other details. Notably, developers should clearly understand which problems the product is intended to solve. Ideally, the team can move on to design the solution only once everyone involved understands these basics.
2. Don’t kill time reinventing the wheel
With so many design patterns, frameworks, and libraries to streamline development, there’s no need to build something from scratch and risk overengineering it.
3. Plan for the future
It’s often critical for software to be scalable; still, it’s not a one-size-fits-all rule. Instead, you need to have the most precise possible picture of what your product will or won’t need in the future. Is the user base supposed to grow? Will you need to integrate this product with other solutions? Or maybe its scope is restricted to the current use? Questions like these can go a long way toward creating a viable plan for future additions.
4. Write tests before development
Many teams follow the practice of test-driven development that helps avoid excessive coding.
5. Leverage the iterative approach
Unlike the conventional linear approach to the software development process, iterative methodologies suggest developing software in smaller sprints, with design modifications and new functional capabilities added at each new sprint. Frequent reviews help to monitor product development effectively and check if it aligns with requirements.
6. Ensure direct communication among project stakeholders
Regular meetings to discuss the project’s progress help make sure everyone is on the same page. It’s also important to talk through challenges that might have arisen and collaborate to come up with the best possible solutions.
7. Stick to the KISS principle
You can significantly reduce your chances of coming up with an overengineered design when sticking to the KISS principle (Keep it simple, stupid). This design philosophy states that designs and/or systems have to be as simple as possible while unnecessary complexities should be avoided.
Final thoughts
Overengineering means solving problems you don’t have, and it’s more common than you may think. It’s always associated with wasting time and money, decreasing the whole team’s productivity and significantly increasing the product’s time-to-market.
The best way to prevent overengineering is to gather a team with a product mindset (or if you partner with a vendor – choose one that will gather this team for you rather than offering individual developers). Product thinking puts customer needs at the heart of software development, helps avoid overengineering and drives long-term success.
