Continuing with the idea of knowing the context of our software as the first step to making better decisions (see it depends blogpost). I will explain in this post a software classification that I found very useful.
This software classification was created/defined by Jocelyn Goldfein in the article http://firstround.com/review/the-right-way-to-ship-software/ and explained at The "right" way to ship software Jocelyn Goldfein - hack.summit 2016.
The presentation's core message is that there is no single "right" way to ship software, as every release process optimizes for different goals and involves trade-offs. The optimal approach is situational, determined by a company's technology stack/deployment model and business model/mission, requiring a flexible and adaptable mindset rather than adherence to a "religious" belief about one methodology.
The model classifies an application in two axes:
- Horizontal axis: Technology stack and deployment model. From very costly to deploy (on-premise, operating systems, embedded software, etc.) to easy to deploy (web application in a cloud PaaS).
- Vertical axis: Business model and customer type. From costly enterprise-critical software to free consumer apps.
This classification helps define the cost of making a mistake, the optimal release process, how to gather feedback, and more.
For instance:
- Web/cloud deployment allows rapid iteration and testing. Bugs are easier to fix, enabling a more risk-seeking approach ("move fast and break things").
- On-prem or device deployments are slower and riskier. Bugs are expensive to fix and may severely disrupt customer operations, thus requiring more conservative, predictable processes.
- Enterprise-grade software often requires predictability over speed. Customers need to plan around releases.
- Consumer-facing software benefits from great UX and fast experimentation cycles. New features can be introduced continuously without prior scheduling.
Beta programs are an especially effective tool across all quadrants: they allow for frequent shipping and direct feedback from users who are willing to tolerate early-stage issues in exchange for access and influence.
Changing release processes is hard, because it usually demands culture change. Engineers tend to become attached to the processes that worked for them in the past, even if the current context requires a different approach. This can lead to internal conflict, especially when companies pivot from one quadrant (e.g., web) to another (e.g., mobile). To navigate this, teams should align on shared values and mission. Processes are negotiable; purpose is not.
When hiring, prioritize learning mindset over specific methodologies. New hires should understand the current context to avoid blindly applying processes that made sense elsewhere but may not fit now.
I found this classification very useful for my day to day work. But remember, the context can be different for each part of a large system and also evolve with time.
According to this classification, these are the systems in which I have been involved:
Thank you, Jocelyn Goldfein, for this useful classification model.
References:
