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 :)
No comments:
Post a Comment