How the Enterprise Adopts the New Stack, or “I Said No, Dammit”

Here’s the typical enterprise stack adoption cycle:

1. Year 1: The way we do things is great; all that crap that startups are doing is basically just the same as what we do, but obviously we’re better.
2. Year 2: That stuff that startups are doing works for them, but it wouldn’t work for us because we have different requirements.
3. Year 3: If we were starting from scratch, we’d do it the way the startups do, but we aren’t, and we have different requirements.
4. Year 4: Yeah, OK, we should probably do a pilot project to see if we can do that new thing that the startups are doing.
5. Year 5: Ok, yeah, actually, it is pretty good. We’re going to do it everywhere and be awesome again. We are embarking on a two-year plan to apply that startup stuff everywhere. It will be expensive, but it’s the right thing, and then we’ll really be set.
6. Year 8: OK, so it took us three and a half years instead of two, but we’re finally done!
7. Go to step one.

That’s not a continuous improvement cycle — it’s a capital improvement cycle. But the best-practices stack is changing so rapidly that you can’t be on a capital improvement cycle. You need to be fundamentally changing the way that you do things so that you can take advantage of new technologies in the first two to three years of them being out, not in year eight or nine. And the cycles are shortening, so the differentials are just going to get worse.

The Stack is Always Changing

And I don’t just mean the specific components of the stack, but also what things you need to constitute a stack. It used to be fine to talk about the “LAMP” (Linux/Apache/MySQL/PHP or Perl) stack, but given cloud-native architectures (servers are software! run what you build!), we now end up bringing DevOps into the stack, so we need to know which configuration management or PaaS or container technology you’re using, and what continuous integration and deployment tools you’re using, and on and on.

The stack is changing so fast that it’s very hard to keep up — every 18 months or so, some part of your stack is almost certainly objectively inferior to what’s available. It’s very hard to know when you should change your stack, although if your stack has looked the same for a long time (Eighteen months? Three years? Five years?), it’s probably not the stack that the most effective developers today would use to build your stuff. While I agree with Dan McKinley that boring technology is effective, that rationale can be used to defend using Java, .NET, and Ruby-on-Rails as defaults today, and they certainly should not be. (Oh, are you getting defensive? Sounds like you’ve been too busy developing and not busy enough trying new things over the past five years).

Why does the stack change so constantly? The main reason is that what we are being asked to deliver is changing so constantly: Led by the massive rise in smartphones and in consumer startups investing so heavily in user experience, the bar keeps going up in terms of usability and availability. We picked Ruby on Rails eight years ago because it gave our developers an easy way to separate data and design (MVC FTW!). But RoR does MVC on the server side, which means that every new piece of content is designed to be delivered through a new page load in a browser. That’s not the single-page-app world that consumers increasingly prefer (e.g., Microsoft Office 365 following Gmail).

Smartphones have driven even bigger changes into the stack than SPAs, as evidenced by Yo!, a fairly popular app that has a full stack of Parse with Objective C. Try to compete with Yo!’s developers for speed or UX with Java or .NET and the many, many things you’ll have to bring along with you.

Let’s run through some examples:

Where is the (backend) code and database running?

How are you Ensuring High Availability?

How are you deploying the server code?

The stack also changes because developers keep releasing languages, tools, environments, and modules that make software development more enjoyable (e.g., Jade instead of editing HTML directly, CoffeeScript/TypeScript instead of editing JavaScript directly). And given the overall demand for software developers, we have an ever-increasing number of people learning how to develop software without any experience with any existing languages, tools, or environments. So those new developers gravitate toward the best of what’s new, which means that if you want to hire them, you’re going to be best off if you can support their preferred stack. So if you’re hiring Java developers today, I’m sorry to tell you, but you’re not getting developers who care or think about continuous improvement (at least not holistically).

This is not to say that you can endorse some kind of chaos of having every developer pick whatever stack they want and go — that will end in disaster. But it does mean that you can’t think about selecting a stack as a capital investment that will pay dividends for years (you’d be assuming that your stack selection can be capitalized, but it shouldn’t have a life long enough to capitalize). Instead, you need to be constantly evaluating your stack, and you should have processes in place to make it easier to update your stack on a regular and ongoing basis.

And beware existing and potential future employees who have technology names in their titles! Guess which language a Java Architect is going to pick for her next project? Guess which database an Oracle DBA is going to pick for his next project? Hire for the technology, not the product or brand, and hire for the people who understand that the stack is always changing.

Image source: Enterprise IT Adoption Cycle by Simon Wardley.

Feature image: “Drive Slow” by smlp.co.uk is licensed under CC BY 2.0.

Joe Emison is Chief Information Officer at Xceligent, a leading provider of commercial real estate information across the United States. Joe is a serial technical entrepreneur, most recently founding BuildFax in 2008, and has consulted with many other companies on...

Read more from Joe Emison