Vegan meatballs and engineering: A cautionary tale

Alex is an engineer. One day, completely out of the blue, Alex receives an email from Rob - an old friend from Uni. After the usual pleasantries, Rob starts to get to the real reason for his spontaneous email. He has a problem, and is looking to Alex for help. It reads:

• “I have this fast food restaurant down in London. We serve these amazing vegan meatball subs... 8" long, family marinara recipe, massive buzz on social media - They are just insane! BUT, it’s too expensive to keep all of the ingredients hot, and customers are complaining about getting cold subs, then walking out without paying. I need your help! Any ideas?”

Alex replies within a matter of minutes:

• “Wow, those subs sound amazing! Your problem is pretty clear, and it sounds like what you need is a ‘sub warmer’, that will get them to just the right temperature before you hand them over to customers. I’m pretty sure they don’t exist yet, but I can design, build, test and deliver one to you. You’d be looking at around £5,000.”

Rob replies a few days later:

• “Whoah, that’s a little on the expensive side! But, I trust you, Alex. It sounds like this is a cost we may just have to bear for the perfect solution. How soon can you start?”

A few months later, Alex stops by at the restaurant to deliver the working solution. It’s gas powered, has flames painted on the side, and has two 8" long compartments - allowing them to heat two subs at a time. Rob is over the moon and gushing with praise. There are tears in his eyes as he tries it out for the first time. Alex strolls out of the restaurant with a satisfied smile on their face. The birds are singing in the trees.

6 months later, Alex returns to the restaurant to see how things are going. Rob immediately comes out of the office to say "Hi!" , but there’s an awkwardness about the greeting that is difficult to place. Alex peers into the kitchen to check how the sub warmer is faring, but it is nowhere to be seen. Rob preempts Alex’s question and explains:

• “So, the sub warmer was perfect…. Really really great. But, the gas supply went AWOL one day... Orders were piling up, and we didn't know what to do. I called you, but couldn’t get through. Then I tried Sonita from uni. You remember her, right?”

Alex nods a reply, eager to hear where things are going.

• “Well, I explained the situation to her... She went silent on me for a couple of minutes - I thought she was messing with me! But then she asked: ‘All the food you serve contains water, right?’
• ‘Yeah’, I said, 'Why?'
• ‘Have you tried a microwave?’”

Alex's face reddens slightly. They bite their lip to stop themselves from interjecting. Bob continues:

“We already had this microwave in the corner that we weren’t using. We plugged it in and gave it a try. The results aren’t quite as good, but we can heat four subs at a time, it’s cheaper to run AND easier to clean. We even diversified and started doing regular-shaped sandwiches, and these amazing hot pasta bowls, and it does the job for those too!! We haven’t looked back really. We even named the microwave ‘Sonita’ out of respect - she’s like one of the team!”

Even when requirements look obvious, they might not necessarily be a great indicator for how a system component should be designed. A developer's job is more than just solving what is in front of them; we must build something stable, concise and consistent, that can be adapted and grown over time. Below are a few personal tips for avoiding the pitfalls of over-engineering.

1. Fall in love with problems, not solutions

Fight those initial urges to jump into a build, and force yourself to take time and ask further questions.

2. Most problems have already been solved

Use what’s available and avoid reinventing the wheel - especially when you have to maintain it, write tests for it, and possibly even throw it out at a later date.

3. Try your hardest to remove ‘circumstance’ from requirements

Separate the variables from the constants, and think about the problem more generically*.

4. Always ask

Is the special case special enough? Diverging from common patterns and solutions may sometimes be necessary, but remember that today's 'unique' solution will be just plain odd when you're debugging it 6 months later. **

Most importantly...

Remember that your developer brain craves challenge and complexity, and will naturally draw you to it. Learn to kick yourself out of autopilot and challenge yourself to simplify whenever possible. To quote the renowned French writer, Antoine de Saint Exupéry: "perfection is reached not when there is nothing left to add, but when there is nothing left to take away".

* Contributing to open source projects that provide generic features (or building them yourself) is a great way to hone these skills.

** If you do find yourself going off-piste: document it! Your future you will thank you for it.