There exists a certain class of small, flying insects notable for biting voraciously and for being invisible to the human eye. Collectively, these incredibly irritating pests are known as "No see ‘ems". It is obvious when someone is attacked, since they will stop what they are doing, yell, and then wave their hands in the air near their head. What better name to give the technique of not using software configuration management, then, than “No CM”?
In my years as a traveling consultant, I have learned to recognize when a project is using “No CM” by observation. Occasionally managers and team leads will stop what they are doing, yell, and wave their hands in the air near their heads. There isn't much more to describe about the “No CM” technique.
Don't confuse using “No CM” with using the wrong technique or doing a poor job at CM. While you may be tempted to cry out, "It's like were weren't doing any CM at all!," the fact is that even a little bit of CM can go a long way towards addressing problems. Of course, doing a bad job of CM can sometimes be fatal.
The advantages of “No CM” are simplicity and low cost. Doing this simply requires suppressing the urges of every professional team member to install some kind of CM system. A classic approach is to postpone the implementation of CM indefinitely, using an inoffensive justification such, "The project hasn't gelled enough yet." This placates the young and enthusiastic, while appealing to the laziness of the older and more experienced team members.
One disadvantage to the technique is the eventual perception that every single member of the leadership and management hierarchy are incompetent buffoons. It would be easy to itemize other disadvantages but, frankly, there aren't many disadvantages that would not be on the list. Let's just say that using “No CM” causes every terrible thing in the world and leave it at that. The waving of hands happens when a CM-related problem occurs. Typically, that happens before lunch (every single day.) The build fails, the tests aren't run, a problem that was found and fixed suddenly reappears-you know the problems. If you're reading this, you already have some idea what CM is for. There aren't any prerequisites or requirements for implementing “No CM”, other than keeping people who know better from implementing some kind of CM system behind your back. Costs are fortunately low, as it costs absolutely nothing. There are no license costs, no capital investment, and no staffing requirements. You may find that other costs skyrocket, but it's hard to tie specific developer-, tester-, and manager-hours spent fighting fires to the lack of CM.
Monolithic Development
Monolithic development is what is done before adopting another technique. When all of the code is a single hierarchy, or when all the sub-hierarchies are managed using the same process, release labels, milestones, and the same tracking fields, that's monolithic development. It could be called homogeneous development, but that suggests a level of consistency that is usually missing from a monolithic project when it gets large.
Monolithic development is a lightweight CM technique: it is easy to understand and easy to implement. It can be quite effective for small to medium sized projects, especially projects with few or no branching requirements. Because of the low complexity, monolithic development can be implemented with any CM tool (yes, even SCCS) and it is easy to automate. A good example is the source code for the X windowing system-up until R6, the source code was delivered in a single tree. All drivers, libraries, and programs are released with the label of the entire system.
The lockstep approach of monolithic development can sometimes be a disadvantage. Components that are ready to ship early get delayed, while components that are not ready for delivery get aborted or shipped prematurely. As a result, overall product quality can be inconsistent. Basic CM data, like the list of changes in a particular release, tends to grow as a function of the size of the code base. For large projects, this can result in data sets too large for comprehension. Ad hoc partition of the data, by target or defect impact area, becomes necessary.
Frequently, a single monolithic project can be broken into a group of independent monolithic subprojects. This is the current approach of most Linux systems: the gcc version is independent of the perl version, which is independent of the OpenOffice version. This system works for subsystems and packages that are truly independent.
Problems begin to appear when the subsystems are not independent. The various Linux "distros" are formed around a core of packages that are interdependent. This is where the "separate monolithic" approach fails and the need for something more sophisticated appears. The standard Linux approach is the Software Assembly technique (discussed in a future article). The point, though, is that monolithic development is adequate for a significant amount of software development, even when the software components being developed have to interact with each other.
There are no pre-requisites or requirements for implementing monolithic development. Instead, this is the standard for all projects until and unless a different technique is adopted. Costs for this technique are minimal. Because it can be implemented simply, and with any CM tool, the costs will remain low until the complexity of the system begins to exceed the limits of the technique. This upper limit can be surprisingly low in an enterprise environment. Having multiple locations, teams, technologies, or targets will increase the apparent complexity and will cause increased management overhead. The various Linux package management systems are an example of this overhead. It isn't impossible to deal with, but it isn't possible to not deal with it, either.
