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?
/filters:no_upscale()/sponsorship/topic/995382dc-b781-4f0b-b74a-413e61a30927/CurityLogoRSB2023-1675420245128.png)
/articles/team-level-metrics-matter/en/smallimage/LOGO-1673637433912.jpg){kind=logo}
/articles/pipeline-quality-gates/en/smallimage/importance-of-pipeline-quality-gates-and-how-to-implement-them-small-1671622799937.jpg)
/articles/integrating-dast-ci-cd/en/smallimage/logo-1666174011486.jpg){kind=logo}
/articles/product-mindset-devops/en/smallimage/logo-1668102246270.jpg){kind=logo}
/articles/observability-gitops/en/smallimage/why-observability-is-the-key-to-unlocking-GitOps-small-1666948778310.jpg)
/articles/measure-optimise-delivery/en/smallimage/logo-1665074783369.jpg){kind=logo}
/articles/secure-software-development-gitops/en/smallimage/accelerating-secure-software-delivery-lifecycle-with-GitOps-small-1679658720410.jpg)
/articles/ci-cd-observability/en/smallimage/logo-1679470476672.jpg){kind=logo}
/articles/enterprise-github-actions/en/smallimage/lessons-learned-from-enterprise-usage-github-actions-small-1672998170003.jpg)
/articles/blue-green-deployments/en/smallimage/blue-green-deployment-from-the-trenches-small-1672220965411.jpg)
/articles/build-deploy-scalable-golang-api/en/smallimage/logo-1667248748960.jpg){kind=logo}
/minibooks/modern-data-architectures/en/smallimage/logo-1664902660420.jpg){kind=logo}
/articles/cognitive-load-platform-engineering/en/smallimage/logo-1668609260559.jpg){kind=logo}
/articles/green-iot-energy-sustainability/en/smallimage/green-IoT-for-energy-efficiency-and-environmental-sustainability-small-1666432828743.jpg)
/presentations/infrastructure-control-plane/en/smallimage/Daniel Mangum-s-1665739290818.jpg)
/presentations/stripe-dev-env-infrastructure/en/smallimage/Soam Vasani-s-1664525808854.jpg)
/presentations/refactoring-rust/en/smallimage/qcon-plus-s-1679694299933.jpeg)
/presentations/aws-apache-airflow/en/smallimage/qcon-plus-s-1679694143127.jpeg)
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
Community comments
Continous innovation rather than maintenance
by Marco Merens,
Continous innovation rather than maintenance
by Marco Merens,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for sharing this article. I develop javascript webapps for ICAO, node.js as backend. One webapp takes less than 2 weeks to develop. Once released, I tend not to touch the code anymore unless there is a big problem. My apps generally have a lifetime of less than 1 year. After that, the app is replaced by a new, enhanced version, or deleted because not used or merged into another app.
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.