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
alb@drdobbs.com
Twitter: platypusguy
Google+
