Mark Staples

A colleague forwarded to me a pointer to the current issue of the ITMPI journal, on Best Practices in Configuration Management. They make an interesting contrast with the best CM practices in the November issue of the CM Journal on “What Best Practice Is Best?”, and specifically the article CM: The Next Generation of Top 10 Best Practices.

The CM Journal article’s list is as follows:

• 1. Use of Change Packages
• 2. Stream-based Branching Strategy – do not overload branching
• 3. Status flow for all records with Clear In Box Assignments
• 4. Data record Owner and Assignee
• 5. Continuous integration with automated nightly builds from the CM repository
• 6. Dumb numbering
• 7. Main branch per release vs Main Trunk
• 8. Enforce change traceability to Features/Problem Reports
• 9. Automate administration to remove human error
• 10.Tailor your user interface closely to your process
• 11. Org chart integrated with CM tool
• 12. Change control of requirements
• 13. Continuous Automation
• 14. Warm-standby disaster recovery
• 15. Use Live data CRB/CIB meetings
• 16. A Problem is not a problem until it’s in the CM repository
• 17. Use tags and separate variant code into separate files
• 18a. Separate Problems/Issues/Defects from Activities/Features/Tasks
• 18b. Separate customer requests from Engineering problems/features
• 19. Change promotion vs Promotion Branches
• 20. Separate products for shared code

The ITMPI Journal articles lists just 3 best practices:

• Software Configuration Management Audits (This isn’t really covered well by the 20 practices above, but is somewhat related to practices 5 and 13.)
• Risk-Based Configuration Control – Balancing Flexibility with Stability (This is somewhat related to practices 7, 11, 15, 16, 18a/b, and 19.)
• Bidirectional Requirements Traceability (This is somewhat related to practices 1, 2, 3, 4, 8, and 12.)

The ITMPI Journal article doesn’t really cover the practices 6, 9, 10, 14, 17, and 20, partly because the CM journal article practices are at a lower level of detail and cover a few practical/administrative issues outside of the core of CM theory.

Anyway, the practices in both these lists are all “good” for “most” development groups. They aren’t rocket science, but I’d say there are a fair number of development groups out there that barely do any of them. Although version control is ubiquitous in industry, CM is still very poorly understood by most practitioners.

For what it’s worth, I think that for most commercial software development, the most important practice isn’t about sophisticated version control issues or processes – it’s a simple but critical piece of organisational structure and policy.

All Customer Deliveries Go Through the Release Team
Create a release team that’s different to the development team. Ensure all customer software deliveries happen through the release team. Have the most senior manager you can find declare it a firing offense for a developer to ship code or patches directly from their desktop to the customer. Even in “emergency” situations.

More than once I’ve seen or heard of companies that own high-end commercial SCM tools, but make those tools worthless because developers sometimes email patches directly to the customer. (Sometimes in the rush they also forget to check in their changes to version control, which just makes the nightmare worse.) The developers are usually trying to “get the job done”, and be “helpful” to a customer with a problem. Sadly, they end up causing bigger problems for everyone down the line. If you’re not managing releases properly, you don’t know what code the customer has – you degrade your ability to diagnose faults, you won’t be able to ship working patches in future, and you might easily introduce a regression problem by losing the fix itself.

Another cordial this weekend, this time using bulk white nectarines from the grocer. They were too hard to be eaten, but made good cordial. I used a nectarine instantiation of my father’s generic cordial recipe. He created this recipe based on Matt’s recipe for orange cordial, but tweaked it after various trials, and made it parametric on fruit.

The recipe e.g. for strawberries or whole fruit, creates a very thick syrupy cordial – thick enough to use as a topping for icrecream. Add water if you want a thinner cordial more similar to a shop-bought one.

Somewhat surprisingly to me, microwaving dry white sugar (below) does work. But, be careful. Your microwave may have a different power, the bowl will become super-hot, and you need to periodically stir the sugar, or it will melt around the edges. Also, when you add super-hot sugar to the fruit puree, be ready for the puree to instantly boil. Personally, I don’t microwave the sugar – I just chuck it into the puree cold, then boil the lot of it…

Generic Cordial Recipe

• To make 7x litres of cordial, use:
  5x litres of fruit puree (see below)
  5x kg of white sugar
  63x grams of citric acid (i.e. 9 grams/litre)

• Heat puree to boil and remove from heat
  Heat sugar in microwave (5 mins/kg)
• Combine all ingredients, stir until dissolved
• Bring to boil, boil until satisfied with sterilization (5 mins?)
• Cool until cold enough to pour into sterilized bottles

Fruit Purees

Ginger: use 100g ginger root per litre of finished cordial (i.e. per 5/7 lire of puree). Grate ginger root, boil with some water until soft (pressure-cook for 40 mins)?, puree in blender (two 30-sec bursts?), then make up planned quantity with water.
Strawberry: Use hulled strawberries and no added water. Don’t boil, mash before blending.
Passionfruit: Use pulp of 1 large passionfruit per 100ml of puree. Boil with some water (or pressure cook) for say 20 minutes to release pulp from seeds. Sieve to remove seeds, puree in blender, add water to achieve planned quantity.
Pineapple, mandarin, …: (boil, add water only as needed)

Cordials with Ginger
Make ginger cordial from ginger puree as above and blend with other cordial to taste (40% ginger cordial?)

Our paper “An Exploratory Study of Why organisations Do Not Adopt CMMI” has started to be cited in the literature. It’s been in the “hottest 25 downloads” for the journal since it became available 3 quarters ago, so I’m hopeful the number of citations might grow.

On one hand, it’s great to cited! On the other hand, I worry that the results could be mis-interpreted. Specifically, people might be tempted to mis-read the paper as saying “small companies can’t do CMMI”. We don’t say that. So, I thought I’d try to clarify a few points here…

The main question we do provide some initial evidence for is:

• When companies decide not to do CMMI, why do they say “no”?

Here’s some questions we don’t provide evidence for in the paper:

• Do most companies do CMMI?
• Can most companies do CMMI?
• Do most companies think they can do CMMI?

(These are alternate “complementary research questions” – by saying what my main research question is NOT, I hope you get a better understanding about the boundaries of the main question, and how to interpret the results.)

In looking at the main question, we broke down the companies by size to see if we could get hints about why companies gave the reasons they did. Small companies tended to give different kinds of reasons than medium and large companies. Roughly, small companies said they couldn’t do CMMI, whereas medium and large companies said they shouldn’t.

But obviously some small companies can do CMMI! There are fairly credible reports of it in the literature. So, what’s going on?

What’s going on is that my target population is not “all software companies”. My target population is software companies that have decided not to do CMMI. To start my research, I first exclude companies that are doing CMMI, or that want to do it.

It’s interesting to progressively partition the population of companies, and think about where most software process improvement research happens. (This looks better as an animation, so think about these pictures as a sort of flick book in your mind’s eye.)

First, there’s the population of every organisation that might reasonably use CMMI.

Some of them will not have heard of CMMI, but some will have. You could study the differences between these groups as a piece of advertising or diffusion research, but I’m not aware of anyone who’s published research on this for CMMI or any other SPI approach.

Of the organisations that have heard of CMMI, some will have decided not to adopt it, and some will have decided to adopt it. This is the point in the adoption lifecycle that we examine in our paper. It is an extremely rare kind of research in software engineering.

For interest’s sake, let’s drill down some more…

Of the organisations that have tried to adopt CMMI, some will have succeeded in rolling it out, and some will have failed.

Of those who succeeded in adopting CMMI, some organisations will have got some benefit, while others will have had no benefit.

Where do you think most CMMI/SPI research sits?

Most research papers report on how organisations benefitted from using CMMI. In the literature, you almost never hear about organisations who tried and failed to adopt CMMI, nor about organisations who adopted but then failed to benefit from CMMI. (This effect is called selection bias, or publication bias, depending on how it arises.) It’s sort of understandable – companies don’t want to let themselves be seen in a bad light, and researchers may think that success is more glamorous than failure.

Looking at successful cases is necessary, but to really broaden the impact of software engineering research, we need to learn from failures as well!