Developing Amidst Change
Lately, I have been working as a lead developer on a software module for a reasonably sized project. What seemed to be a task that appeared to require no more than three weeks has turned into something that has spanned four months and may include an additional two months for the provision of integration support. There is a notable difference between a software project that can be completed by an individual and one that requires multiple teams that are spread across the world.
Getting a feel for the project was a major factor in increasing the likelihood of delivering my modules on time. I was able to observe the development of other software modules for the current project, before I was assigned to work on my own. The tool set was noticeably unstable. Not only were the tools not functioning as expected, the tools that were available changed as updates to the tools were required and additional tools were introduced. The overall system design was unstable and the module interfaces were not set. Responsibilities were being shifted between modules. The project’s susceptibility to change is something that must be acknowledged from these observations, and development practices must be adopted to accommodate such changes.
Noting the high level of malleability in the developing software system, my software module was designed with insulation from external module changes in mind. Specific function signatures for my module were provided to me when I began my low-level module design. My module depended on the services that were provided by other modules, some of which have not been well-established. The gist of my module’s responsibilities was adequately conveyed, and the introduction of responsibilities into my module was rightfully resisted through a Socratic series of questions. The new responsibilities would have kludged the elegance of the design by introducing a distinct behavior to the module for a very special case. With much success in preventing drastic changes within my module, the development effort was placed on dealing with changes to the overall system design.
Distinct program entities were introduced at the entry points and exit points of my module. The module interface functions dispatched requests to the inner module functions. This allows the interface to the module to be easily changed without necessitating a risky modification to the module’s core. Also, proxies for the services of external modules were introduced for the module core functions to use. Instead of having several parts of my module make direct calls to external modules, my module’s core channels its requests through the proxy function, which forwards it to the appropriate external module. Although it may have been subconscious while I was designing my piece of software, it is clear now that this is an example of reducing module coupling. My attempt to isolate my module from changes in other parts of the system apparently resulted in a design that approximates good designs that are prescribed in academic texts on software engineering.
Compartmentalization was also employed within the module. Functions were introduced, for example, to isolate the code in the module’s core from the representation of data transferred between my module and other modules. In one situation, a change in the format for the data transferred between my module and another module required changes in only a handful of my module functions. Changes in a part of my module do not significantly affect any other parts, and as changes to my module became required, the changes were implemented in a way that minimized the impact to the rest of the module.