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.
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?
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.
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!
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.
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.
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.
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!