In 2011 we will see successful mechanical refactoring across service and organizational boundaries. Regretfully it will take nine more years for this to become a common agile practice.
In a decade we will see terms of service expressed as automated tests. Service providers will occasionally revise these terms and their tests as they upgrade their services. They will NOT, however, be obligated to support an old interface indefinitely. Rather, they will be obligated to provide automated refactoring scripts that have been shown to mechanically upgrade a well-known public suite of sample applications in such a way that the new tests pass.
Careful readers will notice that I’m equating testing a service interface and testing a program that uses that interface. This unification will require a fresh approach to interface specification and test. My hope is that this comes as a consequence of the Agile Alliance Functional Testing Tools project.
Readers may also wonder how automated refactoring scripts might be expected to upgrade programs for which they have no prior visibility? Here I am assuming that these scripts are a byproduct of test-driven development with relentless refactoring using an IDE capable of recording refactoring, such as Eclipse Refactoring Scripts. The service provider benefits from the public suite of sample applications, be they hundreds or thousands. They are proxies for their client applications, the owners of which are highly incented to be sure the samples are representative of their expectations.
This division of labor derives as a natural consequence of Agile’s extreme programming practices combined with the intense pressure within our industry to specialize. We benefit from ongoing innovation without sacrificing the robustness in our service-based applications.