AccuRev is once again pleased to inform everyone that its flagship product, AccuRev, has been selected as a Jolt Award Finalist for Dr. Dobb’s 19th Annual Jolt Product Excellence Awards in the Change and Configuration Management category. 

For the past 18 years, the Jolt Product Excellence Awards have been presented annually to showcase products that have “jolted” the industry with their significance and made the task of creating software faster, easier, and more efficient. The awards presentation is sponsored by JOLT, the fabled soft drink quaffed by software developers for sustenance during project development marathons.

“The Jolt judges have selected these finalists from the nearly 300 qualified nominations that were submitted online. The submissions represent the many innovative tools available for every phase of the software development lifecycle,” said Amber Ankerholz, Jolt Award Project Manager. “This year’s finalist round was extremely competitive and we appreciate the effort all of the participants put into showcasing their products’ features for the judges.”

In the next round of the Jolt Award process, the judges will examine the finalists according to the standard criteria of audience suitability, productivity, innovation, quality, ROI, risk, and flexibility. They focus on products that are ahead of the curve, universally useful, rich in functionality or that were solutions to problems in their product space.

Winners are announced during the Jolt Awards ceremony that takes place on March 11 at SD West 2009 Conference & Expo at the Santa Clara Convention Center.

by Dave Thomas

Your team has been coding a feature for a few days, across dozens of files, and everyone is excited with progress.  Deep into development, you find an interesting 3rd party library that may simplify your work and possibly take the team’s feature to the next level.  But it will require adding new files, moving some directories, and refactoring some critical code.  However, you’re not ready to commit your current changes because they are unfinished and will surely break everyone else.  Your changes need to be saved before prototyping in case of a rollback but also be integrated with prototype development.  And what if the new library is a bust?  If you start co-mingling the library integration with unfinished code, the potential revert process will be a complete nightmare and waste of time.

Private Versioning. With AccuRev’s private workspace, you can always commit your changes early, often, and safely without sharing amongst your peers.  But in this case you have two logical development efforts, the 2nd effort depends on the first and both need commits to preserve evolving changes.   How do you keep them cleanly separated and continue to work on both in parallel?

Stream Inheritance.  AccuRev streams have an intriguing and very powerful feature called inheritance.   Similar to how an OO subclass implicitly inherits methods from parent and grandparent classes, a child stream implicitly inherits versions of files & directories from parent and grandparent streams.   Taking advantage of inheritance, we can use streams to independently manage logical changes and cleanly maintain change dependencies without physically co-mingling files.

The Pattern.  Prototyping changes without co-mingling files can be done by simply creating a series of ‘personal’ or ‘private’ development streams (though, they are just regular dynamic streams). This pattern will create a “Feature”, “MyDevelopment”, and “MyPrototype” stream sub-hierarchy.  See Picture.

click to enlarge

From your Integration stream (or equivalent), start by creating a “Feature” stream that will collect all changes from your entire team.  [See related blog, Stream-per-Task Pattern].  The majority of team members may have their workspaces directly from here.  Next, create a child stream called “MyDevelopment” that will track your personal ongoing development activity.  Finally, create a grandchild stream called “MyPrototype” to track changes that will be discarded or retained depending on the level of success.

The prototype development activity is committed, shareable, integrated, and yet cleanly segregated from both active feature and private development.

The “Feature” stream is the collection point of all in-progress development activities for the given feature from the entire team.  Developers will promote here frequently possibly kicking off an automated build with success/fail notification.   The “MyDevelopment” stream provides a collection point for all of your personal development changes.  This stream may be considered a “private” development stream simply because no other developers will likely use it – set a stream lock to be sure.  A lightweight Continuous Integration build (i.e. compilation only) may be performed on “MyDevelopment” for sanity sake or just compile and promote as a practice.  The “MyPrototype” stream is a collection point for all prototype changes. Even as new changes are promoted to “Feature” and “MyDevelopment”, the “MyPrototype” stream will automatically incorporate those changes (via inheritance) and the prototype developers will merge changes as necessary. The prototype development activity is committed, shareable, integrated, and yet cleanly segregated from both active feature and personal development. Also, by using a stream for prototype work, multiple developers can contribute and collaborate. If the prototyping work is deemed successful, the files can be promoted to “MyDevelopment”. If the prototyping efforts don’t work out – no problem – just remove the “MyPrototype” stream and re-purpose the workspaces.

The beauty of this pattern is that it isolates development activity by purpose without co-mingling physical file changes.   It lets the prototype developers go nuts and shoot from the hip while the regular feature developers (with the deadline!) work unimpeded and without fear of rampant changes — and everyone stays up-to-date.   And with no limit to stream depth, teams can perform prototyping efforts in parallel and/or perform prototyping based on existing prototypes by adding another child stream!  Furthermore, the pattern works for any size development activity or team, even for us Team-of-One developers with tons of ideas, fast fingers, and a few green screen x-terms (2 space, 80-char wrapping of course – <chuckle>).

This is a perfect example of how AccuRev empowers the developer to take control of their own development.  Creating streams is extremely easy and the stream browser provides unprecedented visibility into the entire development process.  With the right amount of security in place (Locks, ACLs, Triggers), the critical release streams (left side of the stream structure) can be locked down by the CM Admins, but the development related streams (right side) can be fair game for developers to create an environment that suits their purpose, such as prototyping.

Does anyone have a good story to tell about how this pattern (or equivalent) helped with a major refactoring effort or library upgrade?

/happy prototyping/ – dave

Read my earlier post: Fortune 500 Software Company Answers Your Questions on Using AccuRev

Up until fairly recently I had never worked anywhere that was able to do parallel development without it becoming a nightmare. Individual contributor or manager, we just seemed unable to find that secret magical incantation that would lead to a truly successful parallel development cycle.

Every time the team had a different plan, and the project’s champion would trumpet why this time ‘things would be different’. But in the end, we always failed in one of two areas (sometimes both):

• The quality of the software suffered dramatically

• We lost control of the schedule and we were forced to ship late

I actually worked on one project where the resulting release was so bad that a few weeks after release we had to pull the product off the shelves and work frantically to repair the damage.

Then a few years ago my team was looking for a new software configuration management tool to use. We started out wanting ClearCase, but after much deliberation, decided on Accurev. At first, we didn’t realize the power of the tool now in our control. But after a release or two, we started to realize what we had and adjusted our process accordingly and began to achieve very successful, high quality, and on time releases done in parallel with one another. We had found the holy grail of project management!

We started to understand not just what the best practices were with Accurev, but to understand what we were getting by following them. We made other changes to our processes that helped as well, but I give a lot of the credit to the tool-set for helping us in the right direction.

We started out performing a round-table series on our past projects, looking for common themes, and then choosing the top themes and seeing how we could use Accurev to solve them, and here are some of the things we found:

Problem: Often parallel projects require extensive code changes to the same files, leading to a need for developers to communicate what is being done to which files and when. Often this communication is not handled well.

Solution: Accurev’s work in progress and annotate commands, as well as the version browser allow developers to quickly view who else is making changes to the files that they care about, and what is being done to them. Now developers can pro-actively gather the information they need instead of depending on someone else remembering to tell them.

Problem: Often projects have late phase merge points which are both complicated and error prone. In addition since merging is generally done in the mainline, the entire release can be held when any two projects try to merge together.

Solution: By allowing stream definitions to be dynamic, Accurev allows developers to create common merge streams ad hoc at no cost, and to join the projects without effecting any other users. It also provides excellent trivial merge capabilities that save the users much of the error prone work, calling out only the non-obvious decision points which greatly simplifies the merge task.

Problem: Often bug fixes get made to one ongoing project, but developers forget to make the same fixes to other active lines of development.

Solution: Using change packages users can quickly make changes, move them to all appropriate locations, and quickly verify that the tasks were completed successfully. Using the stream inheritance feature minimizes the number of lines where a developer must make a fix for his coworkers to take advantage of it. This greatly lightens the load on developers and cuts down on the chance that something will be forgotten.

Problem: Ensuring 100% reproducibility of a build from pristine sources is a huge challenge. Changes to the build system environment, tools and code changes can all effect your ability to make a minor fix to released software.

Solution: By keeping your complete build system (environment, tools, sources) all in Accurev, and by using a snapshot you are able to guarantee 100% that what you try to build today is the same as what your built the day the snapshot was taken. Unlike a label, a snapshot is forever! This enables you to reduce the regression test matrix and focus on only the changes that developers make to the released software.

While I am sure that other SCM tools can offer similar results if you know where you are starting and know where you want to go. But what I marvel at is that using Accurev really lead us to the cup so that we could drink from it and enjoy the benefits of successful parallel development.

Have you seen the AccuRev 2-minute demo?

by Brad Hart

Hi, my name is Brad Hart and I am the Director of Technology at AccuRev, Inc. I’ve been working in the software delevelopment / process space for 10+ years. I’ve designed and supported numerous ClearCase / ClearQuest implementations both while working at IBM/Rational and as a customer at various companies. At AccuRev, I’ve been involved with countless implementations of AccuRev with our customers, everything from small to large, ISVs, Internal IT, and Embedded systems companies.

Over the years, I have seen so many different approaches for software development in all kinds of companies. One area that every company seems to struggle with is defining their process. There are many stakeholders in the development process (Developers, QA, Release Engineers, Admins, Management, etc…), and it is a difficult task to get everyone on the same page to ensure that the defined process meets the needs of everyone. One area of particular contention is the amount of process to use. I’ve worked with small companies with a handful of “cowboy” developers which had absolutely no process, and I’ve also seen the opposite end of the spectrum with so much process at large companies that it gets the nickname “pebble moving.” Neither approach works.

In the no/little process environment, developers just do what they want, where they want, and how they want. This freedom certainly seems nice for the developers. I’ve never met one yet who was yearning for more process… However, this hurts the company (including the developers) in the long run. Release Engineers have a difficult time reliably building and reproducing software, parallel development is held to a minimum, Admins lose control of the assets, Managers cannot track progress and at the end, less software is produced and what is produced is lower quality. The positive side is developers spend 100% of the time coding and 0% on process overhead. The negatives are poor software, slow delivery and regressions.

The opposite end of the spectrum is equally inefficient. Have you ever seen an issue tracking schema with 10+ tabs, 100+ fields, and a state transition workflow that can only be described using 5+ visio diagrams? I have…many times. In an effort to control each step that everyone takes, these companies suffocate their developers with way too much process. So much so that they cannot work at even close to their full efficiency. They may spend as much as 30% – 40 % of their time working within the many steps of the process and not enough time coding. From my experience, developers react to this in 2 ways. (1) They just succumb to it. They simply accept the are not working at full capacity and move on. This of course means the organization is only 60% effective and can only produce 60% as much software as the next company… (2) They rebel. A motivated developer will find a way around the process so they can be more “efficient” and get more code written. Their intentions are good, but the results are bad. This approach almost always results in disaster: broken builds, regressions, lost work, etc…

So what is the answer? Just enough process. Just enough is going to be different for each company and even each group within a company. It also is a moving target based on changes in business requirements, company growth, etc… The right thing to do is to get representatives from each stakeholder group and work together to define what all the end goals and requirements are:

• How many releases do we need to ship per year?
• How many releases at a time will we support?
• What is our patching strategy?
• Do we need to support distributed development?
• Are we working with partners or 3rd party vendors?
• Will we support customer one-offs?
• What are our testing requirements and ship criteria?

Once you have the answers to these questions, you can start working on the process. The goal behind any process design is not to have a beautiful and elegant process. The goal for the process is to facilitate all actors in the process in doing the right thing and putting up just enough guardrails to keep from accidentally doing the wrong thing. Keep each business goal in mind and think about what it will take to make sure every actor has just enough information to accurately complete their task and just enough protection in place to handle common mistakes. That’s it. Don’t go overboard. That is just as bad as not having enough process. Don’t overwhelm people with information or steps to complete a simple goal. Should someone really have to fill in 40 fields to submit a defect? I don’t think so, but I’ve seen it. Keep it simple and straightforward. Just enough process is the key.

Also, make sure the tools you are using support the processes you’ve outlined. They should be able to implement your desired process and be able to adapt to changes in your process requirements.