Have you got your act together?

Joe Marasco

PUTTING together the pieces is a vital skill, especially in the world of software products. But who's going to be on the job at every point and what are the issues likely to crop up? Also, how does one make the magic work, this once and every time? Here's taking a look at what it takes to create a repeatable build-process for your product, what it takes for configuration management or CM.

It is important that each developer (or team of developers) has the autonomy and isolation to work on his piece without stepping on the other guy's toes. A system of work that allows such functioning is a configuration management system. At the same time, a good CM system also provides for a loose integration context.

Those that establish a regular ''heartbeat'' for the project - a periodic, regular, dependable, build cycle - improve their chances for success. Those that don't find that entropy begins to take over, and that building the product becomes more difficult over time. Many organisations vastly underestimate the effort it takes to put a good build-process in place.

Because of this, projects in their latter stages often have a ''new'' problem to deal with: In addition to having buggy software, incomplete parts, and so on, they also struggle with something that they have taken for granted - the ''simple'' assembly of their product. This is a trap for the unwary.

In order to not fall into this trap, you need to understand more about the process of assembling a product.

The 'packaging' trap

Why should the product-build be hard, anyway? First of all, the product you are going to ship to other people has more pieces to it than the prototypes you have been putting together for internal consumption. A classic example: Developers and testers rarely look at the ''help system,'' as they know the product well enough to play with it and test it. So the first problem that comes up is one that might be dismissed as ''packaging.'' You need more pieces to ship a product than to use it internally, and further, you need to document all the little details that the internal team has always ''known'' or taken for granted.

With enough planning you can avoid the ''packaging'' trap. If you ignore it, it will bite you, but if you are aware of it and plan for it, then it is relatively easy to overcome.

The three villains

There are three much more fundamental obstacles to success that come up repeatedly. They are distinct and interrelated, and all three must be worked on to achieve a successful build-process.

Organisational politics

Many software development managers lose sight of the simple fact that controlling the build-process is first and foremost a political problem. To put it simply, he who controls the build has an enormous amount of power.

Now the build-process is something that everyone must participate in, but only one group can control. By its very nature it is not a democratic enterprise; it requires a certain amount of hierarchical and structural apparatus to work at all. Everyone agrees on this, more or less. The sticky wicket is determining who gets the responsibility and authority to make it work. For that group will, from that day forward, wield a lot of power and clout.

Myriad discussions ensue as to who will have the right to do what to whom in the interest of the build-process. All of the negative political tendencies of your organisation will be exposed during these discussions.

In most organisations, however, wishing politics away will not necessarily make them go away. Politics is a fact of life that must be dealt with. However, you must get through this phase, as unpleasant as it first appears. Else, you will be incapable of dealing with the next two hurdles.

The process

The participants must now agree on the process they will use. The ''process'' will often be shaped to mirror the political compromises that were made to get to this juncture. In some organisations, we see these two obstacles mushed together into one giant hairball, which in turn gives process a bad name. You cannot use process to solve what are intrinsically political problems.

There are a few traps you don't want to fall into at this point. One is the ''religious wars'' pitfall. In every set-up, there are ''process gurus'' who believe that they, and only they, have the magic formula. Remember always that process is not an end in and of itself; it is a means to an end - shipping the product!

Another trap is to think that any process, no matter how good, can substitute for thought or judgment. You will have to watch what is going on and make midcourse corrections, no matter what your process is. You will need to modify and tune your process in real time as you discover what works for you and what doesn't.

Lastly, get on with it. You will develop your process iteratively, just the way you develop the software. Get to iteration one quickly. Learn. Change. Improve. Repeat until done

Tools

The third obstacle is the toolset that you will use to implement the process. You need tools that will automate and enforce the process you have chosen to use.

If you have a process that admits mistakes, you will be ''backing out'' changes from time to time. Does the tool support that easily? Are developers going to be checking in their work to a common baseline from multiple remote sites?

Then your tool had better support that model. Do you want to build your entire product from top to bottom every night?

If so, then I hope your tool has the performance and turnaround characteristics that will permit that. Do you want to automate your regression testing as part of the build? Once again, tool support is crucial.

Even organisations that have done a good job with the first two problems sometimes flounder with the third. And sometimes it is not the tools' fault either. Without constant vigilance, it is easy to automate a process that produces a low-quality result.

As with pretty much everything else, in software development there are a small number of ways to get this right, and almost an infinite number of ways to get it wrong.

If you view ''the build'' as a detail that will ''just happen,'' then the odds are against you.

Make sure that you attack the build process as a conscious effort that is critical to your success, and devote the time, energy, and resources to it that it demands.

To do any less is sheer folly.

The author is Senior Vice-President, Rational Software Corporation

Please e-mail us at eworld@thehindu.co.in if you have queries on computer usage or if you find an interesting way of using the computer.