The development lifecycle of software products is driven by the customers' business needs. Software providers offer specific solutions that match customers' needs, solutions which are correlated with the instruction level developers have and the technologies available on the market. New technological enhancements determine a quick deterioration rate for products. A product can become obsolete from the point of view of the technology it uses. Even if the business functionality corresponds to customers' needs, the used technology may no longer reflect current demands. The quality of a software product is reflected not only by the accuracy with which it interacts with the desired data flux (as established by the business rules), but by other qualitative factors defined by the current technological spectrum on the market, at the time of the assessment. Product maintenance and the integration of new functionalities supply a wide range of additional parameters which contribute to the definition of the quality rate, factors which are quite abstract from the end-users' perspective.
Almost 20 years ago, J. B. (Joe) Rainsberger, an important decision maker in the field of Test Driven Development, was giving an account of his experience at IBM. At a time when he had to overcome an important milestone, he began running into considerable difficulty in finalising the functionality set for the project he was working on. Each newly designed feature affected other existing features. The project architecture was so interactive, that it was difficult to develop a new attribute without modifying the global frame. Unfortunately only manual regressing testing could uncover the errors, but this option was completely undesirable, as it had low proficiency rates.
Radical measures were necessary to prevent deadlines from being exceeded. A full application re-design was out of the question because of the considerable size of the code and the tight deadline. The only plausible solution was to create a mechanism that can signal the errors, at various stages of development, in due time. J.B. thought of creating a package of methods that could test the pillar project components. Despite the fact that automatic testing did not exist at the time, Joe believed it would be good to use a new paradigm in development, a paradigm he called "building on green", which was based on a set of methods which tested the fragile areas of the application, so that the integrity of the application could be easily maintained. Although building new modules for an application may seem a waste of time, this has driven the application forward because it improved development speed.
During the development process, the relations between various components can increase the fragility of an application, so that there is a great need for a mechanism that can reestablish the balance.
Running the test package at regular intervals allows for the timely recognition of possible errors. This also allows for immediate action since the error detection area is smaller and the code written between the sessions can be easily delineated. Therefore, J.B. took steps on steady grounds, avoiding the writing of huge chunks of code which would then have to be rewritten. "Building on green" allowed our developer to deliver the software in time. Test Driven Development became a necessary paradigm to avoid and eliminate the redundant time and redundant errors that may occur in the development process.
At the time, it was an unusual practice to create software mechanisms that can ensure consistency throughout the development process. Even today, there are large, important applications whose integrity can be checked by the company team that builds them, only upon finalizing a manual testing session. Finalizing a functionality set can generate errors that may require overtime work.
At present, there are mixed views on how the integrity of applications can be ensured, on what methodologies should be implemented and on how necessary automated testing should be. Each paradigm comes with advantages and risks. It is clear, however, that a consensus is yet to be reached. This resulted in the presence of many fragile applications on the market.
The applications which have been used for some time may re-enter a maintenance cycle when their owners decide to modify or replace an existing functionality. The greater the timespan between two consecutive maintenance sessions is, the greater the deprecation degree of the technological quality. The ability to modify or integrate new functionality becomes more and more complex. The on-going technological progress performed within a time unit generates a technological "oxidation" of the current market applications.
From an objective point of view, legacy projects require more effort from developers. From a subjective point of view, there are few developers who are enthusiastic about taking over such tasks. The majority of such applications are not supported by automated testing, by unit testing. Therefore, the risk of error generation is inherent, which leads to significant discomfort.
The rapid technological changes have led to a thirst for everything new and caution when it comes to technologies that have a couple of years behind them. Developers try to avoid those projects which use older technologies, out of the wish to be in tune with the trend technologies. On the other hand, the project lifecycle does not allow for a pace that is kept in perfect tune with technological progress, because of its inherent costs. From a business point of view, technological pace is not a strong enough reason to determine the owners to reinvest in modernising the applications, as long as the data flux meets standard requirements. The discrepancy between developers' paradigm and the project requirements determines the occurrence of a gap. It is a matter of question whether this discrepancy is justified and whether this drawback can be overcome.
Two decades of experience have taught me that there is a generalized attitude when it comes to legacy projects - disinterest - and there have been situations where developers decided to change their workplace because of the projects they worked on.
Each technology is tempting upon its release. After a couple of years, when its popularity wanes, developers may choose to completely ignore the technology. This kind of attitude is representative of developers with less than 10 years of experience.
The first approach to legacy applications is Test Driven Development. This paradigm forces the reshape of the application by starting off with its pillar components. If the components cannot be easily delineated, the Test Driven approach is difficult . In such cases, a full project restructuring is necessary.
Preparing an application for TDD is a proactive step, an important one in understanding the code. Test Driven Development is a development paradigm that can easily overcome monotony, by challenging the developer to be an active component of code design.
Another important element is the requirement to maintain the integrity of the application. Along with the TDD paradigm, the code is tied to testing. Obviously, TDD is a development paradigm. It is not a means of implementing tests. In spite of this, as a secondary goal, the tests will ensure code integrity.
From a subjective point of view, by adopting such a development paradigm, developers may share a new vision of how the development process can unfold. Developers will understand how to use an array of programming techniques, fact which is not so obvious in the more traditional approach. Several aspects become clearer: the granular nature of various code segments, the rigorous definition of each class, the separation of and the ordering of the classes involved.
I believe programmers can break the code-writing routine by adopting a TDD development pattern. Test Driven Development opens up a large field of vision for the imagination, which enables programmers to perceive implementations differently.
Developers are forced to find alternative means of adapting themselves to any type of technology and to any project. The more projects developers get involved in, the more the roads they travel, the better the work experience, the more challenging the opportunities for their personality to develop. The environment which accommodates modern developers limits their decisions to a pre-established pattern for applications. The main challenge projects have is the degree by which they manage to assimilate this pattern. Developers are, thus, deprived of making important decisions, deprived of seeking out technological solutions, deprived of choosing optimal mechanisms. A developer raised in such an environment does not fully understand the "why"s and does not feel the tension of decision-making.
At the time J.B. Rainsberger became a specialist, the developer was growing into the key project component in many instances. Developers' creativity was best stimulated in extreme situations. At present, very few programmers can report truly unforgettable accounts of their work. Many candidates invited for an interview do not know what answer to give when confronted with the key moments and key projects in their life. When faced with the monotonous task of compiling a list of functionalities, developers are involved only in a routine work where the salary is the only incentive. I believe we must nurture developers, so that their spirit of adventure is kept alive. We must make development one of the most tempting profession, just as it used to be.