Our panel of Engineering Directors discussed the art of requirement gathering, avoiding over-engineering and managing complex development teams.
Below you’ll find a collection of highlights from the Webinar
For me, Over-engineering is doing something above and beyond what is required to solve the problem that you’re trying to solve. So the the obvious example that I pulled out is if you have a system, which is expecting 100 transactions a second, if you design and build a system that can handle 10,000 transactions a second, then you’ve over engineered that system for that problem. It doesn’t just need to be things such as scale, obviously, it can be putting in functionality that that wasn’t required to solve the problem, or whatever. And I guess the other thing is, why is over engineering a problem? Because naively, you could say, if I want 100 per second, then I built for 10,000. A second? Well, great, because I can easily do 100 per second. So I think the the thing we need to remember is that all engineering has an associated cost. Now I know the stuff you can do to make software, better quality, more scalable, more robust, that doesn’t cost much, if anything, but fundamentally, whenever you do some engineering, there is a cost. And if you end do more engineering than is required to solve the problem you’re spending cost over and above what was required to solve that problem. And for a business, obviously, a business has decided to build a product out a feature or whatever. They want to spend in certain terms as little as they need to in order to get that thing to market to maximise the return on investment for that.
Dan McNeil, Director of Engineering at ComplyAdvantage
There will always be people that will over engineer, perfectionist. We have some employee’s at Zoopla that do it almost in retaliation to the legacy code that they’ve inherited, you know, they inherited code that was so bad, that they feel they have no choice but to go ahead and over engineer stuff that was under engineered previously. But I think we as leaders have the opportunity to also create org structures around this problem. So if you if you read up on Conway’s Law, Conway’s law basically says that companies and teams will build software that look like the structure of their organisation. So if I have a front end team, an API team, service team and an infrastructure team, those groups of people will build a lot of whatever they’re responsible for, typically ending up in over engineering. And oftentimes, if we can, we can work against that by creating these cross functional teams, cross discipline teams, you know, think of the school Spotify squad model, for example. So that is one way to really think about combating over engineering from an org perspective or structure perspective.
Michael Zucker, Director of Engineering at Zoopla
One thing I found really helpful is adding a naysayer to meetings. So even even if they don’t necessarily disagree, just appointing someone as sort of the negative voice to argue against the point. It’s good to have someone just intentionally disagree play devil’s advocate to encourage a more well rounded discussion. be agile, no, upfront, you know, big no, no big upfront design. No big upfront architecture, you know, required in software mostly it’s, it’s different if you’re building computer chips or spaceships or cars, but in the majority of time in software, we can get away with large without large upfront designs. And I would say prioritisation of features just find a North Star, you know, whether you’re OKR based or North Star based you know, including multiple people in the prioritisation of that should prevent over engineering. And lastly, you fight Conway’s Law by creating these full stack teams set up around business goals rather than layers of the architecture.
Michael Zucker, Director of Engineering at Zoopla
my role as a director of engineering is to effectively educate and convince our stakeholders that we should plan less an estimate less. When we can unblock all that nonsense we can just let the teams go and do and learn and deliver in small increments. The way I’ve been doing that within my team has been setting OKRs that I can have engineering level. And a key focus for us is about how we deliver value as quickly as possible. And I think one of the things that we’re going through right now in the organisation is just to talk about a very high level as we accept and some forms of cryptocurrency and we want to add another one, which is effectively a completely different use case.
We’re evolving the architecture of the system in order to fit it to to accept acceptable currency – but that doesn’t mean we’ve over-engineered a system to begin with, we’re simply evolving it. It goes back to what both Dan and Michael are saying is do the right thing at the right time.
Malcolm Reid, Director of Engineering at the Workshop
