Communicating Software Change

 

As software developers and testers, we often fail to recognize what occurs beyond the last compile / regression loop as part of the Product Delivery Cycle.  Our failure to appreciate the complexity of the complete Product Launch Process results in painful and pointless work by many other teams in this organization. Customer Support, , Product Management, Sales, and Project Management teams just to name the obvious ones.

This situation is not at all unlike my wife when she cooks.  Like many developers, the woman is an artist.  No debate, she really is.  She is a masterful chef, and her culinary creations are often amazing and delicious.  In short, her products kick ass.  That said, there are certain fundamentals of process that tend to get overlooked when the artist in her gets cooking.

Instead of cleaning as she goes, Eleanor prefers to focus exclusively on making the dish.  Clean up comes later.  The house rule is, for the most part, the cook doesn’t have to clean up.  If you are the one who spent all that time and energy cooking for the rest of the family, it seems fair.  Do I resent the cleanup even after a great meal?  Not usually.  It only irritates me when I have to clean up things that I believe she should have done herself as part of the creation process.  I don’t mind doing the dishes, but can’t you wipe the gravy off the ceiling yourself?

Don’t do this to the other teams in your company that eat your cooking.  Make great software, but don’t ask other teams to clean up your mess when you are done. Keep accurate change notes as you check in.  Wikis, Share Point Team Sites, Blogs, other web pages all make great tools for this.  The perfect tool would automatically generate your change notes from the clear, lucid, and detailed checkin comments that everyone provides in the source control checkin dialog box.  This dramatically changes the detail captured in comments for the better because developers know that they don’t have to write it down many times to be done with the documentation chore.

Provide a single tool your organization may depend on for multiple release cycles, be it a web page, a Word document, or somewhere in between.  Be disciplined about using it.  Do not wait until the end of your development effort to document your changes. Change tracking should be done as work is done, not unlike testing. 

A rule of thumb I like is every code commit should be a change that is worthy of advertising to everyone on the team, and every commit should contribute to a line in Release Notes.

Now, go make a great dish.