“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.
Today’s column is written by Vladimir Klimontovich, CTO and co-founder at GetIntent.
The programmatic industry is suffering from a crisis. The ad tech IPO market is lukewarm, and big companies are struggling to raise new VC funding or break even. Corporate valuations are declining. This doesn’t exactly mean that something is genetically wrong with ad tech and programmatic; every young industry goes through several stages of natural growth.
The key to success in the future is to learn from the recent mistakes of the industry. I can clearly point out one problem: overengineering. Overengineering is the “designing of a product to be stronger or more complicated than necessary for its application,” according to Wikipedia. It burdens technology in terms of cost, size and complexity. The industry is making processes more difficult than they realistically need to be.
This issue concerns not only the ad tech industry. It happens with every industry largely overfed with venture capital money.
Potential Consequences
Overengineering is not an engineering failure but a management one. For this reason, management actions should be undertaken to deal with it.
Consider this real-life example.
A well-respected company uses a cluster of 1,000 servers to process data with coding that’s a bit off. Poor design decisions and bad coding led the company to use so many servers. Instead of trying to find the solution from the bottom up by checking the design, the company hired an additional team from a cheap offshore development company to manage the servers. Despite these efforts, the cluster at times would crash completely. Finally, the company decided to create one extra cluster with 1,000 new servers for backup in another city. It was a solution, but it didn’t solve the original problem and ended up doubling costs.
Non-tech execs tend to think that the cost of software feature development should be measured by the salary of the engineers working on a particular feature. But the costs also include the future maintenance. Maintenance can complicate or slow the development of future features, sometimes infinitely multiplying the cost.
Another cause of overengineering: the industry obsession with big data, rooted in the belief that every bit of information should be kept and processed with complicated and expensive tools. The result is high costs of every imprint, as well as greater margin for ad tech companies.
But the truth is that average programmatic impression is fairly cheap and the key to success is to make data “smart,” not necessarily “big.” Not every bit of information is worth storing, and the question is, “Which information is?”
Another popular obsession is known as “high load.” Many companies start to use new and exciting technologies such as Node.js or Scala, which promise to handle “high load” at zero costs. While many of those new technologies are good, there are very few engineers who can deploy them properly. As a result, in the best-case scenario, people are stuck delaying new features or hiring inexperienced or unqualified engineers to produce a lot of messy code. All these things reduce the benefits of technology.
Why Does It Happen?
CTOs are usually under pressure from investors, boards of directors and other C-level executives. Sometimes, CEOs force them to spend new investments faster and, as a result, they start hiring without fully considering the experience of potential candidates.
The main obstacle for any tech company growth is the speed of hiring developers. But it’s better to grow more slowly.
“[W]hen schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster,” Frederick Brooks brilliantly wrote in his iconic book, “The Mythical Man-Month.”
Commoditization
Five years ago, at the dawn of programmatic, solutions, and especially bidders, were like exclusive Formula 1 cars. Today, tech people and engineers still want to build only Formula 1 cars, when the market really just wants a new Toyota.
The bidders, as a core part of demand-side platform technology, are being commoditized and the engineering is taking the same route. I won’t say that programmatic is becoming an easy tech industry, like website development. You can’t go live without being able to process hundreds of thousands of requests per second very quickly and digest high volumes of behavioral data.
But a bidder is not a Formula 1 car anymore; it is more like a Toyota Corolla. The focus should be shifted from going as fast as possible under precise technical supervision to working as reliably as possible with minimal engineering.
The Economics Of Overengineering
Many believe that all coding work should be allocated to capital expenditures. With well-designed software, that is the case. But sometimes code produced after bad architectural design decisions can have a negative impact on capitalization.
For example, let’s say five engineers worked on a new feature over six months before releasing the feature for production. But the feature was overengineered, requiring a lot of pricey servers to run. It also kept the five engineers busy maintaining it half the time. But the feature ended up bringing on board only a few small clients, barely covering the server costs.
So the company starts to lose money – a potentially infinite amount of money, unless somebody makes the tough decision to discontinue the feature, which usually happens too late in real life.
What’s The Solution?
The Toyota Corolla is a great engineering solution. It’s not about speed but efficiency and getting consumers from point A to point B in a cheap, safe and comfortable way. Selling Corollas is a much more profitable business compared to Formula 1 car development because the market capacity for Toyotas is significantly larger.
There is no need to reinvent the wheel. If you are not the expert in the ad tech field, the best solution is to license technologies from market experts or hire an experienced team of developers.
CTOs should not be pressured by CEOs and boards to spend investments quickly. CTOs should be allowed to focus on a project and decide what is the most efficient way to deploy a certain feature within a given time frame.
Developers should also understand that building a C-class car is not a less difficult or honorable task. It’s a vehicle that can change the way of life for thousands of people – not dozens. Driving 220 miles per hour is quite stunning, but very uncomfortable for day-to-day driving.
Follow GetIntent (@GetIntentCom) and AdExchanger (@adexchanger) on Twitter.
