Continuous Development,is it our new maintenance reality?
The onslaught of new APIs and the copious amounts of generated data is expected to heavily impact app maintenance. Andrew Binstock, Editor-in-chief at Dr.Dobbs expects it to be a continuous development process accompanied by a whole new mindset around maintenance with additional focus on Agile processes to effectively manage the work on completed applications.
Earlier last week Andrew Binstock wrote about continuous development and started off by comparing and contrasting it to continuous integration and continuous delivery. Apart from the rather obvious difference that it is a development activity he stresses on the fact that it is truly continuous as compared to the current hyperbolic use of the word continuous( truly "multiple times per day"). On a separate note, Andrew Lee Ribinger and Aslak Knutsen, authors of "Continuous Enterprise Development with Java" use the term "continuous development" to mean continuous testing through the application development process.
Andrew goes on to describe the changing technology landscape specifically all the APIs being rolled out by IoT device vendors that is ushering in a sea of change. Here is a quote from the article that summarizes how these changes accompanied by versioning changes will keep developers tied to maintenance work:
Product capabilities will change with each release, so new data sets will become available via expanded SDKs. In addition, companies with new products will intermittently feel the pinch of being compromised by early API decisions and so will publish new APIs that break with the old. Both actions will force developers to go back and do heavy maintenance on existing, working code. That might not sound like much until you consider that some apps, such as a dashboard that monitors multiple IoT data sources, might depend on dozens of APIs.
He further emphasizes the fact with the current shift to Big Data platforms and its related programming paradigms such as Map-Reduce to handle the exponential increase in data and data processing requirements. This again is subject to continuous development changes to accommodate everything from data format changes to rapidly changing platform APIs and addition of new processing components. The big question around a mindset change is then striking the balance between costs and benefits of committing to a code change.
What are your thoughts? Is this wave of change so vastly different to demand a process change for application maintenance or is it just a spike in maintenance until the products and platforms from new technological vendors mature?
Continous innovation rather than maintenance
This approach requires constant innovation, but is perfect, if you have it! You constantly release new stuff, forget about the maintenance. Innovation is the key.