Design choices software development are complex and demand the expertise of experienced managers to decide, and a good team of developers to implement, writes Dr R Srinivasan

HAVING seen the root causes as one of the concepts that depict AntiPatterns, we will now move on to the next one, viz., the "Primal Forces" that influence decision making. As professional software developers, we know that once the customer spells out the-requirements, the next step is to make the necessary options and choices for deciding the appropriate architecture towards the design.

The design should take care of vital aspects like security, development of the project within the planned budget, suitability and adaptability, and above all to be reliable system under the customer's environment where it will be integrated to other systems or applications. All these points illustrate that design choices in software development are complex that demand the expertise of experienced managers to decide and a good team of developers to implement. Of course the choices made depend very much on the context based on which decisions are made. For example, the choices of which details to expose, which features to include, etc., may be vital and a matter of concern in one context and many not be so in another one. The planning team must know and decide what is important and what is not and so decisions are also based on priority. Once the decisions and choices are made, the project plan should also indicate the risks involved in making the decisions. Management of risk is a universal force that motivates the Patterns and solutions and in a similar manner there are other forces in software development. Forces that are resolved carefully lead to successful software whereas unresolved forces lead to chaos.

In today's parlance of net based transactions, the forces influencing the context of software development could also be domain specific, viz., vertical forces and horizontal forces. While the former one is relevant to solution in a particular vertical domain application, the latter one will snap multiple domains horizontally encompassing several software modules or components. Horizontal forces are more difficult to reckon with because design choices made at one place may have a direct or indirect impact on choices made at another place. This definitely will call for well planned software architecture to assure design consistency such that software design across multiple modules pertains to this consistency. Primal forces are a particular class of horizontal forces, which are pervasive to software architecture and development, and therefore represent a value system for software architects and developers. Brown, et. al. In their book, 'AntiPatterns: Refactoring software, architectures and projects in crisis', present different management aspects under Primal Forces. They are Management of Functionality, Management of Performance, Management of Complexity, Management of Change, Management of IT Resources and Management of Technology Transfer.

As we know each and every one of these is very vital during the life cycle of a software development project. Good control and management of functionality will make sure that the developed software will meet the requirements of the customer. Is this enough? The answer is a clear no, because meeting the requirements without achieving estimated performance under different planned environments is no good at all. Management of Performance covers this. The next aspect to consider is how to make the design decisions such that we don't end up with too much of complexity. For example, the designers and the developers should take cognizance of good software abstractions that would lead to deciding a good architecture and simpler interfaces between the various components.

On the other hand, failure to look into effective abstractions will result in an excessively complex and costly system thereby making future enhancements and scalability almost impossible. Management of Change will take care of the adaptability, flexibility and portability of the developed software. To site an example, from William Brown, when the architectural characteristics for interfacing are decided, the areas of greatest adaptability and stability are borne in mind. Management of hardware and software resources is highly relevant particularly in a big enterprise.

A typical case of AntiPattern relevant to this is non-availability of a special hardware or software package during the life-cycle of the development process. This will lead to schedule delay and associated cost escalation. In a similar manner, the control of secured information and services are also vital under this category of management.

Next issue to be cited is Technology Transfer that takes place at two different levels in a project. One of them is at the completion of the project when the product is handed over to the customer with all details and documents and the second one is when a developer leaves the organization halfway through the project. The latter one is more critical: improper and incomplete handling of this task is another example of AntiPattern. Because of the intellectual property rights, security aspects have to be taken care of, if the technology transfer is done over the internet.

(To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)