Home 
CM Journal Articles SCM Techniques: Kicking Off
CM Journal Articles SCM Techniques: Kicking Off
|
 Patterns are a
well-understood concept in software development. Thanks to Steve
Berczuk and Brad Appleton, they are a part of the SCM vocabulary as
well. So far, the SCM pattern vocabulary is relatively low-level,
concentrated on describing repository layout, branching strategy and
the like. The techniques discussed here are not patterns-they don't
have the required structure, and don't provide prescriptive formulas
for implementation. Instead, these are discrete, recognizable methods
of software development or software configuration management.
Configuration management is a discipline that connects to every single part of the software development process. This means that CM affects all parts of software development, but it also 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 may help your project overcome certain CM challenges. Making radical changes 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. This series will talk about twenty-two techniques, from five categories. Here they are. Ceremonious Techniques
No See ‘em 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, scream, and wave their hands in the air near their head. What better name, then, to give the technique of not using CM? In my years as a traveling consultant, I have learned to recognize when a project is using No CM by observation: occasionally the managers and team leads will stop what they are doing, yell, scream, and wave their hands in the air near their heads. There isn't much more to describe about the No CM technique-it isn't a technique, really, so much as a basis for comparison. 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. Ask the former employees of the Topps Meat company.) The advantages of No CM are simplicity and low cost. Doing No CM 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 like, "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 global warming, kills children and kittens, and causes impotence and cancer, 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-No CM 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 you do before you adopt another technique. When all the code is a single hierarchy, or when all the sub-hierarchies are managed using the same process, the same release labels and 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. (Current X systems, with Qt and competing desktop managers like GDE and KDE, have started to break up the monolithic package.) 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. Looking Ahead I'll try to cover two techniques each month, but there's no fixed order. If you have a particular technique you'd like to have discussed earlier, drop me a line. If you have a technique that I haven't identified, please, please let me know-I don't claim this list is exhaustive. Austin Hastings has spent more than 20 years in the software industry. He has been a developer, system administrator, CM specialist, manager and consultant. Currently he is principal consultant for Longacre, a software CM and process automation consultancy. Austin lives in the southern part of New Jersey (the garden of the Garden State) but travels the world helping to keep software under control. Contact him at Austin_Hastings@Yahoo.com, or through CM Crossroads.
Set as favorite
Bookmark
Email this
Hits: 5139 Trackback(0)Comments (3)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... SueB, I'm glad the article works for you, but I'm sorry it's that section.  |
SueB
said:
 |
... I just love the "No See em" portion of this article. It provides exactly the envirnoment that I see. Thank you....it made it realize another way to see the lack of CM. |
gkawaja
said:
|
... I would love to use the "No See 'en" in a class with an picture of a Daily Project Meeting. I'm looking forward to the next installment. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
