In the article ~{!0~}The Dynamics of Agile Software Processes~{!1~} http://bdn.borland.com/article/0,1410,29726,00.html, Randy Miller pointed out the number one characteristic of Agile Processes is Modularity. But in real work, it~{!/~}s a difficult task to fully embrace the concept throughout a project development.

In this article series, I would like to introduce a modular approach that I created 4 years ago in IT boom time when it started from a small casual project. In the last 4 years, this approach has evolved into a quite effective and successful model used in a fairly big project. I call it ~{!0~}Horizontal Modularization~{!1~} as it highlights the importance of building the framework for future modules while implementing and delivering your first batch of modules to tap into a niche market.

1. The Interface Modularization

The idea of modularity is not fresh in any software development company with a few years development history. However, to fully embrace this concept in a complicated project, involving a broad range of feature set, is a difficult task and can be easily overlooked even in a big corporation. Especially for the companies with more than ten years software development history, they have all gone through converting DOS based menu driven products to Windows based GUI products. To smooth the transition, many companies simply adopt the menu driven interface provided by Windows to mimic all the functionality implemented in their legacy DOS programs, while inside menu items they might utilize the power of Windows controls to provide data entries, data validations in a more modern style. Some other companies simply go to anther extreme in that they stack layers after layers of Windows buttons as a hierarchical navigation structure for their complicated package with a boring look and hopeless difficulty to use.

The problem with the above two examples is that they did not know how to fully take advantage of the user interface revolution brought by Windows GUI paradigm. They thought that as long as they have started compiling their software in Windows environment, the product can be called Winxxxxx for market purposes without knowing the product, in substance, is simply a copy of their DOS legacy providing neither boost to ease of user interface nor big feature delivery fully utilizing Windows GUI controls.

In my opinion, using menus is a simply a DOS way to navigate through your program, but it still has it~{!/~}s place in Windows environment for those less frequently used features such as settings for Views, Options, Registrations and Help etc. However overuse of menus for everything is simply an ignorance of Windows existence. Its main problem as a major navigation tools is that it hides all the features in a deep hierarchy of submenus, therefore, there is no easy way to run a feature berried in the tenth level from the root menu. Another problem with menus is that you cannot see all the features (ie. descriptions) in one picture at the same time, which leaves users wandering what features are available in the application.

The buttons mind field is even worse than menus as the main navigation facilities, even though buttons are purely Windows controls. With Menus, you can at least cursor over the submenus and show the items and exit out without committing yourself to any modules. While with buttons on the a switchboard panel, you have to get into some of the features behind buttons after buttons, and exit your way out possibly without doing anything simply because that is not you target feature. You can imagine how frustrating that would be after a few tries when you are a new user.

In the following few series, I will demonstrate the real power of Delphi TTreeView component as an super efficient navigation tool for any scale of application. I will also introduce a mechanism to link the TreeView to the underlying source code to provide an elegant modular model for all size of development.