“Choose any two: quality, time, or features” is old age wisdom of software project planning. This rule of thumb makes for lively discussions, and used to advantage by many an engineering leader.
Lets start with definitions first:
- Quality refers to known and unknown bugs that lie in the released features. Typically enterprises have SDETs (Software development engineer in test) who help craft a test plan, feature coverage, and regression scenarios to guard against unwanted side effects. This is the primary self defense against loss of availability and data loss for users using the new software.
- Time refers to meeting a tight deadline. This is mostly to keep users and customers engaged on the innovations planned by the organization, and keeps the pressure on in engineering.
- Features are discrete new or significant revision of existing capabilities. This is different than performing small, targeted bug or security fixes.
On surface, the rule is sound. That is, if we want to release significant software features with high quality, it can take more time. Or if we want to release significant features on a given day, the software can be buggy, as there may be no time left for testing and hardening the software.
Software as a service
However, this situation changes with software services model. By definition, software services are:
- Modular in the sense that they coexist along with other services as well, and are
- Hosted by the provider, and consumed by users over the internet
In this particular situation, I argue that we can have our cake and eat it too. That is, within reason, we can release significant features on time and with high quality.
Sound engineering investments and practices
It is also true, there is never any free lunch. Here are some upfront investments that the engineering team needs to be on top of:
- Continuous integration: With git, github, bitbucket etc. being
widely available, almost all engineering shops now have capability
to:
- perform small fixes
- collaborate in code reviews
- merge code patches to upstream versions
- Continuous deployment: change the hosted version of service on demand. This is a critical capability, as it allows engineering teams to perform version upgrades and downgrades with minimum of disruptions to users.
- Periodic iterative development: engineering teams deliver software
in periodic increments (typically every 2 weeks), which allow for:
- tight feedback loops from users
- confidence in incremental delivery
The following aren’t strictly necessary, but do help:
- An architecture that builds upon the modular software service model to ensure new changes have limited impact to existing functionality. In practice, this translates to using and composing based on libraries and or packages.
- Automated rollback capability. If the team has good understanding of their service level indicators and objectives, then they can invest time and effort into performing automated version downgrade of the service.
New rule: discuss scope, not quality or dates
- Time: new features are released incrementally, and periodically. Organizations can announce when all related features come together.
- Quality: there is tight control on quality due to capability developed to upgrade and downgrade software versions at will.
- Scope: track engineering team “velocity” to understand how much complexity a set of teams can deliver in what amount of time.