Channels ▼


Continuous Development: The New Maintenance Reality

In modern software development, we are accustomed to seeing the term "continuous" used in expressions such as continuous integration and continuous delivery. Curiously, in neither context does the word carry its regular non-technical meaning of uninterrupted activity. When continuous integration (CI) first appeared on the scene, the "continuous" adjective was hyperbolic and meant to emphasize that integration (also a misnomer, meaning assembly and build) would be done several times a day rather than once or twice a week. Continuous delivery reflects a similar view of an activity done "several times a day," although some organizations certainly deliver more frequently than that.

So far, these are the two primary applications of the word. However, an upcoming sea change in the fabric of software development suggests that programmers will soon be truly developing continuously. More specifically, continuously working on completed apps.

That sea change is the Internet of Things (IoT), which refers to networking and smarts embedded into almost every item sold. In the IoT scenario, which seems to be only a few years off, you'll be able to check the temperature inside your refrigerator, whether the lights are on at your home, how full your hot water heater is — all from the dashboard display of your car. Everything will be wired and give you access to far more data than you ever needed.

The next step will be the profusion of apps that convert this data into perhaps useful information. Let's stop there for a second. The "things" the IoT will consist of will certainly use published APIs to enable querying data, which will be returned in a predefined, to-be-parsed format. Likely, vendors will publish small scale SDKs to enable this. Applications will increasingly involve pulling data from multiple devices and other sources (such as Web services) and distilling it into something useful. This alone will create a large demand for developers. And because each API will have its own peculiarities, there will be a distinct limit regarding how much of a product a single developer can competently code.

That scenario covers the situation in which the key factors are comparatively stable. The reality, however, will be far more dynamic. 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. So, at almost any given moment, developers who could be writing other software will be tied up accommodating some vendor's changes. There will be no sense of ever being done, but rather one of being constantly in catch-up mode.

This is not the only issue that will become salient. Another is handling the volume of data that some of these devices generate. An airplane engine can generate 1TB of data an hour. A drill bit for oil exploration creates a million data items per minute. This volume of data means that Big Data programming will be needed, especially in industrial contexts. Here, small changes in formats can lead to huge effects that will break back-end processing. Again, forcing developers to expand, rewrite, and update existing code often for small benefits that might or might not offset the cost, but which must be performed carefully.

IBM has begun to refer to this coming overflow of programming as "continuous engineering." I find this appellation a bit grandiose. There will not be much engineering involved, just long slogs of straight-ahead maintenance programming.

One thing that is for certain: organizations that have not adopted modern programming practices of short sprints, continuous integration, and continuous delivery are going to find this new reality to be very painful. It will require companies to make changes agilely, test results immediately, and deploy updates quickly. With the rate of change that the new continuous development requires, this will be the only way forward, I believe. But even with a lean, efficient process to accommodate the demands, a whole new mindset around development — and, especially, maintenance — will be required.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



"Continuous" means exactly what I said it does. What you're referring to is "continual." Different words with slightly different meanings. See and many similar links that explain the difference.

Indeed, my parenthetical comment on integration would have been better stated with your refinement. However, the reality of CI is that the principal activities of CI take place after the code is merged. It's not the merge of code itself that defines CI.


" in neither context does the word carry its regular non-technical meaning of uninterrupted activity"

This is silly writing, and the hyperbole is all yours. In colloquial usage, "continuous" means that it keeps happening, not that there's a literal continuum with no moment of non-occurrence. We have a "continuous build" system, which means there's a build every time there's a code change ... not that the build machine is always doing a build -- that would be pointless. "integration (also a misnomer, meaning assembly and build)" -- no, that's not what integration means. Integration is the process of adding changes from multiple developers into a single branch.

"the Internet of Things (IoT)" -- which is orthogonal to changes in development practices. You have tossed a bunch of things together that don't belong together -- unmodular thinking.


The comment "There will not be much engineering involved, just long slogs of straight-ahead maintenance programming" paints a different picture of how software actually evolves.

Developers of those systems which integrate lots of (often changing) APIs will develop processes and tools for identifying 3rd party API changes as well as generic mechanisms for dealing with these changes that will continually lower the engineering needed to deal with it.

Additionally, more standards and best practices byAPI providers will likely start to take hold which will make integrating new APIs less of a re-invention of the wheel.

With that said, great article!


"This volume of data means that Big Data programming will be needed, especially in industrial contexts."
Actually, industry has been dealing with this for years. It generated the Device Description technology to deal with the issue. Yes, there are changes in the DD specification but few and far between, changes to the devices require a change in the DD...all a part of upgrade costs.
A lot of data is generated, but it is being dealt with quite nicely. Of course there is always room for improvement when you are dealing with high data flows but it's all in a day's work. It is one of the things that make control systems differentiate.


You're right. I should have made that clear. Tests are so intimately part of my build cycle (run in my Ant file) that I don't conceptually break them out. But I should have in this case for the exact reason you explain. Thanks.


Continuous Integration is not just assemble and build, it's assemble, build and test (hence the 'integration' in the name. In sites where I've been that do CI, 'test' meant, unit (or micro-test) suites run, integration tests run, and (less often) functional tests run.