The software development business, once the domain of a few advanced technology companies, is now pervasive. Why? Because software is less costly and easier to modify than hardware. At first glance this is obvious; building a software telephone switch is a lot less costly than the hardware equivalent. Looking more closely, though, software products have far more features and, therefore, are more complex than hardware products. Software is easier to change, but this just adds to the level of complexity, especially on the management side. Software allows us to build products that are more complex.

The successful software organization can manage complexity, in both the product and the process.

Product: Focus on Strong but Simple Architecture Simplicity and good architecture are key to managing complexity and producing high quality product. Good architecture is a result of understanding the problem, the tools you have to work with, and good design. Also, there's no substitute for experience. One important component of good architecture is how you use your tools.

The C language, for example, has numerous capabilities. Some are good, some are bad. At Neuma, we tend to be fairly strict about how the language is to be used. Not just no "go to" statements, but a whole set of dozens of guidelines that help our developers produce good product. Some examples are:

Use loops with conditions at the beginning of the loop, not at the end. It's easier to read and understand.

Always use 0-index origin for arrays, loops, etc., and (start, count) rather than (start, end) pairs.

Don't do arithmetic on pointers and avoid using pointers altogether.

Name local variables/fields with simple names. Use full names for global identifiers.

The list goes on. You can use a safe subset of the C language, but without losing functional capability. The idea is to make all code simple and consistent. Simple formatting rules do not accomplish this goal. The overall set of guidelines help to make code maintainable and readable, while instilling an attitude of good design.

Using a smaller but adequate subset of the language also provides simplicity. If loops are always going from 0 to N-1, you don't have to spend a lot of time figuring out boundary conditions, because they all follow the same pattern while speeding things up and cutting down on errors. This is a very specific example, but if you have even a dozen clear guidelines explained, it's amazing how much simpler you can make your development environment.

Other ways to simplify your product include:

Simplify the technology you use. Don't allow everyone to pick their own scripting or programming language.

Perform code reviews so that you have fewer problems flowing through your product life cycle. Also review against design guidelines.

Use design rules that help your configuration management rather than hinder it.

Instead of variant builds, support run-time configuration of a more generic build.

These are but a few examples that will have significant effects on your product architecture. When it comes down to it, a dozen or two little things that improve your software by 1% or 2% each, can have a significant overall effect.

Process: A Reward, not a Burden

I love it when developers come to me and tell me that they couldn't do their job without the ALM/CM tools and processes. You'd expect that from CM managers, but often CM is seen as an overhead by developers. Granted, you'll never hear this until you take away their environment, but you can give them benefits such as:

Changing based check-in, differencing, merging and promotion

Providing the ability to check-in source code when the developer is ready (versus when the build manager is ready)

Creating to do lists that eliminate any extra effort to provide traceability

Making it easy to review tasks accomplished over the past months and years

Providing access to all the product information they need in a single place

Eliminating tagging and minimizing of branching/merging

Give easy ways to look for outstanding problems or to identify what has been done in the past

Allow for the ability to automatically augment files with source history from the CM repository meta-data

Provide the ability to do on-line code reviews of a completed change package with just one or two mouse clicks.

Each of these things simplify the life of a developer. ALM/CM tools should provide most of these functions, and more. Again, it's not one thing, but a lot of little things (or not so little things) that add up to provide significant benefits and help to reduce complexity.

It's a real sign that they've got a good process and good tools to support them. Good management tools gather accurate and timely data that reflect your processes. Good processes, when supported by good ALM/CM tools, help to ensure productivity and lower administrative overhead. The two work hand in hand.

Your ALM tools and processes should be the nervous system of your product development, not a burden. Up-to-date status information, high-level impact analysis, good communication, instant traceability are a few of the benefits when tools and processes are well implemented. I've mentioned them before, but some of the key ingredients of such environments are:

Well-defined processes

Integrated solutions with good traceability

CM strategies that minimize branching, merging and labeling

Change management rather than file management

High availability, high reliability tools with low administration

Tools that can be easily customized to your processes rather than vice versa

The Customer Comes First The software development business demands that we know our customer. Whether it's a single contractor, an internal customer or a market segment, whether it's a unified voice or an assortment of variant requirements. We need to understand the customer. Many common mistakes are made here:

Not fully understanding the customer requirements

Not understanding the impact of your changes, especially on the customer

Inability to tell your customer how a new release will affect their operations

Not knowing what version each customer has installed

Not focusing on the customer first

Because of this, we'll see a stronger move from CM tools to wider ALM tools. If the tools are well integrated, developers will start to gain an appreciation for the customer and will start to develop a customer centric view. Then everyone will be in the business of supporting the customer.

In the end, it is the flexibility of software that the customer likes. If a good job is done on architecture and process implementations, the flexibility can be realized without exponential costs due to product complexity.

About the author

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 farah@neuma.com