First, there’s the Telelogic User Group Conference 2008, in Austin, Texas. That’s obviously focused on Telelogic, and on CM Synergy and Telelogic Change, or whatever it’s called this week. Since I spent a fair amount of time during the initial implementation of LDM wishing that I could use the kind of one-off ad hoc queries that Change is so good at, I suppose it’s appropriate.

The second conference is CMconf.DE, in Munich, Germany. Sadly, it will be a few weeks after Oktoberfest — otherwise there would be no hope at all of getting hotel space, I suppose. I’ll just have to wander around looking for any leftover barrels of beer, slightly-used lederhosen, or oompa bands that I can scrounge up. The theme is the same — presenting LDM and some other approaches to database CM.

In both cases, the time constraints are really biting. LDM needs an understanding of the other ways to do (fail at) database CM before I can really talk about it, and I’m pretty sure that most people haven’t thought beyond one way, if that many. So I’ll be speaking really, really fast, and inviting attendees to stick around afterwards to talk about it.

Anyway, that’s two continents in a single month — not bad, if I do say so. If I could just find a conference in India, China, or Israel, I could sweep the northern hemisphere.

In fact, the upgrade (and the site outage) lasted for 10 days. The new site is (I think) running Joomla 1.5, so it’s probably a big improvement behind the scenes. (Patrick Egan, site founder, mentioned that this was an important reason for the upgrade.)

But with all the awkwardness of the upgrade, I’ve had to track new posts by querying for them with “New Posts since last logon” or “New posts in last hours” type requests. The results include all the new posts in all the forums–ClearCase, General, Dimensions, etc. Like anybody else, I don’t care about most of the forums (just the ones I do care about).

As a result, I’ve noticed that there haven’t been many new posts. That’s gradually changing, but in the two or three weeks after the upgrade, there weren’t very many new posts at all. I hope this is because the 10 days of down-time really depressed the user base, but that things will snap back.

But I wonder, because a lot of other sites have user communities that are strongly invested in their site. I can’t imagine SitePoint, for example, ever going down for 10 days. But if they did, there would be 400 posts the first day they were back up, most of them talking about the outage and what happened while the site was down.

There are a couple of alternative explanations. One is that there aren’t that many users at CM Crossroads. This is contrary to the numbers published by the site administration, and definitely contrary to the site’s page ranking, per Google. Another explanation is that nobody cares–that CM specialists aren’t spending that much time participating in their own professional development. Or, maybe it’s a cultural thing: CM folks are using the site for the Journal (and for CM Basics, the other monthly) and not paying attention to the forums. Finally, it could be that the new site is turning users off. If the users are coming back, but being driven away by the new site design, it doesn’t bode well for the future, but it would allow for continued high traffic with few posts.

None of these is particularly palatable, and I don’t really have a clue which, if any, is true. I kind of have to hope that the “temporarily depressed” explanation is the right one, since all the others are worse. But I sure hope that things get back to “normal” soon.

I’d like to think that I’m the guy for writing SCM tool reviews. I’ve been a vendor rep, so I know where a whole bunch of the bodies are buried. I am independent, so I don’t owe anybody anything. I have done the developer job, and the CM guy job, and the admin job, so I know what those guys care about. But I’m scared.

The fact is that there are a lot of details in any SCM tool. I spent two weeks reviewing SureMerge, which when you come right down to it is a glorified version of diff, for pete’s sake. Most SCM tools have some kind of diff utility built in as an afterthought. If it takes two weeks to do the afterthought, how many months would it take to cover the check-in command? When I wrote the case study that discussed the development of Longacre Deployment Management, I mentioned that the first-cut questionnaire we used for culling vendors contained about three hundred questions. Guess how many paragraphs that would translate to in a review.

One thing that seems obvious is that different vendors are at different points on the spectrum of object-version versus change-set based development. Some of them allow, or require, you to select which model you want. A bunch of them want to provide those functions, but call them something different and pretend that nobody else has them. Another thing is that the vendors, and even their customers, are at different levels with respect to integrating change tracking tools with version control. And with integrating requirements tools. And with integrating build tools. And deployment tools.

I’d like to have a fair measure. Some common set of activities that I could do for each tool. A benchmark, if you will, that allows the reader to hold two reviews up side-by-side and see the strengths of one tool versus another. (Ditto, weaknesses.) But there is the real risk that what challenges one tool will be a built in subfeature in a second level menu of a more advanced or more integrated tool. For instance, CVS doesn’t have any kind of change request tool integrated. There are some hacks. There are some other “products” that integrate CVS. (cvstrac, for one.) What to do? Accurev doesn’t have a CR tool, but they integrate with just about everything. MKS offers a separate CR tool, and makes it trivial to do change-set based development. Rational sells it as an add-on.

The point is, a “standard review” has the real risk of not mapping well to the product features. My SureMerge review was built around exploring the product, and deciding which features were worth mentioning to the readers. Some of them made it, others didn’t. A “custom review” runs the risk of spending a lot of time talking about worthless features because that is what is interesting about the particular tool. (I’ll mention here that a nice lady from PlasticSCM asked me to write a review of their 1.0 product. I declined for pretty much that reason—the product was too simple. Now they’re at version 2.0, and have a lot of new features. Surprise!)

Another point of concern is that some parts of reviewing a tool need other users involved. Access control, security, and privilege issues need multiple users. Too often, demo or review software has these features disabled or dumbed down. It’s hard to be in conflict with yourself. It’s hard to create any kind of log-jam with only one user. (And of course, it’s a considerable pain in the tuchus by yourself.)

So imagine a “standard” review of CVS: I try to create a set of change requests, and …

This sort of suggests that there maybe should be some kind of onion-peel review. The tool is what the tool is, and the reviewer peels away the standard layers until the tool starts to be relevant. But how much value does that even provide? If I’m writing a review of CVS, and the reader needs MKS Integrity or Telelogic Synergy, whose time is more wasted—mine or hers?

Bizarrely, then, the right first step seems to be to write a book (No, this isn’t a joke.) about SCM. Then match each tool against the book. But that’s crazy talk. The next best thing to writing a book, of course, is getting somebody else to write a book for me. There’s two ways to get there: pick on some standard text, or “web 2.0″ it. I can’t think of a useful “standard book,” so the web 2.0 approach doesn’t seem too bad. Perhaps the approach should be to create a wiki, fill it full of standard questions, and then encourage the users to answer them. Of course, most users aren’t very good writers, but isn’t that what wiki-gnomes are for? Of course, that puts me almost in competition with CM Crossroads, a position I don’t think I want to be in.

Maybe the right answer is a little of both. Create the wiki, then “edit up” when tasked to doing a particular review. Take the standard questions, and render them into useful text. Now I’m competing with Gartner. Joy!

If you’ve got some ideas, boy do I need ‘em.

The case study is here, and the technical details article is here.

I’m eventually going to incorporate LDM info as pages here on Doing Better. But for now I’m frantically editing the articles to try to improve their look — CMJ’s article import scripts really aren’t very good at handling a complex document.

It’s the start of a new year, and that means predictions for the future.
Not content with a twelve-month window, I’ll go out on a limb with some longer-term prognostication. Also, of course, some suggestions on what to do when I’m right. Because everyone else is making predictions, too, I’ll try to keep this light and fast.

Here we go:

Microsoft TeamSystem will kill CM.

This isn’t as bad as it seems. In the short term, of course, TeamSystem will flop—all new technologies suffer a pregnant silence in the year after they come out. This is when various large corporations pay to beta test the product and work the bugs out. Afterwards, the next version is a killer app.

In this case, TeamSystem will provide a platform for understanding what SCM can do. Automated processes, Build automation, Change control, Defect tracking, Earned value, all the way up to whatever starts with ‘Z’, TeamSystem shows enormous promise.

Other developers have provided implementations of task-based development, builds integrated with checkins, etc. Now Microsoft is bringing their enormous market share to the table with a real CM tool. This will set the bar not just for vendors, most of whom already offer some or all these features, but for development shops, too. Because of TeamSystem, every still-employed software manager is going to know about the stuff that CMers have been discussing for years.

SCM will be a commodity function.

One of the effects of TeamSystem will be that build systems become commodity products. Existing systems that rely on hand-crafted scripts that understand the environment and the system being built will be trashed, replaced by inefficient, unoptimized systems that are less capable, less costly, and able to do far more because they will be standards. At the very least, you need to look at Apache Ant or Nant plus something like CruiseControl. Realistically, though, you should be looking at Maven.

CM folks will climb the value chain.

Because so many CM functions—like integration builds, workflow reporting, and impact analysis—are going to become commodity data, CM analysts will advance to a higher productivity level. Time that was spent collecting or refining data will be freed up for other purposes. This is a productivity increase, and like every other increase in productivity it will cost some people their jobs. Others will find themselves doing things that weren’t a part of the CM job description in 2005. Taking advantage of the automated data collection will let more teams achieve more sophisticated development than was possible in the past.

The “active” CM folks—those who participate in the development process—will probably receive these changes as positive steps. Their reporting will be more automated, their scripts will have a better abstraction layer upon which to build, and so the more sophisticated tools will turn them into more advanced, more sophisticated participants in their development organization.

On the other hand the “passive” CMers—who have allowed development to bypass them, substituting simple release forms and reports for involvement in the development cycle—are going to get nothing but stress from these changes. The pressure to produce more for less money and the increasing productivity from advanced tools will produce engineering groups that do more CM functions internally. There will be more of these groups feeding the same one or two “CM gurus” reports generated by the new generation of tools. Sorry, folks, but you’re going to be spread thinner and thinner.

Traditional CM vendors will attempt ITIL integration.

CMers haven’t done the best job integrating the ITIL folks into our community, probably because so many shops fall short when it comes to tracking the kind of data ITIL needs. The next year or eighteen months will show the beginnings of convergence as CM vendors (not Microsoft—they’ve made their big effort for the decade) begin to try to position their extant change and defect tracking products into the ITIL space.

Microsoft is probably the best of all the OS vendors when it comes to automating the OS patch/upgrade process. Sadly, however, there isn’t yet a standard mechanism for reporting this kind of information. SMS can, with help from the administrators, install most OS and key software patches, but reporting and interdependency data is not there yet. Look for the various *nix vendors to begin providing a similar patch installation mechanism, and to go one step beyond Microsoft to provide complete patch reporting as well.

From a CM perspective, whether it’s an ITIL CDB[1] or traditional CM SDE/TOE[2] monitoring, being able to automatically obtain a precise description of the state of a platform is crucial. So far this has required different mechanisms for different operating systems. Look for OS vendors to incorporate the best ideas from ITIL product vendors in the next year. The new Microsoft Longhorn release will almost certainly provide such an interface. Assuming that Microsoft provides a standards-compliant API, other OS vendors will likely simply copy the Longhorn interface. (This is a questionable assumption: Microsoft is famous for being stupidly non-accessible for little or no good reason.)

Sarbanes-Oxley will spread to other countries.

Sarbanes-Oxley is the name of a U.S. law that requires change tracking for all significant financial elements in public corporations. The public grace period is basically over, and most accounting/financial organizations have staked out their positions on what the law actually means. To date there hasn’t been much legal action to provide judicial interpretation. (This is a good thing: “not much legal action” means “no large corporation has imploded.”)

For non-U.S. readers in Europe and Canada, a prediction: You’ll have your own version of SarbOx within three years. It will be sooner, of course, if one of your large corporations self-destructs. But three years even if not.

Sarbanes-Oxley will be tested in the United States.

SarbOx has been one of the driving forces behind the widespread adoption of the ITIL. More and more IT managers are coming to understand that their sophisticated MRP, ERP, and/or CRM systems are not black boxes—that they’ve got a staff of coders frantically trying to squeeze more profit from the business using software. And that, of course, means that the CM Office can offer value to IT as well as R&D. If you aren’t already doing so, I predict you’ll have some pretty surprising meetings with your IT department this year.

The important CM aspect to SarbOx is that it requires change controls on systems that have a significant impact on the financial statements made by a company. The act provides some guidance on this, but only this year is progress being made towards consensus on what is and is not required.

As a case in point, the PCAOB[3] recently instructed auditors to begin telling their clients which controls were not, in fact, necessary for compliance. However, the difference between “we feel this is not necessary” and “this is definitely not necessary” comes from judges, not accountants. Until case law exists, no auditor will feel truly comfortable with ignoring controls.

And case law comes from court cases, which can only take place when someone goes to court. While there is always a certain amount of legal harassment from the shareholders, I predict this year companies will allow some SarbOx-related lawsuits to proceed to trial in order to get basic case law established without the anti-corporate hostility and angst that surround the massive disasters that make for definitive case law but tend to require thousands or millions to be injured.

Consider two examples, one real, the other hypothetical:

Example A: A corporation outsources financial reporting to the Phillipines. An accounting center is established, WAN connectivity is purchased, and 300 jobs are eliminated in the U.S. while 700 happy Phillipinos gain jobs in a new, 24-hour operation.

Due to other U.S. regulations, the corporation purchases most of the equipment on the local market. This includes localized versions of Microsoft Windows and Microsoft Excel.

The auditor argues that because the center produces reports that contribute to financial statements, SarbOx controls are required. And because both the software systems and the personnel changed, the company should run the two offices in parallel for at least a year to establish that consistent answers are being provided.

Example B: A company has set up a backup data center in a separate complex. The auditor argues that because the backup data center could be used to produce financial reports, SarbOx controls are required. Because fire safety is a significant issue in the tight backup center, photos of the smoke detectors in place with the equipment are required, as are receipts establishing the scheduled purchase and replacement of batteries.

It’s probably obvious to you which of these is the real example and which is contrived.[4] Of course, as a CM professional instead of a financial auditor, you may have a different sense of what controls are for and who needs to be controlled.

No Oscars for ‘Brokeback Mountain’.

Despite all the press, and the Golden Globes, and serving as joke fodder for every comedian and talk-show host in the United States, ‘Brokeback Mountain’ won’t win any Oscars that anyone cares about. (It might win one of those “Best technical lighting of live animals against a CGI background in a major motion picture” awards that none of us understand or care about. But that’s it.)

What does that have to do with CM? Nothing. I’m out of CM predictions. But what better way to wrap up something none of us will care about in a few weeks?

Super Bowl XL: Pittsburgh 24, Seattle 10.

Okay, now I’m really out of predictions.

Footnotes:

1. Configuration Database

2. Standard Development Environment / Target Operating Environment: the platform used for development or execution.

3. Public Company Accounting Oversight Board—a quasi-governmental agency established by the act.

4. The first was hypothetical, the second real.