What the Software Industry Can Learn From Old-School Development
In today’s software development world, fast release schedules are the norm. Applications go from initial release to version 1,357 seemingly overnight. Often, there appears to be very little changes from one version to another.
There are a number of factors contributing to this trend, but many are beginning to wonder if it’s time to reverse it. What led to this status quo? What are some of the problems it’s creating? What alternatives are there?
Software Iteration of Days Past
In ‘the good old days’ of software development, companies worked for months, or even years, on the next big update. Developers would pour over each new feature and bug fix, working to cram as much as possible in each new release.
On the flip side of the coin, users and fans of a particular program often eagerly anticipated the next release. When it came out, they would rush to purchase or download the new version, test out the new features and see how those features would impact their workflow.
As time went on, however, the paradigm began to shift due to a number of factors.
What Factors Led to A Paradigm Shift
The single biggest factor that changed the paradigm was the rise of the internet. Rather than development cycles being geared around manufacturing disks and selling boxed software, the internet suddenly represented a direct delivery model that did not require traditional manufacturing processes.
As technology continued to evolve, and cloud computing rose in prominence, the speed of software development increased even more. Rather than monolithic updates that required the end user to download and install the latest version, cloud services could roll out incremental updates to back-end services, with customers on the front end reaping the benefit.
In recent years, two philosophies have contributed to the increased pace of software development: Agile and DevOps. Agile’s focus was on productivity, rather than established rules and processes. Similarly, DevOps focuses on frequent, incremental updates and deployments, testing and improving along the way.
Cross-platform frameworks have also been a driving factor. React, Angular, Flutter, Iconic and others make it easy to develop for the web, mobile and desktop off of the same codebase.
While this approach makes perfect sense for cloud platforms and services, this approach has also become the standard for many direct-to-consumer applications, and especially mobile apps. What’s more, many of these applications update major version numbers as quickly as they release patches and bug fixes.
Google Chrome is a perfect example of this, and one of the first major consumer applications to follow this trend, since its release in 2008. In a mere 12 years, Chrome went from Version 0.2.149 to Version 87. In contrast, Adobe Photoshop’s first version was released in 1990 yet, at the time of writing, it is only on version 21.
While Google may have the resources to maintain that break-neck speed, many companies cannot, especially smaller ones. As a result, new versions of applications often ship with bugs, security vulnerabilities or both, only to be followed by yet more updates to fix the problems.
The Pros and Cons of Rapid Development Cycles
There are a number of pros and cons to the rapid development cycle that has become the new norm.
Pros
One of the biggest pros is the perceived ability to add continual value to users. Research has shown that human beings’ attention span is decidedly short. In fact, the average human’s attention span is a mere eight seconds. This is a significant decrease from the 12 seconds it was in 2000. Even worse, the lowly goldfish, often mocked for its short attention span, outpaces humans at nine seconds.
As a result, many developers feel they need to constantly update their apps to keep their users’ attention. And, when used properly, app updates can be one of the most important marketing tools at a developer’s disposal.
Another benefit is the ability to break up major features and upgrades into smaller pieces, making it easier for the developer to roll out major changes in incremental steps.
Cons
Despite the benefits, there are some significant cons to this approach, especially for consumer applications.
One of the biggest is the impact the constant stream of updates has on users. From Reddit to Android Forums to Quora and a myriad more, the internet is full of users complaining about the never-ending app updates.
For many users this goes beyond the mere annoyance of dealing with another notification. Users on limited data plans, those roaming oversees and users on poor connections can have their entire experience impacted or see costly fees due to app updates.
In addition, when apps have vague, incomplete or outdated release notes, it further exacerbates the problem, making users feel they are wasting time and bandwidth on something that isn’t adding any value.
Worse yet is the tendency of many companies to use live releases as a testbed. As Enrique Dans, Professor of Innovation at IE Business School, writes:
”Fine: technology progresses at light speed. But the current applications platforms, all operating independently, means that users are being driven insane with partial updates, or worse, what seems to be a policy of manufacturers sending out a first version, waiting to see what its problems are, and then a few days later sending out another version, as though the marketplace had now become a permanent beta.”
Striking a Balance
One thing is clear: There is not going to be a full-scale transition back to the old-style, monolithic software releases of the past. For the most part, that’s a good thing. DevOps and similar philosophies offer much, for both developer and consumer. At the same time, however, there are lessons that can be learned from the past and incorporated into the present.
One of the biggest lessons of the past is the need for comprehensive testing. The end user should never be a company’s primary testing platform.
With old-school software development, a program would often go through multiple iterations of Alpha releases, followed by as many or more iterations of Beta releases. Each test version would yield valuable information, helping the developers track down issues.
While the modern pace of software development may not allow for such a drawn out testing process, that doesn’t mean testing is any less important. In fact, cloud computing, remote work, bring your own device (BYOD) policies, multi-platform development and other trends make security and bug testing more important than ever before.
In order to balance these two opposing needs—to iterate as fast as possible while still delivering a secure, stable product—organizations must start relying on automated testing. Automated testing tools, especially those powered by artificial intelligence and machine learning, can perform advanced testing at a fraction of the time as human testers.
Another closely related issue is security. It’s important that security is not compromised in an effort to push out new releases every few weeks. Unfortunately, this is another area where the modern DevOps approach to application development has contributed to the issue. As DZone’sPatrick Spencer writes:
”In recent years, the application security (AppSec) field has not advanced as rapidly as the software development discipline. While developers are under constant pressure to push code, legacy security tools inhibit their ability to do so.”
As a result, organizations may need to rethink their approach to development, making sure they don’t rush out releases at the expense of security testing.
Similarly, another important factor is to make sure releases are spaced far enough apart to include enough features to add quantifiable value to the new release. Otherwise, developers run the risk of fatiguing their users’ attention and bandwidth with seemingly useless upgrades.
In they same vein, it’s important to make sure release notes are detailed enough to convey the value to the end user. In times past, when companies released monolithic upgrades, the releases notes left no doubt about what new features were included, new bugs fixed and more. In contrast, too many of today’s developers release updates with nothing more than “bug fixes” as the release notes.
Again, balance is the key. As Which?” writer Al Warman writes:
”Don’t get me wrong – I think it’s brilliant that software developers are constantly improving their products, tweaking things, adding new functionality, and making things better. No-one can possibly miss the days when updates were few and far between, arrived on a CD-Rom and took an age to install.
”But haven’t we gone too far in the other direction? Updates are great, but let’s make sure that developers aren’t releasing products too early, knowing they can update with every little improvement.
”Unless it’s a matter of life and death for internet security, once-a-month updates suit me fine.”
In other words, even in the realm of software development, the old saying still holds true: ‘All things in moderation.’
Related Articles
Back
In today’s software development world, fast release schedules are the norm. Applications go from initial release to version 1,357 seemingly overnight. Often, there appears to be very little changes from one version to another.
There are a number of factors contributing to this trend, but many are beginning to wonder if it’s time to reverse it. What led to this status quo? What are some of the problems it’s creating? What alternatives are there?
Software Iteration of Days Past
In ‘the good old days’ of software development, companies worked for months, or even years, on the next big update. Developers would pour over each new feature and bug fix, working to cram as much as possible in each new release.
On the flip side of the coin, users and fans of a particular program often eagerly anticipated the next release. When it came out, they would rush to purchase or download the new version, test out the new features and see how those features would impact their workflow.
As time went on, however, the paradigm began to shift due to a number of factors.
What Factors Led to A Paradigm Shift
The single biggest factor that changed the paradigm was the rise of the internet. Rather than development cycles being geared around manufacturing disks and selling boxed software, the internet suddenly represented a direct delivery model that did not require traditional manufacturing processes.
As technology continued to evolve, and cloud computing rose in prominence, the speed of software development increased even more. Rather than monolithic updates that required the end user to download and install the latest version, cloud services could roll out incremental updates to back-end services, with customers on the front end reaping the benefit.
In recent years, two philosophies have contributed to the increased pace of software development: Agile and DevOps. Agile’s focus was on productivity, rather than established rules and processes. Similarly, DevOps focuses on frequent, incremental updates and deployments, testing and improving along the way.
Cross-platform frameworks have also been a driving factor. React, Angular, Flutter, Iconic and others make it easy to develop for the web, mobile and desktop off of the same codebase.
While this approach makes perfect sense for cloud platforms and services, this approach has also become the standard for many direct-to-consumer applications, and especially mobile apps. What’s more, many of these applications update major version numbers as quickly as they release patches and bug fixes.
Google Chrome is a perfect example of this, and one of the first major consumer applications to follow this trend, since its release in 2008. In a mere 12 years, Chrome went from Version 0.2.149 to Version 87. In contrast, Adobe Photoshop’s first version was released in 1990 yet, at the time of writing, it is only on version 21.
While Google may have the resources to maintain that break-neck speed, many companies cannot, especially smaller ones. As a result, new versions of applications often ship with bugs, security vulnerabilities or both, only to be followed by yet more updates to fix the problems.
The Pros and Cons of Rapid Development Cycles
There are a number of pros and cons to the rapid development cycle that has become the new norm.
Pros
One of the biggest pros is the perceived ability to add continual value to users. Research has shown that human beings’ attention span is decidedly short. In fact, the average human’s attention span is a mere eight seconds. This is a significant decrease from the 12 seconds it was in 2000. Even worse, the lowly goldfish, often mocked for its short attention span, outpaces humans at nine seconds.
As a result, many developers feel they need to constantly update their apps to keep their users’ attention. And, when used properly, app updates can be one of the most important marketing tools at a developer’s disposal.
Another benefit is the ability to break up major features and upgrades into smaller pieces, making it easier for the developer to roll out major changes in incremental steps.
Cons
Despite the benefits, there are some significant cons to this approach, especially for consumer applications.
One of the biggest is the impact the constant stream of updates has on users. From Reddit to Android Forums to Quora and a myriad more, the internet is full of users complaining about the never-ending app updates.
For many users this goes beyond the mere annoyance of dealing with another notification. Users on limited data plans, those roaming oversees and users on poor connections can have their entire experience impacted or see costly fees due to app updates.
In addition, when apps have vague, incomplete or outdated release notes, it further exacerbates the problem, making users feel they are wasting time and bandwidth on something that isn’t adding any value.
Worse yet is the tendency of many companies to use live releases as a testbed. As Enrique Dans, Professor of Innovation at IE Business School, writes:
”Fine: technology progresses at light speed. But the current applications platforms, all operating independently, means that users are being driven insane with partial updates, or worse, what seems to be a policy of manufacturers sending out a first version, waiting to see what its problems are, and then a few days later sending out another version, as though the marketplace had now become a permanent beta.”
Striking a Balance
One thing is clear: There is not going to be a full-scale transition back to the old-style, monolithic software releases of the past. For the most part, that’s a good thing. DevOps and similar philosophies offer much, for both developer and consumer. At the same time, however, there are lessons that can be learned from the past and incorporated into the present.
One of the biggest lessons of the past is the need for comprehensive testing. The end user should never be a company’s primary testing platform.
With old-school software development, a program would often go through multiple iterations of Alpha releases, followed by as many or more iterations of Beta releases. Each test version would yield valuable information, helping the developers track down issues.
While the modern pace of software development may not allow for such a drawn out testing process, that doesn’t mean testing is any less important. In fact, cloud computing, remote work, bring your own device (BYOD) policies, multi-platform development and other trends make security and bug testing more important than ever before.
In order to balance these two opposing needs—to iterate as fast as possible while still delivering a secure, stable product—organizations must start relying on automated testing. Automated testing tools, especially those powered by artificial intelligence and machine learning, can perform advanced testing at a fraction of the time as human testers.
Another closely related issue is security. It’s important that security is not compromised in an effort to push out new releases every few weeks. Unfortunately, this is another area where the modern DevOps approach to application development has contributed to the issue. As DZone’sPatrick Spencer writes:
”In recent years, the application security (AppSec) field has not advanced as rapidly as the software development discipline. While developers are under constant pressure to push code, legacy security tools inhibit their ability to do so.”
As a result, organizations may need to rethink their approach to development, making sure they don’t rush out releases at the expense of security testing.
Similarly, another important factor is to make sure releases are spaced far enough apart to include enough features to add quantifiable value to the new release. Otherwise, developers run the risk of fatiguing their users’ attention and bandwidth with seemingly useless upgrades.
In they same vein, it’s important to make sure release notes are detailed enough to convey the value to the end user. In times past, when companies released monolithic upgrades, the releases notes left no doubt about what new features were included, new bugs fixed and more. In contrast, too many of today’s developers release updates with nothing more than “bug fixes” as the release notes.
Again, balance is the key. As Which?” writer Al Warman writes:
”Don’t get me wrong – I think it’s brilliant that software developers are constantly improving their products, tweaking things, adding new functionality, and making things better. No-one can possibly miss the days when updates were few and far between, arrived on a CD-Rom and took an age to install.
”But haven’t we gone too far in the other direction? Updates are great, but let’s make sure that developers aren’t releasing products too early, knowing they can update with every little improvement.
”Unless it’s a matter of life and death for internet security, once-a-month updates suit me fine.”
In other words, even in the realm of software development, the old saying still holds true: ‘All things in moderation.’
Related Articles