5 Reasons Modern Software is Never “Done”

The software industry is constantly changing. Whether we’re developing for new mobile platforms, adopting the latest languages, or upgrading our methodology there are few constants when it comes to modern software. As timelines for software delivery projects tend to be shorter, more continuous approaches, we’ve compiled a list of the five reasons that software projects are never “done.”

#1. Modern software is “agile.”

The days of months-long software development lifecycles are over. Most organizations deliver modern software iteratively using agile-inspired methodologies, and these timelines are increasingly measured in weeks or days. This trend means that environment managers and release managers are increasingly being asked to provision indefinite environments used for projects in a perpetual state of release and testing. In an agile organization the next version of the code is often ready for testing and staging just as teams are deploying the last revision to production.

#2. Mobile Applications have to adapt to constantly changing platforms.

Mobile application platforms are constantly evolving. Out of nowhere your customer-facing applications may have access to a new location service or a location service to connect them to other users. The ability to quickly adapt to new features in a mobile application can make the difference between an app being adopted and an app being ignored. As mobile projects often target multiple mobile platforms simultaneously it’s impossible to put an end date when a mobile app has to respond to changes in a platform.

#3. Cloud computing requires less “setup time.”

Decades ago a project might have had to wait months for the necessary infrastructure to be purchased, installed, and configured. This would introduce downtime into a software development schedule that would encourage longer timelines. With cloud computing and DevOps-inspired infrastructure-as-code approaches using Puppet and Chef the setup time for infrastructure and the effort required to configure infrastructure can be measured in hours and minutes. This means that as soon as code is ready to go it can ship.

#4. Quality has become an engineering function.

This trend away from Quality Assurance to Quality Engineering continues to transform the relationship between application development and teams dedicated to testing and certifying software is ready for release to production. Ten years ago, a QA team might have asked when a software project was going to be “done” so that they could start testing it. Today quality engineers are embedded with application developers and the acceptance testing process begins during the first continuous integration build. If QA is waiting for code to be “done” they might be waiting forever, because today’s modern software projects never stop.

#5. Everything is continuous - Everything.

In the 1990s and 1980s teams would develop code for few weeks or months before installing it on a staging environment. Continuous integration changed all of that several years ago, and now continuous deployment is moving many organizations toward a reality in which it doesn’t make sense to talk about a “release” - many projects are on a release footing all the time, and when code is delivered to production continuously there’s no need to anyone to use the word “done.”

If you find yourself supporting one of these modern, endless software projects you need a tool to help you refine the repetitive processes that are required to support ongoing test environment management and release management. Plutora was designed to support organizations so that they can start improving repetitive release processes and attain an even more efficient approach to iterative or continuous release management.