In this article, we will discuss discrete, recognizable methods of software configuration management, which I call Formal Interfaces and Standards . Because configuration management (CM) is a discipline that connects to every single part of the software development process, it means that every part of the process impacts the configuration management activity of a project. Many of these techniques aren't pure configuration management—if there is such a thing. Instead, they are techniques that have a high impact on CM. Adopting these techniques as formal interfaces or standards, will help your project overcome CM challenges.
However, making radical changes to the development process to address a single CM issue generally isn't a good idea. But understanding these techniques can help you contribute to shaping the future direction of your project.
Formal Interfaces & Standards
Standards and interfaces can be a burden or a benefit, depending on who benefits from conformance with the standard. In some cases, though, Formal Interfaces & Standards can be an effective technique for adding structure and stability to a project.
For our purposes, there isn't any difference between an interface and a standard; they're both well-specified constraints on the project. Whatever you call them, adopting an interface or standard partitions the system. In the case of a technical interface, this provides separation between hardware and/or software development teams.
A targeted standard like "strict ANSI C syntax" or MISRA will offer some performance and/or quality benefits in exchange for fairly straightforward implementation. A "general" standard like UML 2.0 will provide you with the ability to do something (improve documentation) but may require a more specific local standard (documentation standards, anyone?) to really kick things off.
In the case of a process standard, the standard will specify the roles and then specify the separation between them. This separation will tend to slow down parts of your project. In exchange for this, technical standards make it possible to start working parallel on separated modules.
Process standards generally cost a little more effort, but provide a defined starting and ending condition. This improved clarity helps team members understand where they are, and provides improved visibility to project management. For example, RUP does a pretty good job of setting expectations on different project members. Knowing who is responsible for what lets a team work more confidently. On the other hand, CMMI may be implemented at such a high level that you never even know it happened, or you may wind up in weekly metrics meetings doing your part for "improved visibility."
Another advantage to Formal Interfaces & Standards is reduced coupling. By partitioning the system, either technically or organizationally, it becomes possible for one team to work independently of another. At a technical level, this enables parallel development and reduces interference (and bugs) between parts of the system. Process standards can
eliminate ‘political coupling' and provide mutually agreed-upon results for different organizations.
“Political coupling” can happen when a leader or influential member of one team moves to a different team. While having the expert available to help out can be useful early on, excess involvement can lead to one team dominating or dictating the activities of another. Similarly, when one team predates another, or when one team has more influence or
popularity than another, the lines between the teams can blur. Process standards can re-draw the lines between the teams, removing some of the undue influence.
When two different organizations are working together, there will naturally be some uncertainty as to where the division between them lies. In a client/vendor relationship, naturally the client and vendor are trying to push work to the ‘other side' of the line. When two ‘technology groups' (mainframe vs. distributed, IT vs. R&D, etc.) are working together,
the tendency may be to pull design and architecture decisions away from the other groups.
When two ‘functional' teams (development vs. QA) are working together, the tendency will be to disagree over hand-offs, responsibility, and control. In every case, having a mutually agreed-upon specification of the roles and responsibilities of the groups is a benefit. Obviously, the best solution would be a custom-written specification for each scenario, specifying all the circumstances of that particular scenario. But nobody has time for that. Pre-written process standards, and pre-designed interfaces, are
enormously helpful for this.
It is possible to individually specify some technical interfaces. Even these, where everyone involved is a developer and presumably speaks the same language, can have problems. Most of the time this is because of semantics. Everyone agrees on the syntax and signature of an interface, but it requires some experience (which is frequently lacking when groups are first thrown together, since this is the first time they've worked together) to elaborate what the required order of calls is, and/or what the handling of erroneous or imperfect conditions will be. Formal interface languages exist that can automate or validate some of this work.
Some technical and process standards provide an added benefit. By decoupling the parts of the system, they make it possible to begin testing the design or architecture of the system very early in development. Early development of test cases can reduce or mitigate problems with interface specifications, and may significantly reduce the cost of rework by finding problems before too much code is written. (This includes process standards. A
team that knows what role it will play in a project can begin working on that role earlier. When the role of the team is unclear, time and effort will be wasted in duplication, or in political bickering.)
Formal Interfaces & Standards reduce communications across the boundaries that they impose. This can be an advantage-the reduced communication comes from clarity of purpose and reduced discussion about what to do-but it can also be a disadvantage. If the standards reduce communications between important creative parts of the project, you may be creating a problem.
Prematurely imposing a technical interface, for example, can prevent the development team(s) from improving the usage model. This may reduce performance, especially if the interface requires all calls to remain excessively detailed. Imposing a process standard prematurely will definitely slow things down. It's hard to know what ‘prematurely' means, but in general a totally new product design should remain loosely managed for a significant time before attempting to "lock down" the development process. (Part of the motivation behind Agile development processes is to keep development teams unlocked, or loosely locked, for as long as possible.)
Imposing standards on a project will increase the development workload. Technical interfaces will require that all of a set of functions be implemented, for example, rather than merely the exact set needed for the project to work. Similarly, imposing a formal process will increase the amount of ceremony in the project. Changing from one formal process to another will change the amount of ceremony-that's on you. But keep in mind that time spent on ceremony is time not spend on development. Some ceremony is a good thing, when it serves to distribute information and improve efficiency. Too much ceremony, though, is just too much ceremony.
Another potential disadvantage to Formal Interfaces & Standards is an unfair or unbalanced workload. When a standard is used to partition the project, there is the risk that one of the modules or sub-teams may wind up with an excess amount of assigned work. A technical interface, for example, may be created to divide a database interaction module from the rest of the system. But if the database module simply passes data back and forth, and does nothing to abstract or standardize the application/database interface, then the developers assigned to the database component may wind up playing games while the remaining application developers are stuck with the same set of database problems wrapped in a new set of function names.
Likewise, if a process standard partitions a project team-via roles-then one team may wind up with a disproportionate share of assigned work. The key here is to understand that creating (or importing) a standard will partition the project-that's the whole idea-and so it's imperative that the partitions that get created are aligned with the natural divisions of the project itself.
Implementing a standard requires, first and foremost, an applicable standard. In the case of technical interfaces this means establishing an agreed-upon interface. For the most part this can be left to the development team. It will fall upon you as a CM specialist to find out about interfaces if there is an organizational component. When a technical interface is also an organizational interface, you will have to document it as part of the CM plan, and set up procedures for negotiating changes to the interface. If your job also includes a ‘build' or ‘integration' component, then you may need to keep track of internal interfaces between sub-teams or between technologies. Depending on the size of your project, you may want to impose formal interface controls. Formal languages, like IDL or UML, can be your friend here. The interfaces themselves should be owned by development. But you need to know when they are changing, since the risk of "collateral damage" (broken builds, HSI failures, etc.) is quite high.
Implementing a process standard also requires an applicable standard. It can be harder to know when a standard is applicable, and even harder to make the adaptations required to implement the standard. If you don't already have one, consider hiring a Subject Matter Expert (consultant) to help you with the implementation. The real success or failure of a process standard requires buy-in from the project team, training, and easy compliance.
Getting buy-in is a simple (not necessarily ‘easy') proposition: explain the problem, and explain the solution. Losing buy-in is just as simple (and very easy), so you need to be right. Training is one of the more difficult areas. I don't know why, but organizations that will spend tens or hundreds of thousands of dollars on a software package to help implement a process standard will turn around and refuse any attempt to establish a training or compliance program. The word for these kinds of packages is ‘shelf-ware.'
Last, and probably most important, is easy compliance. It is very easy to comply with a process standard if it is done for you automatically. Consider the difference that payroll withholding makes for retirement and health-care programs. Before the popularity of IRA and 401(k) withholding, few Americans made a consistent effort to save for retirement. But when it became possible to silently and automatically set aside money for retirement plans and insurance, participation rates skyrocketed. This is "easy compliance." If your process standard is built in to a part of the system that users already know about, they will comply simply and naturally by doing what they already know to do. If your process standard requires a steep learning curve and signing on to a new system in order to comply, expect problems.
Costs of implementing Formal Interfaces & Standards vary. A technical interface is usually very low cost, requiring a series of meetings and some development hours. A process standard can range from low to high cost, depending on the amount of reorganization required to comply. Obviously, training and automation will raise the costs. (Not training or automating will raise costs even higher, but they'll be hidden costs. See the "No CM" article.)
Implementing a technical standard or interface requires an understanding of the architecture or design of the system. For a system being built from scratch this understanding can be hard to come by, especially if the new system is not in the core specialty of the organization. Failing to understand the problem can lead to an inadequate or wrongly-positioned interface (as in the database example, above). A similar understanding is needed to avoid work load imbalances, as mentioned. Implementing a standard, be it technical or procedural, requires a negotiation to establish the boundaries and fine details of the standard. During the early period after implementation, some kind of update procedure should remain in place to allow for ‘fine tuning.'
An additional requirement for technical interfaces is a solid test plan. Part of establishing a technical interface is establishing a division of responsibility. This enables both sides of the interface to proceed independently-one of the key benefits of Formal Interfaces & Standards. When a problem occurs across an interface, it can lead to finger-pointing as each team tries to establish that responsibility for the problem lies on the other side of the interface. A thorough test plan, especially one implemented early in the development cycle, will prevent this. Test cases are a good tool for exploring a technical interface to ensure that it is complete, so this requirement should be relatively painless to satisfy.
[1] In a past life, I worked for a company whose products were always identified with designations like AB-1100 and XYZ-350. As a joke, I wrote a "ROM size estimator" that could take product design documents from the Marketing department as input, and returned an estimate of the amount of ROM needed. The algorithm was based on the knowledge that marketing always reduced features until the XYZ-350 type products fit in a ROM of 2 megabits, while the AB-1100 type products were more expensive, and could then have bigger (4 megabit) ROMs. So the tool searched for the first string that matched either of those patterns in the input, and printed the resulting number along with the caveat that "certain of the ‘extra' features may get dropped for performance reasons." Marketing found out about the tool, and demanded access to it, and so the tool became a standard part of the product development process.
Years after I left, I got a call from my replacement offering a consulting contract if I would come in and update the "natural language parser" in the tool, since it was consistently producing low estimates. I let him in on the secret but rather than carry on the tradition of
R&D wizardry, he chose to let the cat out of the bag. I take some satisfaction from the fact that the tool had a useful life of nearly a decade, and even more satisfaction from the knowledge that R&D made him perform the ROM size negotiations with the Marketing group himself, since he ratted everyone out.
