Image: iStockphoto/Rawpixel Ltd
Your code is bad. Really, really bad.
No, not because second-tier developers wrote it. You probably have great developers. Instead, the real problem is that your developers are stuck building new code on top of old code. Over and over and over again.
Ironically, this is a sign of success. But, it also creates problems.
As professor Zeynep Tufekci describes it, "We are building skyscraper favelas in code—in earthquake zones." While she's referring to the security vulnerabilities inherent in such code development, the problem is actually broader.
Big IT vendors get this. Startups...not so much. And this, perhaps more than anything else, illuminates why enterprises default to buying from their peers, rather than the "obviously better" super-cool new software from a super-cool new startup.
How broken is broken?
Enterprise IT is broken. Everyone knows this. But just how broken it is—and who is qualified to fix it—are up for discussion.
Chris Mahan, assistant vice president at Bank of America, details, "It's not just broken, it's like a thousand jigsaw puzzles all jumbled together with no hope of ever looking decent."
Or, as Neven Mrgan colorfully suggests, "Our 16-month old is yelling in anger at not being able to connect a Lego piece to a Duplo piece. Kid, enjoy your future career in computing."
Again, this isn't because some developer did a shoddy job. It's because successful enterprises stick around for a long time, acquiring companies and building up all sorts of technical debt in the process.
Software engineers do what they can, as fast as they can. Essentially, there is a lot of equivalent of "duct-tape" in the code, holding things together. If done right, that code will eventually be fixed, commented (explanations written up so the next programmer knows what the heck is up) and ported to systems built for the right scale — before there is a crisis.
How often does that get done? I wager that many wait to see if the system comes crashing down, necessitating the fix. By then, you are probably too big to go down for too long, so there's the temptation for more duct tape. And so on.
There is no easy way out of this, and startups that proclaim they have the answer simply aren't credible.
Fixing the problem
I should know. I spent most of my career working for those startups, raging against the big enterprise machine. Sometimes, I convinced enterprise buyers, but more often I didn't. Or, when I did, it wasn't me—it was my code.
Open source code, that is.
With open source, my customers didn't have to believe me, and they didn't have to buy from me. (Sadly, they usually didn't. That's the blessing and curse of open source.) Open source may well be the only real way for startups to effectively insert themselves into an enterprise IT conversation.
The reason is that open source communities can be bigger than any particular startup or company. And, if you're going to have a real chance at solving a crazy complicated enterprise IT problem, you must bring an army.
This is why mega-banks, retailers, etc. buy from mega IT vendors. It's not that they believe an IBM knows more than random Startup X. Instead, they opt to buy from a large enterprise software vendor because they're big enough to understand the problem, and to have the resources (and longevity) to tackle it.
This isn't to suggest there's not room to disrupt enterprise IT. There is. Just ask Amazon Web Services.
But, even cloud and open source aren't enough. AWS is hitting its stride in part because it increasingly looks and acts like the legacy vendors it's displacing. CIOs trust its scale. But CIOs are also placing big bets on Microsoft Azure, because it tells a great story of helping enterprises bridge the divide between the broken code they live in and the cloudy code of the future.
Few startups are going to get invited to that conversation. Those that will are likely going to need to rely on open source, and the communities that support it.