Gargh!

Okay. Don’t get me wrong, I have nothing against you telling me how your tool addresses the problem at hand. In fact I really want to know how your tool address the specific problem being posed. If it takes too long for a short post, link to a white paper or an article or post on your website/blog. But please, please, please, make sure that whatever you point to really does address the problem being asked about. Don’t just link to some random marketing bullshit about your product. The person asking the question wants to know how to solve a specific problem, at least do them the curtesy of answering with something more enlightening than ‘buy our product’.

What if the question is more general? Well, again, add to the conversation. Answering with ‘take a look at my tool’ just makes you look like one. The only question that should be answered ‘take a look at my tool’ (unless you’re in a dodgy ’70s porno) is ‘can you please list tools in the X category’, and only then if your tool is firmly in the X category (not in the ‘could be used in the X category, if you have a really good imagination or are willing to invest an additional one billion dollars in customising our tool’).

Vendor input on forums is, at its best, very useful and helpful. Sadly it is too often lazy, irritating, and unhelpful.

Here’s an example of what I mean, posts on forums where claims like the following are made.

Eliminate the number of potential risks threatening database development and deployment by 60% and reduce deployment costs by 95%.[sic]

What does this even mean? Reduce what deployment costs? Against what baseline? Is this an average observable saving, if so, where’s your supporting data?

Which development and deployment risks are you talking about? Which of these risks does your tool mitigate? How much effort is required to mitigate those risks? Is it really worth it?

In this particular case a link was provided to a press release. Still no sign of any substantiating data. What about their web site. Nope. Not a thing.

Or how about this one,

AccuRev will eliminate up to 90% of normal merge activity.

What is ‘normal merge activity’? On what basis does this person (who was a representative of the company) make this claim? 90%? At first blush this is a remarkably specific claim (read it carefully and they’ve included those marketing weasel words ‘up to’), it must be based on some pretty sound data. Or maybe not. Maybe it’s just one of those made up statistics again. Yeah. That’s what it was. I contacted the person involved and they continued to be vague and push out marketing speak, but failed to come up with anything more substantial than ‘Our customers have typically seen between 70-90% reduction in merging activity.’ Another unsubstantiated claim, and even if it’s true is still seems to be based on perception and hearsay rather than hard numbers. (Oh, and 70-90% is a heck of a wide range and boldly claiming 90% in the original statement is misleading even if you accept the more qualified range.)

Ah, you say, but it claims ‘up to 90%’. Well that’s BS too. I can save up to 100% by not doing any parallel development at all. No merging, no merging costs. Alternatively, if your merges are normally done by a bunch of alcoholic monkeys, then I guess saving 90% is possible by using properly trained software engineers and following good branch and merge practices.

And if they save you 0%, well, that’s up to 90% too. 90% is just a made up number plucked out of some marketing guy’s butt.

Now, I understand that marketing people like to make these claims, they look impressive on paper, but they’re absolutely useless to anyone with an IQ greater than their shoe size who is trying to evaluate tools. Frankly, if you’re going to make ridiculous, unsubstantiated claims then I for one don’t want to be doing business with you. I mean, if you can’t be up-front and straighforward at the beginning of our relationship, how trustworthy are you going to be when it matters? (I’m tired of hearing people say things like, ‘but the sales guys said this tool would solve this problem’. Really? The sales guys said that did he? And you didn’t think to verify that before you bought the damned tool?)

The stock reply of course is, ‘but everyone does it and if we don’t make these claims no one will pay any attention.’ Really? You’re falling back on the ‘everyone else does it’ defence? If that’s the best you have then, once again, I’m not sure I want to do business with you. (As my old Mum says, ‘if everyone else stuck their head in an oven, would you?’)

Another justification goes along the lines, ‘but there is no good way to measure X’. Now that may be true, but that doesn’t give you license to just make shit up. If there’s no good way to measure something then claiming to reduce that something by a specific quantity is… well, bullshit. ‘Oh yes, I can reduce your unspecified cost by 53%.’ How the hell can you say that with a straight face?

These sort of unfounded claims really make my blood boil. So I’ve decided that whenever I see unsubstantiated claims I’m going to call them on their BS. It’s simple enough, just reply to their post asking, ‘I am interested in your claim that X will say me Y%. I wonder if you could provide us with the data on which this claim is based, I’m sure the community will be interested to see the methodology and metrics you used to gather this data, as well as the data itself. In an industry where such benchmark studies are rare, or at least seldom published, your data will be most useful.’

I bet not one will reply with anything remotely like an independent data set that substantiates the marketing claim. And if they do, all the better because I for one would love to see this sort of data collected and published.

Remember, marketing statistics and claims are generally worth exactly what you paid for them. Zero. And I have data to support that.

E-mail. It’s a nightmare. Too much spam. Too much irrelevant crud. We should all be cursing the day e-mail was invented.

Strangely I suspect most of you would agree wholeheartedly with both of these statements. I know I do.

So which is it; angel or demon? Well, both. And neither. When it comes to e-mail and projects though it is too often the demon and too seldom the angel.

I’ve noticed on many occasions that projects can be killed, or at least severely wounded, by e-mail. Things progress something like this.

E-mail is used to communicate among the various team members. Person A asks person B for some information. Person B is slow to respond, so person A e-mails them again but this time CC’s in their own boss and person B’s boss. Now, neither boss has the solution to the problem or the information A wants from B. The intention is obviously to prod B into action by making the bosses aware of the request. The problem is, now three people are receiving the e-mail instead of just one.

The bosses have to read the e-mail, just in case it’s important (after all, they don’t want to be the cause of delays, nor do they want to be overlooking important decisions). Sure, it only takes a few seconds to open the e-mail and scan it, but that’s a few valuable seconds that could be used productively instead of filtering irrelevant e-mail.

Person B responds to A asking for clarification. Of course B uses Reply All because they want the bosses to know that it’s not their fault there’s a delay. More CC-mail.

On any substantial sized project this ridiculous CC-mail game leads to a huge amount of CC-mail in the system.

CC-mail is like cholesterol, it clogs up the project communication arteries making it harder to keep useful information flowing around the system. I’ve seen e-mails exchanged, ostensibly between two engineers, that have ten or more people CC’d in to the conversation. None of those people are directly relevant to the exchange they are CC’d in purely as a defensive measure, ‘sure, I told you this was a problem in that e-mail’.

It drives me nuts and some projects just grind to a halt as people either overlook important details in the maelstrom of irrelevant CC-mail or they spend so much time each day wading through e-mail that there’s no time for productive work.

So, what’s the solution?

One productive alternative is the project wiki. Carry out ‘public’ conversations on a project wiki. If you really feel you need to draw your bosses attention to an exchange then e-mail them once indicating the relevant wiki page/discussion. If they feel it’s important they can add themselves to a watch list on that page and receive notifications, or they can drop in when they have a few moments to see how things are progressing. The wiki provides a complete trail of the discussion (assuming you’re sensible and use a wiki that maintains a history of page edits), so if things do turn nasty each party has a good record of what happened —although if your project suffers from that level of mistrust it’s probably already in decline to oblivion.

Wikis also make the exchange public, meaning anyone can jump in and help solve the problems, and that’s what everyone really wants.

Keep e-mail for very specific communications and cut out CC-mail cholesterol from your project’s diet. Trust me, you’ll feel better for it.

Mark – you contact Patrick and I directly on a regular basis. I was in the middle of conducting live interviews and did not have time to follow up with Patrick to see why your IP was blocked. You also know that we have been getting spammed daily and we are trying to resolve that problem. Completely untrue that you cannot contact CM Crossroads and you know that.

Fair enough. It seems Bob thinks I was being unfair. The tone of the comment even suggests I was lying with malicious intent. It certainly contains some misleading information and factual inaccuracies itself.

Okay. I had written a rather long response defending my position. However, rather than post that I’ve decided to simply write the original post but with more content; a full account of proceedings and full disclosure (this seems to be what Bob is complaining is missing from the original). I’ve left the original so you can see the difference.

Before getting stuck in, I should just say that the original was simply a quickly dashed of blog post expressing my frustration. This one is much longer (I have some time to write it, unlike the original) and it is a slightly more thorough treatment of the topic.

To be honest, I’m not sure Bob’s going to be any happier with this account, but it is a complete account this time so I don’t think he can complain I’ve concealed any material facts (well, none that I know about. Bob seems to know better than I what I actually know, so perhaps he’ll tell you what I know, even though I don’t, or at least I’m not aware I do). [That last parenthetical minefield will become more meaningful by the end of this post.]

I’ve been receiving e-mails from CM Crossroads for some time telling me about the upcoming ALM Expo. They’re free. I don’t need to travel to attend. So, I don’t much care that presentations are basically product demonstrations. Hey, it’s an Expo, what were you expecting. It’s good to keep an eye on the various ALM tools and their noteworthy capabilities and this is as good a way as any of covering a lot of ground quickly.

So, November 8th I receive the following e-mail (characteristic of all the e-mails, it just happens to be the one that arrived to remind me that the Expo started the following day):

ALM Expo 2011 – Starts Tomorrow!

Dear Registrant,
Don’t forget – you’ve registered for the ALM Expo Virtual Show,
which starts tomorrow at 8:30 a.m. ET!  Start your day off by
viewing the Better Software keynotes, streamed live from Orlando, FL.
You’ll also be able to choose from up to 11 hours of presentations
and chat with colleagues and peers. Take a moment to view the
schedule and set your Outlook reminders now! We are looking
forward to seeing you at the event!

The ALM Expo Team

Day 1 Agenda:
http://www.cmcrossroads.com/day-1-agenda

Day 2 Agenda:
http://www.cmcrossroads.com/day-2-agenda

We’ll see you November 9 and 10, 2011!
The ALM Expo Team

Login Info: http://www.cmcrossroads.com/component/user/remind
Password Reminder link: http://www.cmcrossroads.com/component/user/reset

–
Software Quality Engineering
340 Corporate Way, Suite 300
Orange Park, FL 32073 USA

——————————

This is a one time email. But If you wish to update your profile
please use the following link

http://app.streamsend.com/private/Odst/srk/CXUGJyC/unsubscribe/15006423

I duly clicked the link the following day and received a message informing me that my IP address was blocked.

Hm! Perhaps my mistake? Perhaps the link was somehow bad. So I try the simpler http://cmcrossroads.com Nope. Same result.

You will, I hope, notice that nowhere on the e-mail does it warn me this might happen. Nor are there any contact details (other then a handy postal address, I guess I could have posted via snail-mail) that would allow me to ask for help.

At this point I dashed-off my original post.

Bob complains that I could have contacted him directly. And this is true. Had I been in a frame of mind suited to thinking it through, I could have e-mailed him at this point. But I didn’t. I was just pissed that the e-mail didn’t tell me anything useful about who to contact if I had any difficulties. (*SPOILER ALERT* Hang in there though, I DO contact Bob directly in just a short while.)

I received several other e-mails from the ALM Expo over the next couple of days. Each one announcing some highlight presentation and telling me how to log in and find out all this great stuff. The following is typical.

ALM Expo 2011: Orchestrating Agility – Now Showing!

Dear Registrant,
ALM Expo 2011 is now open!

Please join us to view our next presentation, Orchestrating
Agility: Four Steps to Make a Truly Agile Enterprise, sponsored by
Serena: http://www.cmcrossroads.com/day-1-agenda/14219

Please view today’s full schedule: http://www.cmcrossroads.com/day-1-agenda
and bookmark your favorite events.
Don’t forget to set your reminders for day 2, as well:
http://www.cmcrossroads.com/day-2-agenda.

We hope you enjoy the live presentations, interviews and networking
opportunities available.

See you there!
The ALM Expo Team

–
Software Quality Engineering
340 Corporate Way, Suite 300
Orange Park, FL 32073 USA

——————————

This is a one time email. But If you wish to update your profile
please use the following link

http://app.streamsend.com/private/Odst/srk/CXUGJyC/unsubscribe/15014379

See all those links telling me how to get in contact with the organisers if I have difficulties? No. Me neither.

Anyway, around 22:00 GMT on the 9th November (okay, 22:11:49) I sent the following e-mail to editor@cmcrossroads.com (this is the e-mail address that was sending the e-mails out. I completely failed to register the fact that this is also Bob Aiello’s e-mail address as editor on the site).

Would have loved to join you but you’re blocking my IP address, making it impossible.

To his credit, Bob replied with the following about an hour later (okay, 1 hour, 3 minutes and 40 seconds later—I know how Bob is a stickler for details).

Just want to cc Patrick
Sent from my Windows Phone From: Mark Bools
Sent: Wednesday, November 09, 2011 17:11
To: CM Crossroads
Subject: Re: Now Showing at ALM Expo: Is DevOps Practical For Real
World Enterprises?
Would have loved to join you but you’re blocking my IP address, making
it impossible.

(Time discrepancies in the e-mails are due to server time differences, I’m always using the timestamps as they appear on my e-mail headers.)

And that’s the last I heard of it.

So, to recap:

• Got e-mail invite.
• Clicked on link to attend—IP address blocked.
• Went direct to site home page—IP address blocked.
• Wrote brief blog post.
• Sent e-mail to editor (Bob Aiello)
• Received CC message that Bob had forwarded this on to someone else (maybe Patrick Egan)

And that’s all I heard until 11:33 this morning (14th November) when Bob left his comment on my LinkedIn cross-post of the original blog post.

In the interests of full disclosure, I also received, at 11:59  today (14th November) the following CC’d in to a message to Patrick Egan (for sure this time).

Mark’s IP is blocked and Mark claims on a linkedin posting that he cannot contact us.

Bob

Between receiving Bob’s comment (11:33) and just now (17:20) it seems my IP address is now free to contact http://cmcrossroads.com (I checked at lunch time and was still one of the disenfranchised then.)

That then is the full account of what happened. I leave it to you to decide what to make of it.

As for Bob’s comment.

It is absolutely true that the hyperbolic statement ‘completely unable to contact’ was an exaggeration (it’s in the nature of hyperbole) and one that might appear disingenuous or even malicious on my part. I intended neither. I was frustrated and reflecting how I saw the dearth of information in the e-mails regarding remedial action available to users wanting to attend who found themselves blocked. It’s like being sent an invitation to a party, turning up to find not just the door locked by the gates to the entrance of the property locked and no note saying ‘call me on my mobile 0555 1657343′. Instead you leave me to guess how to contact you.

You knew…

Despite Bob’s statement that I ‘knew’ the site was experiencing a spammer attack, I knew no such thing (I don’t even recognise the term ‘spammer attack’ in this context), and am surprised that Bob thinks he knows what I know with sufficient insight to be able to make such a statement.

Sorry Bob, but asserting that someone ‘knows’ something, not matter how assertively you say it, does not actually make it true.

I did suspect (suspect, not know. There’s an important distinction) I was caught up in some sort of DoS attach and a range of IP addresses were blocked from accessing the server (a range that included mine). Okay, a brutal, unsophisticated but ultimately quick, easy to implement and effective means of slowing or stopping such an attack. But one that ultimately creates significant collateral damage.

Quite what me ‘knowing’ this has to do with the issue at hand escapes me anyway. I can see that had I known about the situation then I would have to be a special kind of asshole to subsequently blog negatively abou… Oh! Is that what Bob was trying to imply? I hope not because that would be very unpleasant. I shall assume Bob simply mis-spoke, or that he thought I did know (although it says a lot about his opinion of me if he thought I would write that unqualified post when I knew).

Understand, CM Crossroads actively blocked IP addresses. Going from Bob’s fallacious claim that I ‘knew’ this was going on, I can only assume that they knew they were doing this. It was not something done to them. It’s not something of which they were unaware during the ALM Expo. A simple note on the e-mails explaining that

Some users may experience problems while we combat a denial of service attack. If your IP address is blocked, please e-mail your IP address to blah.blah@whatever.com and we’ll try to get you access as soon as practicable.

Too much to ask?

Evidently.

You’re always contacting us…

I don’t think I contact either Bob or Patrick directly ‘regularly’. In fact I have never directly initiated contact, I always use the CM Crossroads site, which, as we’ve been discussing, I could not use this time.

I’ve looked over all the e-mails I’ve sent to Bob directly over the past four years (yes, I’m one of ‘those’ people who archive everything) and the most recent sent e-mail to Bob was 7th March this year, and that was a reply to an e-mail he sent to me. One e-mail response in eight months is not what I would characterise as ‘regularly’. And certainly not me contacting him. Perhaps Bob means something else when he says ‘regularly’.

Even accounting for my contact and interaction on the CM Crossroads website, I would hardly say I contacted either Bob or Patrick ‘regularly’. In fact, the more accurate adjective I would use is ‘rarely’. Both begin with an ‘r’. Easy mistake I guess. I communicate with them maybe two or three times a year, if that. And then most often in response rather than initiating.

I accept that Bob was busy. In fact so busy that it has taken nearly five days to restore access. Fair enough. It’s really not a problem. I don’t care that much about access to the site or the Expo for that matter. I was not complaining or badgering them about access, more about the complete lack of helpfulness to anyone unable to access the ALM Expo after being caught in the IP blockade. If I had not been privy to information about contacting Bob then I really would have had no way to resolve my issue, and that has to be bad. Doesn’t it?

The weird thing with Bob’s comment is the way it seems to imply that I was being unfair in the original post. That I did have a means of contacting them and as such it was unfair of me to post about being denied access after receiving the invites. As I hope I have illustrated in the preceding account, having direct contact available did nothing to actually resolve the core issue. Nothing. Bob’s comment is akin to  a banker complaining that his name was misspelled in the coverage of the collapse of his bank. Me? I think the mismanagement is the important feature.

Anyway, hopefully, now I have given a full, open account of proceedings Bob will be happier.

On balance, I think I’d prefer the original post myself.

I certainly feel better knowing that I didn’t conceal the heinous truth about my secret, if useless, knowledge of e-mail addresses a moment longer.

A constant stream of emails telling me how cool the ALM expo is and how I am invited to attend.

Shame then that they’ve block my IP address and I cannot contact CM Crossroads. At all.

I assume I’ve been caught in some broad IP address blocking campaign, but this does not make the fact of the matter any less annoying.

This book is not a technical implementation manual but rather a bridge between the worlds of Agile practices and Configuration Management. As such, it can be read be either Agilists wanting to get a grip on configuration management, or configuration managers wanting to understand how Agile projects may be accommodated.

In places I myself yelling, ‘but this should be done on any project, not just Agile’, before recalling that the sole purpose of this book is to offer that bridge between CM and Agile. Much of the advice in the book is good advice on almost any project. The book is useful to any CM practitioner whether applying CM to Agile or not—simply replace the word ‘Agile’ with ‘good’ throughout and you won’t go far wrong.

The book presents two primers; one for CM, the other for Agile. These primers provide a whirlwind tour of each discipline in order to orient the reader to the material in the remainder of the book. Each primer is sufficient that the interested reader will not be lost in later material  while remaining brief enough that they do not dominate.

After these primer chapters Moreira discusses how CM and Agile values work together. This chapter should disabuse the reader of any notion that the two disciplines are in any way in conflict and reassure each side that the other has only the best interest of both at heart.

Chapter five discusses infrastructure in the context of Agile projects, highlighting practical issues such as short lead times between project initiation and the need for infrastructure to be in place to support development which will start much sooner than in non-Agile projects. Some practical advice is offered on delivering infrastructure and in reusing existing infrastructure.

Next, the specifics of CM implementation on Agile projects is discussed. Discussions about the implications of team coordination and locations are discussed along with potential difficulties and possible solutions when dealing with Agile teams that are near– or off–shored rather than collocated.

By far the largest chapter, chapter seven, is dedicated to adapting CM pratices for Agile. Each of the main CM functions (identify, control, report, and audit) are examined from the perspective of their impact on, and benefit to, an Agile project. Particular care is taken to point out where CM practices must be tailored to the Agile mindset in order to accommodate Agile practices. A great deal of the advice boils down to ‘keep it lean’ and ‘do nothing that does not add value’; tenets that apply universally, but are particularly important for Agile projects.

The final three chapters deal with the relationship between CM tools and Agile projects, tool selection, and the application of CM standards and frameworks to Agile projects. Chapters eight and ten are written by guest authors Damon Poole and Bob Aiello respectively. These three chapters cover a lot of ground already covered in the first seven chapters, but from a fresh perspective.

A book that every CM practitioner (and every Agilist) should read.

Don’t get me wrong, there are some nuanced uses of these terms. Some of the nuanced use has merit, but hardly needs to be labelled with some nebulous noun. The problems are not the ideas themselves, but as soon as a label is applied it starts to be twisted and morphed into something that is essentially useless.

How useless? Take ‘Agile’. The idea itself is simple and clearly expressed in the Agile Manifesto (even this is making preposterous claims about ‘uncovering better ways of developing software’—listen buddy, what you describe is the way many of the organisations I worked for developed software long before this manifesto was published, even while claiming to do the opposite). It’s not new, heck it wasn’t new even when the term was created. But having coined the term it started to accrete all manner of meaning (especially once the marketing twonks got hold of it).  The problem now is that if you ask ten people what ‘Agile’ is you’ll get ten different answers. Not only that, all ten will think the other nine are idiots, or heretics, who don’t understand the true meaning of Agile.

It would be easy to blame the marketers and they must bear a lot of the blame because no sooner does a new technology or method of working gain traction than they start riding the bandwagon labelling every product with the new non du jour. This process immediately destroys the original, possibly clearly defined, term.

However, easy as it is to blame the marketers (and I do), those in the IT world are complicit in this devaluing process.  The number of disagreements I’ve witnessed over just these three terms is staggering, not only because they are so fruitless but because they have a real impact on businesses. Weak managers incapable of independent thought, or fearful of making unpopular decisions, simply go along with the current popular idea and this leads to IT infrastructure and organisations that are a tangled mess of technology as the organisation is swept from one technology to the next on no better rationale than its popularity (this is the old ‘no one ever got fired for buying Compaq’ mentality that persisted in the ’90s).

So, DevOps. Another day another bloody stupid term. A devop is someone who bestrides the development and operational worlds. Now, I don’t know about you, but I’ve worked with an endless stream of such people over my twenty odd years in the business. I’ve even fulfilled that role on many occasions during those twenty years. This is not a new role, nor is it a new function, approach, method or technology. It’s just a new label and it will suffer the same fate as so many before it. It will be used and abused to the point of becoming worthless, nothing more than marketing fluff and a shorthand to make HR’s life easier (no need to actually think about what you really want, just search for DevOps on a CV, that’ll do). And that’s what pisses me off.

Bob Aiello lit the blue touch paper (again) on the debate about ‘what is configuration management?’ and, once again, he seems to be trying to redefine configuration management to fit the role of Configuration Manager identified (incorrectly) in many organisations. This is absolutely the worst way to define configuration management.

Let’s now look at Bob’s list of things he want to dump on CM’s lawn.

I often describe that there is a big CM and a little CM.

Big CM is the field of Configuration Management which I suggest includes:
* Source Code Management
* Build Engineering
* Environment Configuration
* Change Control (seven different types)
* Release Management (coordination and engineering)
* Deployment

while little CM refers to Configuration Control (of interfaces).

From Bob’s original post to this thread

This is simplifying CM?  In this article I hope to show why this redefinition is unnecessary, flawed, and ultimately damaging to CM.

If we were to accept that a discipline is correctly defined by looking at the roles identified in organisations then we would never get anywhere (much like this debate). I for example often have the role named ‘Configuration Manager’ and yes  I also do builds, releases, etc as identified in Bob’s list. But then I also fetch coffee for the team and I do the odd bit of development or testing, I write technical documentation, perform product evaluations, project management, risk assessment, and I assist in problem solving for production systems—and yes, sometimes these things (with the exception of fetching the coffee) are part of my official role (although given the current economic climate, who knows). Does that mean these too are defining features of configuration management? No. This is a silly way to define a discipline. Even if you observe that ‘many’ organisations lump the things together it still would not justify redefining configuration management because there’s absolutely nothing to gain, and much to lose, from doing so.

Configuration management (the discipline) has a perfectly sound definition (all together now); identification, change control, status accounting, and auditing. To change this definition is to define something other than configuration management and I have no objection to defining an umbrella term to cover all the disciplines identified by Bob; in fact I do, I call them Development Support Services.

Yes, we could do more to clearly communicate what CM is. Although, I cannot recall a time when I was ever confused by what the the four core activities were, the difficulty always stemmed from more subtle issues like ‘how do I select good configuration items’ and Bob’s redefinition does precisely zero to address these problems. Adding more complexity by mixing in a load more disciplines is hardly likely to aid clarity.

If the idea is that by lumping all of these disciplines under the CM heading we can make CM appear more useful or make it an easier sell to management, then I think that’s horribly misguided too.

You: We want to introduce CM.
Manager: What’s that when it’s at home?
You: Oooh. Loads of good stuff. Build, release, change….
Manager: Hang on. We do most of that stuff already.
You: Ah. But we’ll pull it all together under one heading. Make it more coherent. Make it better.
Manager: Create a bottleneck you mean.
You: No. No. No. We’d be specialists.
Manager: So CM is just all this stuff under one team?
You: Oh no. We also do identification, change control, status…. *noticing manager slip into comma* Oh, wait. Remember the ITIL course you went on?
Manager: Oh yeah. That was a great couple of week. Great evenings…. Oh. I mean, yes, very valuable.
You: And you remember them saying you needed a good CMDB?
Manager: Yeees?
You: Well that’s what we’ll do.
Manager: As well as all this other stuff?
You: Sure.
Manager: And what about all the people already doing the other stuff?
You: They’ll be part of my team.
Manager: Hang on. Your team?
You: Of course. They’ll be under the CM team.
…. and so on…

Obviously I’m being slightly facetious, but hopefully you see my point; why complicate things? The manager is now more confused about what CM is than he was at the start. Sure, you’ve made a pitch to create a service team supporting development, but you’re not closer to furthering the CM cause than you would have been had you just reminded the manager about his ITIL course in the first place. You’ve made no real progress in explaining CM, you’ve just hidden it amongst a load of other stuff, possibly to the point of obscuring it completely.

‘But we should move with the times’ is a common enough response. I agree. Let’s draw a parallel to show how it’s unnecessary to abandon the existing definition of CM but still move with the times.

Science is decomposed into disciplines. Physicist will often joke (and in some cases only half-jokingly) that all other sciences are ultimately reducible to physics and therefore physics is the only science we need. This seems to be what those who want to lump all these other disciplines into configuration management are set on doing, lumping all the other disciplines into one. And, just as with the science example, it’s a bad idea.

Continuing the parallel between CM and science. Just because scientists resist the temptation to mangle all their disciplines together hardly means they’re not moving with the times. Biological science is unrecognisable from fifty years ago, but it’s still Biology. Similarly, configuration management’s scope has increased as we have more powerful tools we can realistically monitor and control to a finer and finer degree of detail. Where in the past a configuration item’s scope would be limited by the capacity of a paper system to realistically track it, we can now declare almost every file in a system to be a CI if we so choose.

What Bob (and I’ll use Bob as a proxy for all those who support the view that CM should absorb all these other disciplines) seems to be proposing is something like the following (I’ve reduced the list to just build and release management to keep the diagrams simple, my point is still made I think).

Or, heaven forbid, the following.

In the first case build and release management become intrinsic parts (aggregate into) configuration management. In the second (shudder) they become inner classes, only accessible through the configuration management wrapper.

Both of these system architectures are… well. They’re terrible design. If a software engineer came to me with this design I’d fire his ass. (If people are sufficiently interested in me expanding this claim, I will do so in another post.)

One observation, made by Joe Townsend, was that the four activities that constitute configuration management are still to be performed within many of the sub-discplines identified by Bob. If this is so, then why not keep the CM discipline separate and have these disciplines use it rather than mangling them all together? What possible benefit is accrued by redefining CM in this way? ‘Oh well, CM is still a part of some of the disciplines we want to put under the CM banner. Erm. No. Wait. The ‘four activities formerly known as CM’ as now part of some, but not all, of the disciplines that now make up CM’. It just makes no sense. It’s adding insult to injury. It’s muddying the waters. You get the idea; you’re doing nothing at all to help clarify CM and your piling in a load of additional stuff that does not belong in there.

Let me be clear. If you want to be called ‘Configuration Manager’ and cover all the disciplines Bob identifies, good luck to ya. You won’t be the first, or the last, to do that. Heck, you can take the title ‘Lord of all he surveys’ if you like. Makes no odds to me. My gripe is about redefining the discipline of Configuration Management in these terms.

The following diagram shows how build and release management simply use configuration management. A much more elegant structure and one that benefits from modularity, making it much simpler to explain each discipline—also making it simpler to ‘debug’ the processes involved. (The benefits of such modularity should be obvious, but if people are keen for me to expand I will do so at another time.)

It’s simple. It’s elegant. It’s modular. It’s scalable. And IT’S WHAT WE HAVE NOW! (Well, those who have not polluted the well.)

Another objection is that this combination of disciplines under the CM rubric is only done for Software Configuration Management (SCM). What! Why? Why do people insist on making this asinine distinction? SCM is ‘Configuration Management of Software’, which, according to the correct definition of CM is precisely the same discipline as, for example, ‘Configuration Management of automotive engineering’, ‘Configuration Management of hardware’, or ‘Configuration Management of X’ for whatever ‘X’ you care to put in there.

If you accept the universality of CM principles then the multi-discipline agglomeration proposed by Bob makes even less sense. Most engineering CM systems, for example, have no build discipline within them; the CM discipline is used by fabrication plants to provide reference material (engineering specification, computer controlled tool programs and the like) from which the fabrication plant build the items. The closest these CM teams get to performing a build is assembling a baseline to be passed to the fabrication teams. It is simply coincidental that people labelled ‘configuration manager’ in the software business tend to be qualified to do build management. This is not sufficient justification for putting build management under the CM (or even SCM) banner.

Even if you claim justification for putting these other disciplines under the CM banner by saying something along the lines, ‘oh, well CM does not ‘do’ the builds necessarily, they’re just responsible for ensuring they are done’ I say that road leads to perdition. You could justify the inclusion of almost anything you want under the CM discipline using that argument, and you’d be wrong every time.

Blimey! It’s different! VERY different. In fact it’s a completely new way of working. I mean COMPLETELY! The only things that remains the same are that you’re handling video and it’s a non-linear editing tool.

There’s certainly plenty of professional’s complaining about Final Cut Pro X. Why? Complaints can be broadly split into two camps:

1. “Ew! It’s different. I don’t like it.”
2. “It does not support <insert favourite feature>, so I hate it.”

Okay, the first camp are immediately dismissed. Every new release of a product that attempts a significant overhaul faces opposition like this. People generally find the disjoint of learning a new way of working uncomfortable. Too bad. Such is the price of progress.

The second group are simply not going to be the early adopters. Look guys, Apple works this way with all their products. They release a product the will appeal to a large proportion of their customers, then they wait for all the complaints, then they add in those features that most people really need. Simple.

If you really need a feature that’s missing, keep using FCP 7. It’s not that difficult. FCP 7 was great yesterday, it will be great today. FCP X does not downgrade FCP 7′s functionality out of spite. If a feature is really needed (and if it’s technically possible) Apple will put it into FCP X over the next year or two. (Oh, and the the moron who said FCP X deleted his FCP 7, look for a folder under your applications folder. FCP X moves FCP 7 out of the way, it does not delete it.)

I’ve only been using FCP X for a few hours and, yes, the interface is, at the moment, a barrier to me because it’s so new. There are tons of features in FCP X I can see being real time savers (like automatically cataloguing clips, auto-synching clips, locking clip together on the timeline) and the new paradigm of a storyline makes perfect sense to me. It will take a few days messing about to get used to it all, but I’m confident it will be a great fit for me in the long run.

If you’re a professional working in a broader workflow then, sure, you’ll not want FCP X. It does not export XML (so passing your work too and fro through a complex workflow is out), nor can it import clips using an EDL. Nor can it open FCP 7 projects. All of this is probably because FCP X takes such a different approach to controlling the timeline that it may not be possible.

So, what are Apple up to?

As usual I think that many reviewers are missing the point. The number of professional users of FCP who need these features is vanishingly small compared with the actual, or potential, user base who want a professional editing tool and work alone or in a small team. All those Indie film producers, YouTube/Vimeo/etc. producers. All those small companies (like me) who do their own video work. The list goes on and on. Apple are not here to serve a minority, they’re looking at the bigger picture.

Sure, they will lose professional editors unless they find a way to fill some of the perceived gaps in the next 12-18 months. But let’s face it, many of those whining about FCP X fall into category one above, and of those that fall into category two most will continue using FCP 7 until either a) it gets so long in the tooth they are forced to move, or b) FCP X becomes a viable upgrade for them. What they will NOT do (unless they’re idiots) is immediately start moving their workflow to Premiere or Avid just to spite Apple.

So, hit or miss?

I little from column A, a little from column B. For me, I think FCP X will be perfect once I get my head around this new interface. The speed improvements are awesome, the new features and automation are great for someone in my position, and overall I like the storyline idea. FCP X is going to make my life much easier. On the other hand, it does mean taking time to retrain myself, and no doubt I will find some things I dislike along the way, but these are the price of progress.

IBM Rational ClearCase 7.0: Master the Tools that Monitor, Analyze, and Manage Software Configurations

by Marc Girod and Tatania Shpichko

Published by PACKT Publishing

ISBN 978-1-849680-12-7

I am reviewing the eBook (PDF download) version of the book.

Reading this book will not make you a ClearCase administrator, or user for that matter. It is mainly a manifesto for the authors’ views on why base ClearCase is the SCM tool and how you should be using it.

This book is part technical presentation, part dogmatic manifesto. On the one hand the authors have evidently found a method of using ClearCase that works for them, on  the other they are fanatical in their approach, brooking no descent from their chosen methodology. Any other approach to SCM or use of ClearCase is simply wrong; a position repeatedly and unambiguously emphasised throughout the book.

This is not an easy book to read. Not because the subject matter is particularly sophisticated but because the prose is often difficult to decode. Throughout the book you will encounter things like the following two samples (chosen pretty much at random):

The opacity of tools, as well as that of sources, is of course only a matter of viewpoint: the boundaries are only surfaces of separation between realms of distinct coherence.

Attributes are the preferred alternative to comments. They are preferred because their typing allows to avoid depending on parsing informal text.

Unfortunately this abstruse prose style means the authors’ ideas are often obscured. They really make the reader work hard to figure out what is being said. The book would, in short, have benefit immensely from being professionally edited by a native English speaker.

Another feature that I would have found immensely helpful would be a few well chosen diagrams. The authors are big advocates of the command line, but extending this bias into a book intended to educate, leaves readers with the additional cognitive task of imaging many of the situations based on text output where a simple diagram would make everything immediately obvious. Imagining the situation being described is not always a simple task when the output is from unfamiliar tools (and given the authors make extensive use of some Perl utilities there is plenty for even existing ClearCase users to find unfamiliar).

That said, the book is not without merit and does contain some interesting ideas (if only one takes the time to wade through the authors’ style).

The book does contain plenty of examples and these are used to discuss the application of the authors’ approach. The authors’ evidently use the approach that they advocate, so this is no theoretical approach but one that obviously works for them.

So, who would benefit from reading this book? With the caveat that any serious practitioner should read everything they can: if you want to use base ClearCase (no UCM, the authors are very dismissive of this innovation) and you are content to follow the prescriptions of the author, then this book may be of value to you.

If you are looking for a book that will teach you about ClearCase or a book showing anything other than base ClearCase, then you will have to look elsewhere. Multisite is dealt with, but mostly to highlight the difficulties in using it—this in itself is quite useful information.

The authors principal concern is with the leveraging of ClearCase’s derived objects and ClearMake system to make builds more efficient (although there is nodding acceptance that the advantages are less apparent when using systems such a Java with its compiler’s built in dependency management).

I can see some benefits to the authors’ derived object maintenance approach. However, there are many simpler, and better, ways to improve build reliability and performance (proper system decomposition and leveraging parallel builds, for example). Anyway, this is a review of the book, not a critique of the approach, so I shall defer my observations on the correctness of the authors assertions about the superiority of managing derived objects and simply say that the book contained no substantial argument that I found persuasive in favour of their approach (although it does contain much assertion of the superiority of the approach).

The approach to version control described in the book is fundamentally quite simple, but the explaination makes this simple system appear more complex than necessary. In summary, the proposed approach is, in essence, branch per change. The “novel” feature, according to the authors’, is that they promote the idea that there is no need to merge changes back into an integration branch, preferring instead to use labels to pick up versions from the extant fix branches. I often found myself having difficulty seeing the real benefits of this system, or indeed any significant benefit of the system over more widely used approached. The main benefit seems to be that this approach maintains identities within ClearCase, making the authors derived object maintenance objective feasible.

The authors attempt to dismiss alternative approaches (such as use of integration branches), but I found their explanations of the weaknesses in these approaches seemed most often to be based on misunderstandings of the mechanics of these alternative approaches rather than fundamental problems. (Although I defer to their superior knowledge of ClearCase’s shortcomings when they make specific comments on the problems with these methods when using ClearCase.) Perhaps I misunderstood their case. It was honestly difficult to tell sometimes simply because of the writing style and dismissive tone in some sections.

This is not a book with wide appeal, and this may explain the high price. Is it worth the £20.39 (eBook price), £30.59 (printed book price)?

At about 320 pages (excluding the index and front-matter) the book is brief enough to read comfortably on a wet Sunday. Unless you are specifically looking for a prescriptive method of applying base ClearCase to your organisation I would have to say, ‘no, this book is not worth the purchase price’. There is simply not sufficient content of general interest to the SCM practitioner, or even of interest to those looking for a general ClearCase book.