Six Ways to Build Reliable Applications


In his CM: the Next Generation, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

more on good names for boolean locals. Also, we made sure that the names chosen made the code (e.g., if statement) more readable. This is especially important with booleans, arrays, and function names.

We focused on constant code refactoring, because software architecture was everything. Copy and paste was replaced with factoring and this not only kept the code minimal, but eliminated the multiplication of bugs with each copy and paste operation. It further allowed us to improve the factored code rather than having to try to track down all of the copy/paste locations.

Getting the Requirements Right
Neuma's CM product evolved over a period of about 20 years (so far). So how did we get the requirements right, or did we? Well first of all, the wealth of large project CM experience helped. We knew, for example, that change packages (aka updates) had to be at the center of any solution. We also knew the value of seamlessly integrating applications and the derrived benefits, but it was still not easy. For one thing, GUIs were rare and evolving in their infancy 20 years back. Networking dealt with connecting mainframes together (except in the Unix world), and not users. And our CM tool experience was based on fixed company requirements, once for an IBM mainframe supporting hundreds of users, and once for a small network of DEC Vax mainframes supporting a couple hundred users. Keeping the command line interface simple was important. So was the architecture of each language we were using, in both cases proprietary.

The focused in-house requirements gave us a tremendous blind side, especially because Windows wasn't mainstream for development, and Unix was just expanding its foot-hold. There were no file system standards to adhere to (i.e., make the design architecture mimic file system architecture). As a result, our first releases of CM+ focused on a complex folder/module/section paradigm, where each module, which shared a common base name, was composed of several sections, identified by the file suffix. For example a C-module had a .h and a .c component, and in our case a .x component as we preferred (and still do) to keep externals separate from all other header definitions. An Oracle form had a different set of sections. An assembler language module had a .inc and a .asm component.

Although the product let you define your own module types (called groups), and this was a selling feature for some shops, we soon realized that every shop worked differently.  It wasn't always easy to package things into neat module groups, especially because the groupings overlapped. As a result, it became nearly impossible to automatically load in a

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!