Software Delivery in Small Batches

Inflection Points
Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode I share a small batch of software delivery education. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
I’d like discuss crucial moments in a system’s history. These moments repeat across time, teams, and architectures. They are pivotal moments that may lead to success or kick-off death spirals.
These moments present asymmetric risks. Good decisions maintain or moderately improve the status-quo. Constant good decisions accumulate as long term improvements. On the other hand, bad decisions may make go wrong quickly or plants the seeds of inevitable destruction.
My aim with episode it so share some inflections points I’ve encountered, so that you’re better equipped to perceive them and ultimately navigate them.
One common inflection point is going from one service to two services. This is what I call the "1 to N" problem. Moving to a distributed system requires adherence to architectural and organization boundaries. Properly introducing the second services can scale an organization by removing bottlenecks. Improperly introducing a second service can create new technical and organizational bottlenecks.
Another variant of the this inflection points comes when existing systems need to be connected a third party "business intelligence" tool. Does this happen by creating new database credentials then connecting directly to the database? Does this happen by creating new capabilities and APIs to support the new use case?
Astute listeners will realize this is practically the same inflection point. Teams mistake it because it feels like the third party tool isn’t "a new service". The only difference is who is writing the software. The boundaries are still the same.
Inflection points are not just technical. They’re also organizational. Inflection points come when organizations scale by introducing new teams or splitting the existing ones. Are the new teams congruent with the technical architecture? Or, are those teams at odds with the underlying structure? Are those teams staffed enough to actually succeed? Or are they so-called "full stack" teams that must depends on others to actually ship anything?
Inflection points also appear in innocuous choices. Consider a small system with a fancy Javascript frontend and a GraphQL backend. Naturally these are two separate systems. The frontend engineers want to quickly iterate on their codebase on their own machines. So what happens next? Do they just clone the backend repo, start it, then connect it the frontend? Or do they use fakes and mocks instead?
These may not seem like trivial decisions but they are important because the results compound. Unfortunately, the bad decisions compound faster than the good ones.
In the last example, choosing to run one dependency implicitly means running its dependencies and so on. This establishes the precedent that just run everything when a new service is added. That’s how the decisions compound. Eventually, you’ll end up with engineers trying to run a dozen different things to do the basic work.
There are common themes in these inflection points. One side of the inflection point leads to less coupling, strong boundaries, and fewer constraints. The other side violates boundaries, encourages coupling, or introduces new constraints to the system. The latter should be avoided, especially if they’re deemed "short term solutions". There’s nothing more permanent than a "short term" solution as the saying goes.
Alright, that’s all this batch. I recommend you listen to some of my past interviews to further explore these ideas. The first is my conversation with Derek Comartin on boundaries. The second is my conversation with Bryan Finster on development environments. Find links to both episodes at SmallBatches.fm/68
I hope to have you back again for the next episode. Until then, happy shipping.