Stand On the Shoulders of Giants or Fall in Their Footsteps?

The first-mover advantage is much touted in the technology press. After all, you won't really see much benefit to being the second car insurance company that makes a sitcom about cavemen. But in technology, being first to market only works when that first enables a new business. On other occasions, following the pioneers can enable others to move faster than the pioneers.

All My Heroes Were the First to Release New Products

With a long enough temporal distance it's easy to remember iPods, Nintendo Entertainment Systems, or even Heroku as 'the first thing like that to appear' when all of these are actually beneficiaries of second mover advantage.

Here I have the extreme pleasure to acquaint you with the MacRumors forum thread from 2001 when Apple fans decried the iPod as just another mp3 player with 'no more features than my Rio Diamond Jukebox.' Sadly while writing this article I could not find a way to work in the fact that Steve Job's presentation stack for the first iPod is typeset in Comic Sans.

In short, first movers, even those who have a successful product launch, offer a 'free ride' to their competitors who can use the first movers' market research, product design, and advertising. If parts of the market don't respond to the first product, a second-mover can offer a new product that, along with improvements, addresses the market better.

How do these differences shake out in the technical field? When we're not talking about marketing a product to a group but rather the engineering, the process is extremely different when you're not breaking new ground.

And how, fundamentally, is the development process different? Can we stand on the shoulders of giants? Or will we get bogged down in a landscape already riddled with giant's footprints? What are the pitfalls of going second?

Follow the giants' map.

When Walmart Labs took up NodeJS when it was an open source darling with a few un-formatted websites proudly proclaiming its benefits. When the team documented their path to success it largely recapped a framework's path to mainstream success.

• Patching core modules to support interoperability with other frameworks - when node core HTTP was converting everything to lowercase and the existing Java framework expected custom headers in uppercase, a patch was the only solution. When you are trying to roll out a new open source tool in your enterprise, you won't be able to wait for your Github issue to get upvotes. Like it or not you will end up either forking or patching core.
• Implement procrustean resource imports - I want security updates and bug fixes as much as the next gal, so the inbuilt Semantic Versioning (semver) support in npm is perfect for me. But in enterprise, we need to know that rollouts are identical, to the bit, with what we did last week. That means we want to lock our packaging to an exact version of a module. There are a ton of ways to do this in npm now but all of this was stuff Walmart Labs had to work out on their own.
• Onboarding - How long does it take to go from 'tinkerer' to 'competent'? I've been writing C for the Arduino for for 4 years and I'm just above a beginner. Focused self-directed study might only take a few months, but onboarding in an enterprise shop is a matter of weeks. Again, in the early days of a framework you may end up drafting internal documents rather than forcing new devs to sift through mountains of repo documentation, blog posts, and Stack Overflow questions to get up to speed.

Enterprise features and tools are not automatic.

In these examples Node was 100 percent working it had no bugs or fundamental flaws. All of the missing pieces were ones that you only need if you are working in an enterprise environment. The clever engineers who built node didn't 'forget' these parts, but using Node to make money required them!

Blazing a trail even if you're using AWS

iRobot dived feet-first into serverless architecture to run countless IoT devices, and while this has come with some great successes it can lead to some odd moments! In articles like this one Ben Kehoe of iRobot tries to be the first one to wrap his mind around the new AWS Fargate, and how it changes the map for iRobot.

Even without facing road bumps with a new project, keeping up with bleeding-edge features means your team might change directions after every re:Invent conference. Occasionally it means that a service that you thought was an expansion of serverless is more like automatically managed containers.

Rewrite your queries to serve customers better, not to save RAM.

Being the second mover in a managed environment means that both performance issues and enterprise requirements should be solved for the majority of cases. The examples above are all about making your team and the code work, none of them involve real business problems.

What if all our bugs could be business focused? Rather than trying to optimize queries for memory use, you were optimizing sorting, providing more relevant results, or adding metadata to power cool new features?

The power of serverless, a highly managed environment where operations can focus on observing real performance, is to allow your developers to spend less time optimizing within frameworks and more time understanding your business needs.

...and Stackery Can Help

Stackery, a tool for creating serverless stacks, makes it easy for teams to collaborate on AWS resources and configuration. With tools to let your whole team modify and approve changes to your stack, it has the potential to let you stick to best practices as you roll out services for your customers. AWS CloudFormation has an open source standard for describing and deploying stacks Serverless Application Model (SAM) YAML, which Stackery automatically creates, making it easier to learn the standard.

Move Slow and Make Things

Did you ever hear the one about two friends who come upon a bear in the woods, and one man sits down to tie his shoes? "What are you doing?" says the other man, "shoes or no you can't outrun a bear." The first man finishes lacing up and says "I don't need to outrun the bear, I just need to outrun you."

If the message of this piece is 'move slow' it should really be 'move a bit slower than the competition.'

If you are breaking new territory, plan the time you'll need for enterprise features and documentation, and if you really want to deny your competitors second-mover advantage, keep tight-lipped about best practices and cancel your senior devs' speaking schedule!