I remember our early production deployments at Bestmile, back in 2016. There were three main software components at the time. The “core” component — holding the seed of Bestmile’s Fleet Orchestration Platform; our homemade API Gateway — holding the plumbing around the core; and finally, the Dashboard web front-end.
This early version of the platform was not serving thousands of customers. Yet, the deployment felt uncomfortable. I remember these deployments for two reasons:
We had to do it “after hours”, when our main customers had parked and shut down their autonomous shuttles, which put the deployment in the middle of the afterwork-beer time.
We had to plan it carefully, and manually deploy each component individually in the right order, making it difficult to actually drink the beer.
These were the early days and since then, Bestmile’s platform grew beyond three components (30+ as of Q1 2020). While the complexity increased, Bestmile’s customers’ operations were growing in size and requirements:
Features — and bugs, sometimes — kept pouring in the product requirements.
Operations, driven by autonomous fleets and new business models that kept evolving and changing, brought new features.
New, bigger customers required more technical abilities and proofs, better performance, and shorter time to market.
Most importantly, there were soon to be no such things as “after hours” as businesses would run almost 24/7 around the world.
Continuous Development is one of those “non-functional” product requirements that are not visible, yet unavoidable to keep the platform running 24/7, while at the same time reducing the time for new features to come to life.
