CWDN series: DevEx - Kubecost: Going beyond commoditised value
This is a guest post for the Computer Weekly Developer Network written by Thomas Evans in his role as director of engineering at Kubecost, a solution for Kubernetes cost management.
Evans writes in full as follows…
As I see it, the equation for providing a winning developer experience is straightforward; it’s the execution that is tricky.
Technology vendors need to deliver products that include thorough and up-to-date documentation and their products need to work as expected. When my development team chooses an off-the-virtual-shelf piece of software, it’s because we don’t want to build something ourselves and because we don’t want any hassles.
We just want a product that works – and if it doesn’t, we’re pretty quick to toss it out and find something that will.
I’ll share a recent example. Just a few weeks ago, my team and I were working to explore new database management systems with the goal of reducing application response times. We identified three DBMS candidates, each offering us a roughly-the-same 100x performance improvement. However, we disqualified two within the first 24 hours of experimenting because their documentation wasn’t what we needed it to be and because the developer experience we were looking for just wasn’t there. My team of senior and staff-level engineers couldn’t get two of the solutions up and running, even with a full day of effort.
In contrast, going from zero-to-value with the one we chose (it was DuckDB) took us about an hour. The developer experience was that much more inviting and efficient — and that variable made choosing among these otherwise comparable solutions easy for us.
Going beyond commoditised value
So, now, today – given all we have said so far here – I would say, DX and time-to-value are the last great differentiators.
So, what’s going on here? Developer teams like mine that compare available vendor solutions for any given need increasingly find that the technology capabilities are a tied ballgame. That value is becoming commoditised [and remember, this commoditisation moment is the point at which a product or process can be essentially deemed to be identical to the same class of offering from a competitor], so we reached for three tools and they all did exactly what we needed them to do (they just had different paths of actually unlocking that value relative to our frustration), which is how things often work now.
There are also more options than ever.
The database industry, just to stick with my example from above, has come a long way from the olden days of Oracle or Sun Microsystems. Back then, of course, you only had a few choices and your market decision was based on how big of a cheque you’d have to cut. But now, teams like mine don’t really care which database we use out of the dozens of roughly-similar options out there. We only care about how quickly we can deliver and iterate customer-facing applications. The tool with the best developer experience and the fastest time-to-value will win every single time.
The 75%-25% rule
For any developer or development team, I’d gauge that DX and time-to-value hold a 75% sway on decision-making.
Most developers will come to the same conclusions about vendor tools from those perspectives. The other 25% in that equation comes down to personal preferences and philosophies. For individuals who want tools that cater to their specific ideas of how they should operate, those nuances are satisfied by more flexible and tweakable solutions. A good database technology example is Postgres: it works great off the shelf from a DX and time-to-value standpoint and offers all the tweakability you could want for those developers who find that important.
The success of emerging technologies that offer shiny new DX tooling highly depends on that 75%-25% rule.
In general, opinions on particular technologies in areas such as AI/ML, low-code/no-code and other automation tooling will depend on the individual developer you’re asking. But every developer will be drawn to tools that deliver results. In AI/ML, for example, the big question is how fast you can develop an effective AI model.
Developers will have nuances they look for, but when Google has a tool that offers pre-trained AI models and lets a team have what they need up and running in 15 minutes, that’s going to win every time. The low-code/no-code arena is the same story: platforms that offer truly transformative DX and time-to-value advantages will lead any conversation about worthy candidates and more subtle preferences will finish it.
A challenge to technology vendors
Maybe this oversimplifies it slightly, but selecting a tool for a developer experience strategy isn’t much different from purchasing any consumer-facing product. When you buy a TV off the shelf, you want it to work and you want a good interface where you don’t have to click a hundred buttons just to watch Netflix. Success is simple if you make it simple.
I want to issue a challenge (or maybe it’s a polite plea) to technology vendors: when you build tools, build for the developers that use them. Remember that developers want clean experiences and tools that just work. Whatever the tweaking and configurability included, there’s no excuse for tools that take days to even get up and running.
Where we still see the biggest gaps in DX quality is with vendors that think they own some special IP. For example, while at a previous company, I once struggled with configuring a (large) managed Kubernetes service for a year…before implementing OpenShift and having it humming along within a week. The difference was that our developers could simply run the script and it worked.
Vendors would do well to task their own development teams with creating solutions that they themselves would like to use. This is especially true as vendors increasingly compete on a commoditised landscape, where DX and time-to-value are fast becoming one of (if not the) most differentiated values that vendors can compete on.
Thomas Evans, director of engineering at Kubecost: Don’t get left out the cold by commoditised engineering value, stay warmer and closer to positive DX and time-to-value.
