Don’t Be Innovative. KISS or Die.

I have spent a lot of my career in startup software companies, but only about half of them were really startups when I joined, with the rest being in some state of trying to become “post-startup”. Startups succeed on speed and ability to respond to change, and this necessarily leaves a lot of half-baked and unsuccessful ideas, usually still in production — there’s no value in spending time cleaning up when the likely outcome of all startups is failure. Innovate or die.

However I have seen many “post-startup” companies now, and spent a lot of my career in several companies working on transforming the few good ideas that the market embraced from hack-ware to software. This is not a criticism — it’s just a reality of how our business works! I opened the doors of a couple of startups, and wrote my share of hack-ware.

Startups have a concept that’s new, in one way or another, and this is what differentiates them. And if it doesn’t, they “pivot” to a similar concept, repeating until there’s a market, or not. It seems self-evident that everything the whole company does should be towards this goal. But it’s not. There’s an interesting phenomenon I have noticed: developers like to be innovative as well. Don’t do it! KISS or die.

At a startup, innovating how to build software is wrong. Embracing the most obviously correct and cutting-edge technologies is wrong. The only thing that’s right is spending all effort and time focused on finding an implementation of that concept, or the various pivots of it, that the market embraces.

And yet, nearly all of the companies I have joined in their attempts to become “post-startup” have had technical innovations, often internally developed, that eschew the boring, accepted, market-proven ways to build, release, and deploy software. This is wrong — it’s the hubris of the developers to assume their job is also to be creators. It’s not: it’s to further the singular aim of the startup.

A company I worked at embraced micro-services, deployed on Kubernetes, in the cloud, using ruby as a core development language, starting in around 2015. It’s arguable that micro-services and Kubernetes were right, at the time, but if you choose the micro-services, Kubernetes deployed on the cloud is reasonable. Just follow the established patterns. Each of these was solidly in the “not new, but clearly growing” category. What was different, though, was the choice to not use Ruby on Rails (RoR), and instead use Sinatra.

There’s no doubt that in 2015 Rails had lost a fair amount of its luster, with many companies (including the one I was with then) struggling to do a version upgrade from 2 to 3. It was kind of a shit-show. Yet Sinatra, while it had its acolytes, was far from well-accepted — people were hating on Rails, but it’s where almost all ruby development was being done. Yet my former company chose Sinatra, along with the other new things. And for a time, actually several times so far, they succeeded in the market.

The choice of Sinatra, coupled with Micro-services, Kubernetes, Cloud (AWS) left a rather smaller potential employee pool than would have been available with older and more boring tech. And it’s true, I would have had less interest in joining the company with boring tech.

Last week, I joined a company steeped fully in boring tech. As I dance my way through yesteryear I am finding all the old, tried and true ways of doing things: single app deployed on a small cluster of servers, with a single database, using Rails 5 on ruby 2.7.6. And I need to understand this system quickly, as a new developer. Mostly, all I need is Stack Overflow, to either remind me, so I can know how a thing works — took me a little while to understand the newer asset-pipeline of Rails 5, since the last I had worked with was Rails 4.

Incremental learning is far easier than whole-cloth learning, though. So I spent a few cycles figuring out what was wrong, learning what the options were and how they had been implemented. After a couple days of struggles, I had it all working, just like the online doc said.

When I started at my previous company, I assumed that my extended ruby skills and learned patterns would make that part of my new job easier. But it didn’t — in each of the key systems we used, we had specialized versions and methods of doing things. Sinatra doesn’t work like Rails, just like a very thin layer of Rails. While patterns had been mimicked, they were not the same. Documentation was thin, and almost none of the Stack Overflow answers applies to how we did things.

I spent my first several years there allegedly building infrastructure, but in truth a lot of that was supporting our developers, old and new, in how to understand and build apps in our very innovative environment. These were some of the most talented and experienced engineers I had worked with for a while, but almost to a person, we were all exasperated by how nothing worked like it said in the manual. It was all very much more clever. Our engineers could sometimes make significant and amazing changes to our software in a morning, and then spend the next three days getting all the bespoke configuration required worked out.

That’s the point: a startup needs to move as fast as possible and realize a single vision by delivering software fast. There are occasionally cases where such companies actually need to create some brand new technical component, or library, but that is far less frequent than I have seen over my career. My former innovative company hired me after beginning to recover from a COVID-induced layoff, and tried to hire enough engineers to overwhelm our innovative platform with sheer force. And yet, as of my departure core applications were running versions of ruby that had been EOL for years, and only after several years of intense effort had finally been able to upgrade their K8S infra to a current version. Product managers said “engineering takes too long” (as they so often do) but in this case: right.

Side note: some of the most talented and capable employees were laid off recently from my former employer recently (including me, but I have a new job now). If you know of anyone hiring, here are just a few of us.

So don’t try to innovate on too many levels. KISS. Or die.