Who wouldn’t want to do something perfectly?
Who wouldn’t want to look on their work and say “Yep, no mistakes or corrections needed there”.
We all wanna do the best work we can and we all have horror stories in our back catalogue of when we’ve been caught out because we didn’t.
To me the first step to preventing over-engineering is understanding why people over-engineer. But first…
Why is over-engineering bad?
When we talk about over-engineering or even under-engineering, I feel we’re talking about an incorrect balance. If you’ve built a new website with an over engineered front end with snazzy animations but an under thought out back end, then your whole website suffers.
Software engineering isn’t just about writing code, it has a lot to do with well though out planning and balancing many things at once in order to deliver a project on time, that your customer is happy with.
Over-engineering has a time cost, a money cost, and sometimes has an energy cost. Wearing yourself out trying to look into the minutiae of every little thing has the potential to drive you mad!
Why do we over-engineer?
Reason 1 — Lack of trust that things will be ‘fixed’ later
“We’ll fix that later”, “Make a tech debt ticket and put it in the back log and prioritise that”, “We can do that after the deadline date when things aren’t so busy”
Sound familiar? There’s nothing wrong with these statement, as long as they’re true... Feedback I’ve gotten from engineers is that the reason they want to over-engineer a problem is that they’re concerned that if they don’t get it right the first time, they won’t be able to revisit it later. We need to build trust so that the team is confident that everyone understands the importance of quality iterating on solutions.
Ensure there is a plan to handle tech debt within the team, and ideally a plan which is department wide.
Solutions
- Provide a guaranteed two weeks at the end of a project deadline to fix any lingering issues we didn’t get round to fix during the project
- Have technical refinement planning where you can prioritise technical debt and other technical tasks like library upgrades
- Solutions should include the product owner to ensure it’s not an us vs them type thing as the whole team should care about tech debt
Reason 2 — They just didn’t see the simpler solution
Sometimes this can be the case too! There are many solutions to a problem, some are more complex or time consuming than others but produce the same result without any downsides. If you find out that someone has over-engineered their solution at the code review stage, that is way too late. You’ve wasted time from the project and also wasted this engineer’s time who might now have to end up rewriting their solution. Technical solution discussions need to happen a lot sooner than the code review and sign off stage.
Solution
- Ensuring there are technical kick offs/investigations before a ticket is picked up. This doesn’t necessarily have to be a super official thing and depending on the problem, could just be a ten min conversation at your desks
- During the refinement/pre-planning meeting, there are some high level implementation discussions
Reason 3 — Going down the rabbit hole
There are times when people will just get caught up in delivering the best and most elegant solution to a problem. This thinking can sometimes suck you in and you forget that you are supposed to be solving a problem for your users or delivering a feature.
Solution
- When you feel you or someone else in the team is going down a rabbit hole, always bring it back to “What is the problem we’re trying to solve?”. “What is the end goal we’re trying to achieve?” If the remit is to create a website for hundreds of users, should you be engineering a solution for millions of users right now?
Reason 4 — I wanted to try out something cool!
We’ve all done it, sometimes you read an article which shows you a cool new design pattern and you’re desperate to use it in your code no matter what! Sometimes however, clever code does not mean good code. I think we all just need to remember that above all, coding is about keeping things simple, easy to understand and maintainable.
Solutions
- What I do personally is try out my cool new technique that i’ve learnt to satisfy that urge. Once I have that working and I have the tests to prove it, I’ll refactor and see if a simpler solution is available
Conclusion
In the vast majority of cases, the best approach is to keep things simple and focus on the problem you’re trying to solve. This doesn’t mean that you ignore best practices, but simply that there is a balance to be struck and it’s up to you to work out where that balance is. We need to feel confident that we can come up with a solution to a problem, deliver it, celebrate that success and then throw all of it away if needed.
