Waterfall
Since the discipline began with programming in Cobol and Fortran, software development has mostly followed the same path as other new product introductions. It was called the “waterfall method” – in contrast to the smooth flow of water in a flat river. Periodically, there would be a cascade of changes that came all at once – the “waterfall” – with a new version of the product released after a lengthy accumulation of fixes and updates.
For example, car manufacturers come out with new model versions each fall; once that model is released, it’s another year before the next version comes out. Furthermore, complete redesigns have much longer cycles – all the great ideas and lessons learned from the past and current models are poured into a new-generation replacement, complete with new features and a host of new bugs, not to mention the risk of unpopularity (think “generations” of car brands like Taurus or Camry, or computer OS versions such as Windows Vista or Mac OS-X).
More specifically, traditional “waterfall” methods of software development mean periodic overhauls or redesigns that can take years to be released, and will almost certainly require a brand new purchase in order to get the upgrades and new features. And in the meantime, patches and fixes would be sent out to deal with egregious bugs or security vulnerabilities; more importantly, these patches and fixes have to meet a very high threshold for release due to the very nature of the “waterfall” to favor slow, big packages of changes, rather than quick incremental updates.
This is especially true with “site-specific” software – client hardware with standalone installations of software. With thousands of such installations, the process of updating software can be tedious and stretched out over years. It also means that vendors have to put aside a lot of time to manage many different versions of their software out in the world because the installations aren’t synched, and some customers may opt to not install updates. This can be a real problem if hackers decide to target systems where software updates to fix widely publicized vulnerabilities are not implemented.
Here Comes the Cloud
With the advent of cloud computing and the development of massive systems of thousands of servers by pioneers such as Google, the waterfall method has given way to a newer, faster, and better software development method: Agile.
Agile Software Development at its core is defined by small code changes for small improvements lined up and launched rapidly in a disciplined, repeatable process. Unlike the plan-based methodology of traditional software development where the next version may be a year away and the fixes to that version another year later, in Agile, customer feedback is immediate and often, a customer request is in production in a week.
Today, of the leading tech companies, it is hard to find one that does not follow the “Agile” software development method. For almost fifteen years, first at GE and then with VEOCI, our team has deployed a new version of our application every two weeks. VEOCI is now on its 104th version. In the two-week work cycle, new features, user interface improvements, security and quality tests and bug fixes are all “shipped’, constantly improving.
On-premise Begins to Lose
Previously, successful software had hundreds of instances on customer premises and the upgrade of versions was never an easy process and numerous versions of the software had to be supported simultaneously. Agile would not have been possible in that model – imagine supporting hundreds of versions of the application. The single version of the application on the cloud, used by all, makes Agile possible. That it dovetails well with small changes, of course, is critical – imagine surprising users every two weeks with big changes. Veoci is a cloud application. The upgrades to the new version are immediate; no waiting for the “system” to be upgraded and a big project to move to the new version – there is only one instance of the software to be upgraded.
Winners: Agile + Cloud
The Agile + Cloud innovation also becomes an insurmountable barrier for the previous generations of applications developed the old way. They can only expect that their users will upgrade to a newer version when they choose and while they may move to an Agile release schedule, it is unlikely to be in production at their users. They need to continue to maintain numerous versions of the software as long as their user base uses the versions. The cost is enormous – bugs fixed in multiple versions require unique attention and enhancements only happen with the newest version with frustration for the others. With this complexity, the Agile model falls apart. To make matters worse, a software culture used to the annual “waterfall” methods finds the change to Agile difficult at best. With Agile and Cloud, the generational brutality of the software marketplace plays out again with thriving companies with thousands of customers suddenly vulnerable to new entrants with a major structural advantage.
