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