What I Want To Know About Your Process Blog

Version 2



    First Questions
    "Undo Your Code"
    Building in the Morning, Building in
    the Evening, Building at Suppertime
    Development To-Do List
    Steps 1-3 of Many
    Links for Further Reading

    First Questions

    Could you retrieve any version of any file from the last release of your software? Do you know why you made the changes that you did in that version? Do you feel confident that you could make a complete build of your current release right now?

    These are some of the questions that I ask a software team I haven't worked with before. The answers to these questions point out some potentially easy-to-do process improvements that can work for most any team: source control, change tracking, and regular builds. These improvements:

    • Support larger-scale process improvements.
    • Are technologically simple.
    • Offer big bang for the buck.
    • Are so basic that most people know they should be doing them, but often aren't.

    The next sentence is the most important one in this entire article, so please read it twice — my editor would only allow me to print it once. If you make no other process improvements, figure our your source control. It has the potential to save you countless hours of wasted effort, and potentially rescue your entire project.

    "Undo Your Code"

    Source Control (sometimes called Revision Control, Version Control, Configuration Management): A combination of procedures and tools used to manage the changes to a set of files.

    Every smoker knows that they should quit smoking today. They know about the cancer. They know about the emphysema. They know about the heart disease. Yet they still smoke. Anti-smoking campaigns seem to want to overwhelm them with facts, but it's usually a direct personal experience that convinces someone to stop smoking. An earlier draft of this article contained lots of facts and benefits about source control, but I took them out. You already know you should have source control. You know how it protects you as you make changes. You know how it supports bug fixes in very old releases. You know how it helps isolate when a bug was introduced, which in turn helps you understand how to fix it.

    If I start working with a team that's not using source control, adding this to their programming regimen is my first priority. Source control can be added to your development routine in a single day and for no money, assuming that company bureaucracy doesn't get in the way.

    There are approximately 17,000 source control software packages in the known universe. They all use slightly different terminology and function slightly differently, but here's a general overview of how source control works:

    • All of the source code is stored in some place (often called a "repository").
    • A developer "checks out" or retrieves a copy of the source code that he wants to work on. Some systems require the developer to "lock" the file before editing it. This prevents developers from making changes to the same file simultaneously.
    • After the developer makes changes, he "commits" or "checks in" those changes to the repository. Usually the software only stores the differences between the versions of the code and not full copies of the files, minimizing storage space.

    All source control systems offer a mechanism for retrieving older versions of a file. This is done with a specific revision number, date, associated product release, or other criteria. So after version 3.0 has shipped, it's very easy to go back and produce a bug fix for the 1.1 release that your Important Customer is still using. If you find yourself in one of those "It worked last Thursday!" situations, you can easily view all of the changes that happened between last Thursday and today and locate your bug.

    Source control gives you the freedom to undertake major refactoring projects or experiment with a potentially risky code change with a safety net. Just think of it as multilevel "undo" for your source code.

    A popular choice for source control software is CVS. It's free (as in speech and beer) and can be implemented in Windows and UNIX environments. CVS conveniently uses an open file format, in case you decide to implement another source control system later. If you'd like to integrate CVS into your IDE, chances are good that the work is already done: Eclipse,IntelliJ IDEA, NetBeans.

    It's surprising how many development teams are not using source control, despite the well-known benefits. This is certainly a process improvement that offers a lot of value for a minimal amount of effort.

    Building in the Morning, Building in the Evening, Building at Suppertime

    Regular Builds (sometimes called Nightly Builds, Daily Builds, Continuous Builds, One-Button Builds): Making a complete build of the software on a regular basis, preferably via an automated mechanism.

    Imagine, if you will, a team rapidly approaching a deadline. The coffeemaker has been pushed to its limits. The team is now halfway through the second complete playing of their MP3 collection. With less than two hours before the deadline, the spiteful testers have found a fatal flaw in the system. The testers enter a request into their into their Shiny New Change Tracking System and augment the email alert by screaming over the wall to development. The developers take a look, discover that it is an easy fix and commit a new revision into the source control system (which is also Shiny and New). As the deadline looms, they call the guy who knows how to make builds — there is always only one guy who knows how. He begins the complicated, manual process of putting the build together…

    This scenario will hopefully make you giggle about a team you used to work with, and not weep about your current environment. Unfortunately, too many teams still save integration for the bitter end of the development process and rely on manual, error-prone steps to get software out the door. Regular, automated builds can turn that last-minute, one-line fix from an all-night disaster to a joyous celebration of product release.

    The first step to implementing regular builds is to find all of the files needed for a build and make sure that they are under source control. Then automate all of the manual steps with a build tool like make or Ant. The goal here is one command to a shippable build. There should not be any manual steps required to finish a build, because manual steps are opportunities for error.

    A great deal of office politics revolves around who is allowed to initiate a build. I've always felt that if your source control is sound, and your build is fully automated, then it is fine (if not preferred) for anyone to initiate a build. However, without good source control, it is possible for inappropriate code to slip into the build. Additionally, any manual steps expose you to the risk of creating a build that appears solid but is actually incomplete. You are exposed to these same risks even if only one person is permitted to initiate builds -- the risks are considered to be less in these situations, but they are still present. It is much better to correct your source control and build process before you begin to work on your project.

    Regular builds remove a huge area of uncertainty: "Will the build work when I need it to?" Additionally, continuous builds provide a layer of peer pressure: no one wants to be the one who broke the build.

    A common pattern is to have a build made every night at midnight, so there's always a fresh build first thing in the morning. Some organizations go even further, and use a continuous build tool like Cruise Control orAnthill— these systems constantly check the source control system for changes and make new builds of the software from the latest code.

    Development To-Do List

    Change Tracking (sometimes Bug Tracking, Defect Tracking): Software that manages and tracks requested changes to a project.

    How do you know what changes need to be made to your software? Whether it's a stack of index cards, an Excel spreadsheet, a fancy web tool or stuck in some guy's head, you are probably already using some form of change tracking.

    Oftentimes, "bugs" and "enhancements" are monitored using two separate mechanisms. I find that this separation is detrimental to the big picture of a project. In my experience, "bug tracking" is often synonymous with "blame tracking." For this reason, I prefer to lump both bugs and enhancements together and call the process "change tracking." If you consider unimplemented features to be "defects" in the ideal system, then "defect tracking" is also an appropriate term. As long as you track bugs and enhancements in the same place, you can call it whatever you want.

    Change tracking benefits your team in several ways. The most important of these is that the system maintains a permanent record of all information related to a specific change: status of the change, who requested it, why it was requested, commentary and discussion, proposed resolution, who fixed it, and when was it fixed. You don't have to track all of these things. You should only track the ones that are useful to your environment. Obviously, single-person teams don't need to track who made the changes.

    If an old bug resurfaces or a new one shows up as a result of an enhancement, a quick search of the change tracking system can reveal all of the information needed. Another powerful benefit to change tracking is in the area of customer communication. Exposing all or even part of the change database to your customers allows them to observe the progress of requested enhancements and bug fixes. This allows the customers to be aware of the flow of the project, and can offer them more control and make them feel more comfortable with how their money is being spent.

    Almost all change tracking systems allow you to set the priority (and severity … but be sure you know the difference between the two). By tracking all proposed changes, and managing their priorities, you can let the change tracking system determine what needs to be done next.

    Some features that you may want to consider when selecting a change tracking system are:

    1. Thick or thin client: Cross-platform, thick-client tools are harder to come by than their web-based cousins.
    2. Work flow and approval: Assigning a change to a product manager, and then to a developer, and finally to a tester automatically can help keep your process on track.
    3. Integration with the source control system: Seeing the exact changes committed to fix a bug/add a feature, and when they were added, makes it easy to have all of your information in one place.
    4. Powerful search: The better the search, both in terms of ease of use and flexibility, the more likely it is that someone will add to an existing report instead of adding a new, redundant one.
    5. Usage via email: Many people prefer to submit reports, and comment on those reports, via email.

    For every one of the source control systems out there, there are at least two attempts at change tracking (writing a bug database appears to be a rite of passage in the open source world). If you want a change tracking system that is free and fairly easy, Bugzilla from the Mozilla Organization is hard to beat (just enter your enhancements as bugs and you will be all set). There are patches to integrate it with CVS.

    Steps 1-3 of Many

    Teams who are looking at improving their development process should have already covered the steps discussed in this article. But there are still many teams who don't recognize the benefit -- the necessity -- of source control, change tracking, and regular builds.

    Links for Further Reading