The Infinite Software Release

Software Versions

Software is living and breathing, it is something that is continually changing with “the times”, to be successful over time you must continually be iterating and updating software, working to create the best experience for your end user. Software shouldn’t be stagnant.

Many vendors in the software industry are fighting with “The Innovator’s Dilemma“, where the company has not moved to building software in fast iterative cycles. The best way to create a nimble release cycle culture in your company is to have your software created and maintained in the cloud. For vendors pre-cloud movement, it is hard for them to move to a cloud software and to Software as a Service (SaaS) models when customers are paying for older software that is working right now for them. What will justify the moved to the cloud when the customer paid large sums of money for software that is working for them. Overtime, non-cloud base software will become stagnant, it is a struggle to keep all of your users up to date.

The risk of doing large software releases in the worst case scenario; when a large software update is released, users reject it and don’t use the software at all. There is also the risk that a large software update takes to long and the software is delayed to a point where the application is “stale” altogether or never released.

The Infinite Software Release

Have you ever heard of the “infinite release cycle”? The goal is to release often allowing continuous small daily, weekly or monthly incremental changes to software. Doing large/major version releases of software every year slows down developers from moving fast and getting input. A large software release benefit’s marketing the product, the product queues up for launch and gives the marketing team something big to announce, but doing so slows down getting the product out to market for real users to take advantage of getting feedback.

For example, the drchrono iPad and Web EHR is a continual work in progress, starting January 2009 and we have been on an “infinite release cycle”, pushing code to quickly, not releasing yearly or monthly but daily or close to daily. Within a given year, we have released at least 100 to 400+ versions of drchrono, that is how we are making the drchrono platform better and better at a rapid pace.
Look at the graph below at how infinite release cycles can change the customer experience and feedback loop. The green line represents a company that is on a yearly release cycle, great for marketing and launching a product right out of the gate will tons of features, but this is sometimes bad. Customers don’t have a chance to help you refine and give input the software. The blue line represents the quarterly release cycle, it is a better then yearly releases, allowing customers a chance to give feedback and learn about software in increments. With an infinite release cycle, customers can learn the product as it comes out and as enhancements come out, the learning curve is less drastic. Fast release cycles provide quick feedback loops to be able to make changes fast for refinement. Do you think it would be easy to do this if you are building for a year in an insular environment, then realizing a customer wants a major change? It is much harder to make a major refinement if a years worth of work is complex to change, which happens often.

Software Reversibility

Version 0 of drchrono

Version “day 1”, year 2009. drchrono iPad EHR.

In a new world of cloud-based apps and services, rolling out software in the past was episodic. Now things are moving to an almost continuous release cycle, happening fast. In today’s environment aren’t products “done” like they used to be, they can’t be. Do you recall the days of software on DVD and CD? You can’t just ship a DVD with software on it and call it a day anymore. The focus has shifted to pushing code and having the capacity for reversibility. You need to build software in real-time so you can iterate fast but also build fail-safes in place so if there is an issue, the software can be fixed it before users notice it. Reversibility is very important if you’re rolling new software out that is broken. It must be tested, one great company that does testing is Rain Forest, they have an on demand Uber-like service for quality assurance (QA) testing. As part of the deployment cycle, you need to test and talk to customers, showing them the new software, react to feedback and iterate.

Move Fast and Release Often

Track Metrics

A critical metric to track is how long did a cycle take and what can you do to make the next cycle faster?

Be sure to track after a developer writes code and committed to run the unit test and then how fast the code gets into production. If you can get the code out into production in 15 minutes from a change in code base out to users allows faster iteration and feedback.

  • After developer code is written and committed track these
    • Time after code was written, track how long until a unit test is run
    • Time after code was written, how fast the code gets into production

If you don’t track that metric, release cycles will generally get slower and slower.

Many startups start moving fast and naturally slow down on release cycles, to bi-weekly, weekly, then semi-monthly, then monthly. It can get worse from there.

A great talk from Startup School 2017 from Adam D’Angelo about this. Watch from 43 minutes into the talk.

 

One thought on “The Infinite Software Release”

Comments are closed.