Engineers are known for wanting to do things the hard way. We prefer building things from scratch, even if 90% of the technology we need already exists. We like pushing boundaries. And we’re drawn instinctively to complexity. It’s like we think of the complexity of a given problem as a proxy for how much mental weight we’re capable of moving. That drive, however — to show off, to impress our colleagues with our mental strength — is what holds so many engineers back. exactly See, complexity breeds more complexity. The more parts a product has (and the more complex and custom those parts are), the harder and costlier every production activity around that product becomes. More complexity means more development time, more testing, more maintenance, more documentation, and more ramp-up hours needed for anyone new who will be joining your team. Complexity is a lot easier to add than it is to remove, and as result, many complex products quickly become too complicated for their users and their developers. The costliest mistake of engineering is over-engineering your product. I’m guilty of this, but I’m also familiar with coaching for it as a former , co-founder, and as a former head of studio at . And over the years, here’s what I’ve learned: what engineers be focusing on is not complexity or scale, but rather . engineer Glu Mobile should speed and simplicity There are a few key principles that engineers learn back in that are worth resurfacing, since many of us forget to follow them in real life: Design for Manufacturing 101 The reduction of the number of parts in a product is probably the best opportunity for reducing its overall costs. Reduce the total number of parts. Standard, or pre-made components, can usually get you up and running faster and cheaper, and you’ll have a bigger community of specialists who can help you should you encounter problems. Use standard components where possible. You don’t want errors in one small part of your system to crash your entire product. This requires discipline and good communication across your entire team. Maximize compliance and fault-tolerance. In the end, the easier our tools, games, and apps are to use and understand, the better for everybody — our team members and consumers alike. Here’s why. Users don’t care how much work went into a given product. The only thing users care about is how easy your app or game is to play. They care about the experience of the interaction. They care about what’s happening underneath — and, as long as things continue to work, we shouldn’t either. don’t If we spend too much time obsessing over the engineering minutiae (which only other engineers care about), we risk wasting time and money. The first company my co-founder, Alex, and I started, for example, was called TrackingSocial, a social media analytics . I was responsible for designing our data ingestion pipeline and our analytics products. And I remember being absolutely convinced that to truly impress our potential clients, the platform needed to be fully functional and dynamic to show off our engineering muscle. We dedicated to it and delayed demos to make sure that what we were building met that high bar. platform months Ultimately, however, clients preferred reviewing our static UI/UX mockups for demos. And to top it off, many of those potential clients who finished reviewing those mockups ended up wanting something different than what we’d built. The lesson? Before you build, put yourself in your users’ shoes, or even your investors’ shoes. We would have been better off testing our mockups at the outset to confirm that what we were building was what people wanted. This lesson sounds corny, and has been said a lot before, but it’s true. much Complexity compounds. Of course, over-engineering can have internal repercussions, too. When even aspect or component of your software becomes overly complex or time-consuming, it can spread and affect the whole system. one easily It makes it harder to ramp up new engineers to work on any of your complex components. In turn, testing, monitoring, and maintenance of these things becomes harder, as well. And if this goes on long enough, your company may evolve into a culture of complexity — one where engineers will want to show off how complex of a problem they can tackle in front of everyone else on the team. This is something I saw a lot of while working at Microsoft, and I’m sure it happens at many other tech companies, too. Any benefits of the initial complexity quickly erode into wasted time and money. So as founders, this is something you avoid. must The reason? Over-engineering is bad for business. This is pretty simple. Overly complex products are expensive, time consuming, ineffective, as most of the time they’re not what users want. and That’s why it’s up to the team leads and company founders to check their engineers’ propensity for over-engineering, and instead push their people to prove out their assumptions with simpler, more effective tech. At Dairy Free Games — the company Alex and I sold to Glu — I learned this the hard way. We were convinced, early on, that the prototype server infrastructure we’d built wouldn’t be able to handle a large enough influx of users for our beta testing. So we tried to strengthen it and improve the load-handling by . This, of course, required tons of time and resources, and in the end, predictably, we found that our initial server was more than enough for what we needed at the time. nearly 1000x Here’s the thing: this mistake stemmed not just from a strategic error, but from our personal attraction to complexity, and the thought that bigger and more complex is always better. And , ultimately, is what holds engineers back. that The solution? Force yourself, always, to focus instead on keeping things simple. Prove your assumptions out using the simplest, fastest, and most standard ways possible before investing heavily in any unnecessary complexity.
