When trying to assess the quality of a software application, in my opinion the most valuable measurement is Cycle timeImproving cycle time has done more to improve software quality, reliability, and availability than any other single software development technology.
There are many ways to measure cycle time in the product development life cycle. One of the key measurements of cycle time is the total time it takes from deciding to make a change to an application to actually implementing, deploying, and making that change available to customers.
A history of constantly shortening cycle times
In the early days of computing, software cycle times were very long. This is because the software was written to the physical punch his card with his one line of software code per card. The program was a big stack of such cards. A stack of cards was physically brought to a mainframe computer and placed in a queue behind stacks of 50 other cards that needed to run 50 other programs.
Just running the program required a lot of time and energy, not to mention a lot of money. Given the amount of time between when a program is ready to run and when it actually runs, my attempts to get the program working correctly have been limited. I tried it and couldn’t see what would happen. Instead, I manually combed through the program, line by line, to make sure it worked as intended. I made an effort to run the program on my computer only when I was absolutely sure that it would work.
Decades of computational change have greatly improved the time between writing a line of code and executing that line of code. The write-compile-run-test cycle has shortened dramatically over the years. In the early days, a single test run could take days or longer. Now you can change a line of code and press a button to run it immediately.
But then the question became how to get the software to customers. In the early days of microcomputers, software was distributed on floppy disks and CD-ROMs (both physical media). If you wanted to change the program, you had to throw away all the unsold discs and create a new set of discs containing the latest version of the program. Then I had to find a way to make that change available to all existing customers.
Customers receive updated software at the same time, but not all customers update immediately. It may take months or years after a software bug in an application is fixed before a customer starts using the software version containing the bug fix.
In this environment, it was very important to thoroughly test the software before releasing it to customers. This is because the time and effort required to fix defects is usually very long and very expensive.
With the advent of modern software web applications as a service, this dynamic has changed dramatically. Now you can change your code and deploy it to all your customers at the same time, almost instantly. With a modern CI/CD pipeline, you can deploy your changes and make them available to all your customers. Virtually no human involvement.
This means that the cost to change, fix a defect, or improve the customer experience is negligible, at least beyond the cost of the change itself.
Modern cloud-based release process
This change has brought about a major shift in how software is developed and released. Long QA cycles were common in early software development processes due to the very high cost of fixing defects. Companies often invest more in software QA than software development to reduce the number of changes required. These QA cycles were very important as the cost of remediating defects was very high.
But the cost of making changes is virtually eliminated, eliminating the need for lengthy QA cycles. Long QA cycles are a waste of resources and lead to unnecessary delays in making changes to customers.
In fact, many modern organizations do not QA test their software. JeezDevelopers do regular testing during the development cycle, but once they’re happy that their changes work, I press the buttonAn automated continuous deployment process releases to production almost immediately. If your software has a bug (a bug you didn’t notice until it was released to production), you can quickly and easily deploy a fix to resolve the bug with little cost or effort.
The mean time to repair (MTTR) for defects in modern cloud-based software applications can be dramatically reduced from months to minutes. At the same time, this significant reduction in cycle time allows new features to be rolled out to customers much faster.
Modern application failures for learning
Failures (mistakes, bugs, problems) that were once feared in software development can now be largely ignored. benefit from learning from failure far exceed the cost of failure itself.
Think about it. This means that failure can actually be encouraged. Making changes that are wrong is a great way to learn at very little cost what works and what doesn’t for a particular application. You can try experiments that may or may not succeed.
That is, in modern applications, Failure is now a viable option Additionally, additions to the software development process are welcome. Continuous improvement, incremental changes, and incremental fixes are great ways to improve the quality, availability, and usability of software applications. Companies that embrace a failure-tolerance mentality can move faster, improve their products faster, and become more competitive than companies that try to avoid failure.
Failure is not only an option, but perhaps the only option for maintaining a competitive product in the modern digital world.
