Word about task-driven configuration management

Recently I read an interesting post that attempts to explain how configuration management process has evolved from “file-based” into “task-based”; and am writing mine as some of the opinions expressed there are arguable.

First of all, the concept of task/feature/change request artifact associated with the changes to code is not new; first commercial CM system, CCC Harvest (dating from mid-70s) already employed this concept; and the current version of the software is still built around such artifacts. Thus the idea of configuration management process driven by the change artifacts rather than by the changes in code files is every bit as traditional.

Another misconception is that configuration management using files-based version control alone is simplistic as compared with task-driven CM. Branch/merge model, labels (snapshots etc.), concurrent check out and other concepts that are file-based provide for pretty flexible environment, and many of the tasks attributed to task-driven tools are achievable (as illustrated, for example, by Perforce). 

But it is certainly intriguing how nowadays for most CM tools the integration with meta-data artifacts other than files (however they are called - tasks, CRs, defects etc.) became one of the most important and requested features.

Personally, I have a theory that tasks-driven approach become more popular due to the changes in the way software development is done. While task-driven process was available for years, usually it was an integral part of a rigidly formal structure. The distance between defect filed by the customer support and developer who handled the bug was huge and involved multiple tiers, and smaller shops just did not have the resources required for such multi-tier formalized setup.

But in recent years, development become more and more “agile” (for the lack of better term), and the “path” between code and related artifacts become significantly shorter. And the process itself changed as well – perhaps that’s why the tools that worked well for enterprise in the past (CCC Harvest or IBM Rational ClearCase/ClearQuest) find it increasingly difficult to compete with less formal and more flexible competitors. Microsoft Team Foundation Server is a good example of the tool that can fit into enterprise environment but is still sufficiently agile to be a valid choice for less formal one.

There are some things in TFS that you can achieve by using work items in conjunction with source controlled files:

• Associate work items with checked in files (and enforce the association using check-in policy); that way every set of checked in files has bug, task, change request etc. aligned with it
• Establish what work items are contained in specific build (based on changesets contained, work item – changeset associations and build labels)

However, there are things that are not available (out of the box), for example

• Merge changed files from branch to branch based on work items
• Get file versions based on work items (f.e. get me versions associated with bug fixes X, Y and Z)
• Partition file revisions according to the work items state

Important as they are, the missing features hardly pose insurmountable obstacle in TFS adoption (of course, unless you hit some political snags along the way – you know, of the kind “if X is not supported exactly in the way I want it, we are not buying it”). If you believe otherwise, I would be very interested to hear about it.

(Let’s not) blame the other guy

I did some general research on SCM tools lately, and one fact I found interesting was the amount of negative information floating around (no matter what tool you are looking at). What’s interesting about it is that in most cases the negative zeal seems to be misplaced. And here is why – what I know from my personal experience, blaming the tool is usually the symptom of something else lurking behind. So being positive guy that I am, let me share my thoughts about “something else”.

First problem that comes to mind is selecting the wrong tool from the start and then blaming it.

With all white papers floating around, and trial versions available (not to mention sales persons ready to do circus dance at your office), it is still the easiest thing to do. People do it by a) assigning the wrong person to do feasibility assessment, b) compiling a list of wrong requirements or c) making the decision based on political/financial motives alone. Those are just a few reasons that come to mind; I am pretty sure anybody who worked (or better yet, consulted) for multiple companies can add more. And mind you, when I am talking about “wrong” tool I mean “wrongness” on a great scale – choosing system without offline support for largely distributed work force with limited connectivity, lacking of the integration to the one development tools that is used by everybody etc. Things of that scale usually cannot be fixed internally no matter the resources available.

Choosing the wrong SCM (or looking at bigger picture – ALM) tool may result in different outcomes. Three outcomes I have personally seen are: dump the tool and do re-assessment (extremely rare since somebody has to take the blame and requires understanding that the tool is a wrong one early on), readjust internal practices to align with the tool (also relatively rare since internal practices usually have more champions that any new tool, regardless of their merit) and make a do with what is there.

In every case there will be frustration abound, and some (or may be even most) of it is always directed towards the tool.

While choosing the right tool is undoubtedly important, setting up the right process is even more important. By process I mean general set of SCM practices that may include software design, development, maintenance and release; whether these practices are formalized and documented is not material.

Let’s assume that the well performed feasibility study allowed your company to acquire the right suite of tools; i.e. the company managed to avoid “wrongness” on a large scale. The pilot project was set up, outside consultants were hired to provide inside knowledge, pile of documentation was compiled. Does that mean the process is right? Not really. The groundwork may be there, but whether the process is working still remains to be seen. 

The only way of understanding whether process is working is continuous monitoring; the only way to make it work is continuous adjustment. Same as in software development in general, it appears that being agile pays better than being know-it-all-right-from-the-start.

The signs showing that the process is not working correctly are many and may be monitored with relative ease. One such easy to detect sign is a developer bitching how it is impossible to work with YYY (while with XXX everything was a breeze). Countless cases of such “issues” may be found by searching for "YYY sucks” on the WWW, though sometimes the reason is case of the "wrong tool" (it is not always easy to distinguish what is the reason – find one extreme example here; I think that one combines wrong process, wrong tool with a touch of good old RTFM advise applicable for a good measure).

Adjustments to the process should follow the signs and eliminate the bottlenecks by healing the cause – whether by developing custom utility to provide automatic generation of release notes, by training your developers in the art of branching concepts or by chucking your carefully crafted (theoretical) workflow in favour of less elegant but working one. The mantra of “developers, developers, developers” is well applicable to SCM process (just do not forget to change the words every now and then to “release managers, release managers, release managers” etc.); making everybody happy or at least content is the best metric of well implemented process.

My purpose in writing this lengthy and somewhat generic post was this – when one has an urge to write spiteful post about certain SCM tool (be it TFS, SVN, Perforce or whatever), it would really help to stop for a moment and deliberate. I am willing to bet that in majority of cases either the tool is being bend to deliver something it was not intended for or the process built around the tool is less than perfect (and I leave out the eternal cases of RTFM). Myself, I am proud of never blasting any SCM tool in public :)