by Tahir Hussein, Alterian

This diagram shows one key aspect of our development process i.e. 3^rd Line Support. It is critical to our operations because we support anywhere from the last 3 to 5 release steams. This includes monthly patch releases which address key customer defects and enhancements.

3rd Line Support

Prior to 2006 our development operation was UK based (in a single location). Everything was straight forward! However, when we opened up a development centre in Bangalore, that situation changed. Once we had recruited and trained the developers it was time to get them using our SCM tool, Serena Dimensions. This has served us well since 2000 but the performance of the connection to Bangalore meant that the PC and Web clients were totally unusable for shared development work e.g.

* It was taking over 5 minutes for them to browse change documents

* Editing the attributes e.g. to specify the fix times etc was taking around 10 minutes

* Making any kind of source code changes on a change document, especially one with a lot of additional related items or change documents was even longer.

* To fetch all 9000 items from the repository for a sandbox development and build was an overnight job (if it worked at all!)

Hence we had to put our thinking caps on and come up with another solution.

We tried making use of Subversion and associated tools and initially this looked very promising. However, when we started putting our Development processes on top of Subversion, in particular “Branching” and “Merging”, it became apparent that the underlying SVN functionality was not going to be mature enough for the tools to be available to cater for this. The solution we were looking at was Subversion running in UK and Bangalore, with the replication of data taken care of by a product called WANdisco and the Application Lifecycle management by Polarion. We had a number of meetings and discussions with all of the above parties, including the Subversion developers, who gave us an insight into the future plans. In the end the overall solution was not going to be elegant and satisfy all our needs. We carried on looking and eventually came across AccuRev.

At first we were reticent to go down this route as it was a proprietary system. However, when we were demoed the system by the AccuRev guys it seemed to fit in exactly with what we were looking for. Even with the addition of merge tracking in SVN, AccuRev is still head and shoulders above with its merge, change and namespace tracking.

We then obtained a demo license and spent a month evaluating the product against our list of requirements. The sort of checks we carried out were:

* How long does it take to create something e.g. stream, workspace in the UK and see it reflected in Bangalore and vice versa

* Can you create/delete hundreds or steams without affecting the system performance

* The critical one of can a number of developers on the UK and Bangalore work together on a set of changes in parallel and easily have those merged back together.

The whole thing ran so smoothly that we could no longer delay the decision to purchase. Last year around this time we purchased the required licences and then started the process of moving the development over to AccuRev.

So, where are we currently?

The intention has been to move over to using AccuRev and Jira combination (as Serena Dimensions covers both Issue Tracking and Source Control). However, as we have a limited number of resources available, and the fact that we require quite a lot of work to implement the appropriate workflow and associated build process, we have not had the time to do this. We are currently using AccuRev for ALL development and 3^rd Line support work but still use Dimensions for the Issue tracking and build process. Given that none of the developers in Bangalore or UK are impacted by this and can get on with their day-day work then I am cool with this. The only person affected is me as I have an additional step to perform by moving changes between AccuRev and Dimensions and vice-versa. I am confident that in the near future we will fully move onto the AccuRev/JIRA system and gain even more benefits.

I hope this will be of help to others and I would be more than happy to answer specific queries.

In a recent blog post on CodeSqueeze (http://www.codesqueeze.com/the-blame-game-how-necessary-is-traceability/) the subject of traceability and its utility in software project management was discussed. This post is a response to the author’s points on traceability. While I agree with the author on some points (especially that traceability can be used proactively), I believe that traceability has much greater utility in the development process and in the management of software projects.

Traceability, both at the code and issue levels, provides you with fundamental process metrics. By removing these metrics, you lose objective insight into the state of the project. Using such metrics for a blame game may indeed be a sign of poor project management, but not having the metrics at your disposal is a sign that you are not controlling the process, and that puts your project at risk. I can’t imagine other engineering disciplines such as chemical engineering even having this conversation - you measure (almost) everything that can be measured, and then determine which metrics are most useful in improving the process. The best engineers on your team will welcome objective measurements into their code - like having the fastest time at the racetrack, doing well by a set a metrics that are not easily manipulated is something to be proud of, and something for more junior engineers to aspire to.

As for feature traceability, some of the comments on the blog point in the right direction - for example, that in regulated industries, such traceability is a requirement. ‘We all trust each other’ doesn’t fly well with the FDA or DOD. But even beyond the regulated industries, traceability and related metrics answer questions that are too basic to leave unanswered:

- what requirement did this code satisfy?

- what ancillary issues (bugs, related requirements) is this code associated with?

- how long did it take compared to the initial estimate?

- how often since the fix was marked as ‘complete’ did the code change?

I could (and just might) write another blog post on why these metrics are interesting and essential to software process management, but for now I leave it to commenters to elaborate.

To the specific points that the author makes, lets look at them in turn. The author’s orginal points and counterpoints are in italics.

• Provides visibility of per person velocity - Visibility can occur during daily stand ups and weekly powerdowns.Sure it can, but that implies among other things that you are doing such standups. What if you are using an alternate process to coordinate the efforts of large, widely distributed teams? At some level, independent of your specific process, you need to be able to look into your SCM system and answer questions of who is doing what and why. Also, (and this touches on the second issue of accountability) not all developers communicate in the same way, so even if you are doing standups, as a manager you need objective facts to correlate with the verbal and written communications of your team.

• Creates a sense of accountability - Why the hell do you have people on your team that you don’t trust?  Trust doesn’t happen all at once. The basic principle of managing people, whether they are shipping clerks or software engineers is ‘trust but verify’. Once a person has established a track record of reliable communications that are consistent with the objective (and hopefully, automated) metrics, you might reduce the frequency of how often you check them against the metrics. But periodic checking is essential - if a previously reliable engineer has for some reason fallen off the tracks, they may be reluctant to admit it, or they may not even be aware of it. A properly constructed metric that is trending in the wrong direction will give you clue that there is an issue to be addressed with this engineer.

• Allows for possible learning opportunities - Either the bug is a bug (and no real lesson is to be learned), or senior developers did not properly guide less experienced devs through a design problem. All bugs teach you something. The latter case that the author mentions is certainly one lesson, but it implies that senior developers don’t write buggy code or are somehow immune to design problems (or design-to-implementation translation problems) of their own. This seems unlikely. Most of the best engineers that I’ve worked with will admit to some whopper bugs - many written well after they had earned the title of ’senior engineer’ or ‘chief cook and bottlewasher’, or whatever. What a bug tells you is that you have code that needs attention, independent of whether it dropped out of a build process or was discovered by the janitor. The overhead for recording a bug, commenting on it and connecting it to the source code change that resolves it is minimal in a well-designed and well-tooled development process, so for a small amount of effort you get the benefit of a window into your code, its failings, and your process. Seems like a low price to pay for such potentially valuable information.

I’ll admit that traceability and metrics are on my mind often (see for example, my prior post on the AccuRev-Rally integration and how it assists in agile requirements traceability). Maybe it’s because my favorite toys as a kid were ruler, compass and slide rule and I just like measuring things for the heck of it. Or maybe it’s because I’ve seen too many engineering projects fail - projects that if the manager (myself included) had a bit less hubris and a few more objective facts at their disposal, could have been squarely in the success column.

By Tomas Lundström, ReadSoft

A consistent naming scheme makes your life easier and is also a good way of avoiding name clashes in AccuRev. Here follows my stab at it. (With one important disclaimer; for multi-depot installations, you should use a depot prefix for all streams, to avoid name clashes between depots)

AccuRev Codelines and Baselines

The following naming rules apply:

• Character set. For scripting compatibility, allowed characters are English alphanumericals, underscore ‘_’, hyphen ‘-’ and period ‘.’.
  In particular, blanks, Swedish characters and slashes are disallowed.
• Case. Product names and keywords exclusively use ALL UPPER CASE, other text and component names use mixed case.
  Examples:APPROVE_REL, Libraries_DEV
• Main codeline streams: <CODELINE>_<LEVEL>
  Examples: APPROVE_REL, DOCUMENTS_DEV
  In the basic case, there are two (optionally three) levels of streams for a codeline:
  • REL. Release stream, where final main releases of products are done.
  • QA. QA stream (optional). If not present, the REL Stream serves QA as well
  • DEV. Development stream where developers share code, and perform initial integration.
    
• Maintenance codeline streams (’branches’): <CODELINE>_<VERSION>_<LEVEL>
  Examples: APPROVE_5-1_REL, DOCUMENTS_6-3_DEV
  Maintenance codelines may be single level, in which case it shall have the level REL, or it can be two or three levels, just like a main codeline.
• Other codeline streams: <CODELINE>[_<VERSION>]_<PURPOSE>[_<LEVEL>]
  Examples: APPROVE_portToVS2005, APPROVE_5-1_hotfix47
  These streams are used for e.g. hotfixes, service packs, substantial tasks, subprojects, teams, experiments and acceptance tests. Most streams will be single level, so the level can be omitted. In most cases, the version can be omitted as well, since it will be evident from the context (i.e. its parent stream).
• Snapshots: <PARENT STREAM>_<TIME>[_B<BUILD#>][_<PURPOSE>]
  Example: APPROVE_5-1_REL_D051127T1347_B6365_iRC01
  
• Workspace Streams: <PARENT STREAM>[_<host>|<number>]_<USER>
  Normally the default scheme should be used, where the AccuRev wizard attaches the user name to the stream name, i.e. the user name should never be explicitly written out when creating a Workspace!
  If a user has several workspaces on the same stream, they have to be distinguished by some kind of identification. For workspaces on different computers, the host name shall be used. For workspaces on the same computer, an integer number shall be used.
  Examples: APPROVE_DEV_3_tomas, APPROVE_DEV_buildserver12_tomas
  
• Reference Trees: <PARENT STREAM>_RT[_<PURPOSE>][_<host>|<number>]
  A reference tree cannot have the same name as an existing reference tree or workspace. In case of conflict, use the same distinguishing naming rules as for Workspaces.
  Example: APPROVE_REL_RT_NIGHTLYBUILD_buildserver12
  
• Pass-through streams: <CODELINE>_PT_<PURPOSE>
  No changes ’stick’ to pass-through streams. However, include/exclude rules apply, so they can e.g. be used for grouping other streams/workspaces that share visibility rules.
  Example: Documentation_PT_APPROVE

<CODELINE> is typically a product or component name, such as APPROVE or Utilities

<VERSION> is the commercial product version, e.g. 5-1

<TIME> is on the form: Dyymmdd[Thhmm] Time is optional.

<PURPOSE> is used for additional comments:

• Hotfix number (HOTFIXyy)
• ServicePack number (SPyy)
• Release Candidates (iRCxx, eRCyy)
• Other useful freetext information about the purpose of the stream, such as:
  • For customer specific development (e.g. pilot projects): the company name
    Example: APPROVE_Volvo

For tasks: The task name and/or unique identifier
Example: APPROVE_PurchaseOrders

By Tomas Lundström, ReadSoft

Reporting is pretty basic in AccuRev. Here’s a simple tool for Windows you can try (this site would not allow zipped uploads). It’s a beta, feedback is welcome.

Excerpt from the README file:

WHAT IS ‘RELEASOR’?
Releasor (short for Release Notes Generator) is a simple reporting tool for AccuRev.

It basically answers the question “what Issues have been addressed in stream S between times t1 and t2?”

(A future version will also allow for difference reporting between arbitrary streams)

The resulting report is presented either as HTML or as a tab-separated text file, suitable for Excel.

Releasor was created by tomas.lundstrom@readsoft.com

SYSTEM PREREQUISITES
* Windows XP/2003 (Vista not tested)
* .NET Framework 2.0 installed
* AccuRev 4.x.x installed
* accurev.exe must be in the path
* Minimum 1280 x 1024 desktop resolution

LIMITATIONS
* Report format is Issues only (even though the preview can be viewed as transactions and files as well)
* Preview fields are hardcoded at this time
* Releasor does not log in to AccuRev on its own, so there must exist a valid Accurev session.
* Help is limited to a few tool tips.
* Error handling/recovery is not complete
* Requires the default field ’shortDescription’ to be present in the Schema

by Lorne Cooper, CEO, AccuRev 

A Top 25 WordPress Blog Post of the Day

In Part 1, we looked at the sins of Building a Weak Team and Ignoring the Future.  Once you’re committed to hiring talent and building a forward-looking process, there are two more sins to avoid.

Sin #6: A Long Tail After Development is Complete

We constantly see organizations where the time from “requirements-in” to “feature freeze” is half the time to “solutions-out.”  That 50% “tail” on development provides no direct value to customers, but is there because of limitations in our development process.

Sometimes that tail is twice the length of the initial development. 

Ironically, while the long heavy tail is grown to protect the organization from delivering bad product, it eventually decreases response time until it becomes an instrument in the organization’s death.

But many industries have a long tail, don’t they?  Surely it doesn’t hurt the construction of bridges that the plans are completed long before the bridge is built.

For forty years people have tried to make analogies between software development and more mature engineering disciplines, say, like building buggy whips.  The designer of the buggy whip might make a sample or two to try it out on his children, then send it off to the factory, where a slew of Industrial Buggy Whip Engineers would spend months figuring out how to sew the damn things, buying up horse-hair, and hiring immigrants to sit at sewing machines. A year or so late, Pony Express delivers the new buggy whip to general stores all over the Grand Trunk Railway line. 

We can all certainly learn a lot from that.

Now try telling your customer that the problem she’s been working around is well understood, and in fact fixed, but she’s not going to get it for three months.  She’ll be looking for alternative suppliers before the screen door has hit your butt. 

Everything moves too fast to use that tired old process.  Frankly, I use to blame computers.  Now I blame the Internet. 

When you take a hard look at the time it takes to get completed product out the door, you’ll probably find it dominated by two things: testing, and fixing bugs that the testers find.  Both stem from the problem that you’re not doing enough testing during the development process, and you’re trying to test too much at one time.

I’m no fan of Hawthorn-effects, or what the politically incorrect might call gimmicks, like pair programming or stand-up meetings, but projects that use an Agile development with automated regression test processes are certainly doing more right than wrong. 

Is it really so hard to manage by tasks/issues, normalize them to a small unit of work, merge in just one set of changes into each build, and test just that perturbation?  What if you knew you would consistently get better code out the back of the process, and therefore make your organization more responsive to your customers?

Your development process must minimize latency, instead of trying to maximize bandwidth.  Don’t miss the changes in requirements and environments that produce opportunities for better products, or sooner or later you’ll end up locked in a suicide pact with a project no one wants.

Sin #7: Complacency

Calais’s stone walls were so thick the city had no fear of invaders, until they showed up with cannons.  Napoleon’s Old Guard was undefeated in battle after battle, until they were cut down by Wellington at Waterloo.  Big Blue’s OS/2 would crush little Microsoft’s Windows product.  Big Microsoft’s Live Search would crush little Google’s search engine. 

Hubris on ice will leave you with a heck of a hangover.

That brilliant team using that wonderful process you put together last year, is just a few months of complacency away from dysfunction.  People move and, thanks to the 13^th Amendment to the US Constitution, may leave their jobs and there’s little you can do about it.  Environments change and architectures become outdated.  The marketplace changes and requirements change with them.

One VP Engineering I know told me he asked his off-shore application development partner to give him 110%.  They did, but it turned out to be turnover.

Your process needs to be constantly monitored and upgraded, because everything in the process is changing.  If your offshore partner has high turnover, their part of the process might require more code inspection and knowledge transfer.  If your biggest customer can’t use your product until it supports their new environment, you need to put a special team on building a custom version of the product, and then merge that back into main development.  If you have to replace an old veteran with a rookie, then you might create new integration points and a more rigorous test protocol.

Recognize that everything will change, and the assumptions under which you built your last success are no longer valid.  Make small process changes early and often, or in the long run the big changes will be made by your replacement.

Stirring Conclusion

Managing a software development organization is a very challenging task, as tough as playing a violin with your toes, and less fun. 

I don’t mean to trivialize important management functions such as customer management, budget and project tracking, running a good meeting, and designing effective compensation structures. And by all means, hiring someone to spend their time doing all of that.

But that won’t protect you from the seven deadly sins.  Only you can do that.

I’ll finish with the Four Virtues, which are the antidote to the Seven Sins:

1. Hire great people or don’t hire.
2. Plan to build a product that will have a long life.
3. Keep your process nimble, and deliver less, faster.
4. Keep improving everything.

by Lorne Cooper, CEO, AccuRev

A Top 25 WordPress Blog Post of the Day 

Here at AccuRev our business requires we dive into the development process of dozens of software development organizations each month seeking our expertise. While reasons for success differ, there seems to be a pattern in ways organizations fail to deliver on their goals.

Here are seven pitfalls and tarballs to avoid when managing a software development organization.

Sin #1: Building a Weak Team

Great people build great products that generate great value. The rest of them fill up meeting rooms discussing whether they can get that bug fixed by Friday.

Sure, sooner or later someone will show you a great product developed by a committee of average engineers. Until then, do what you have to do to get great talent, and demand exceptional things from them.

Not sure if they’re good or great? Ask them to do the impossible: the good ones will tell you why they can’t do it, the bad ones won’t understand the problem, and the great ones will smile, and then ask for a little more time.

What kind of people answered (what is claimed to be) Sir Ernest Shackleton’s ad for his expedition to Antarctica?

Men Wanted: For hazardous journey. Small wages, bitter cold, long months of complete darkness, constant danger, safe return doubtful. Honour and recognition in case of success.

Sin #2: Blaming the Workers for their Bad Management

Is disaster a function of the people or the process? If great products come from great people, do failures signify you’ve hired too many chumps, and it’s time to play French Revolution with your development team? Can’t be the manager’s fault, after all, since the managers are the smart ones, or they wouldn’t have been made managers! Right?

Leadership and Management are the steering wheel and the accelerator. Development and QA are the engine. Why blame the engine for hitting the tree?

Can a project succeed despite poor management? Absolutely, and it happens all the time. Sometimes the needs are so dramatic, the architecture so obvious, and the team so experienced, that success is as certain as a Russian election.

But project failures are always the fault of management or leadership. If the engineers couldn’t do the job, good managers would swap them out, and good leaders would motivate them.

With added power comes added responsibility. Good leadership tolerates and anticipates engineering errors, but has little tolerance for management failings.

Sin #3: Short Term Thinking

If they paid you by how long it took to replace your software, you’d be a rich man, and could pay someone else to spend their time reading my blog.

When do you replace your underwear? When a new color comes out? When there’s a new innovation in cotton? If you’re an engineer, of any gender, you wait until that underwear is worn ragged.

And that’s the problem with software. It doesn’t wear out. In fact, it probably runs faster now than it did ten years ago when it was shipped. And it has more reports, more adapters, and more integrations than it did then, too. Ask any CIO: it’s hard to get rid of working software.

If you admitted your product was going to go through ten major revisions over eight years, and be used by 100,000 people, would you do anything differently? My guess is you would invest in a strong architecture, design code for re-use, and develop tons of automated tests. How about if it were to go through three revisions in two years and be used by 100 people? Same answer!

Investment in architecture is what determines whether your crack development team spends its time designing tomorrow’s skyscrapers, or on spreading spackle in the cracks in your old foundation.

Bad architecture is the answer to the question of “Where did all that money go?”

Good architecture is the answer to “How did someone so young get that job?”

Sin #4: No Investment in Code Re-Use

Good implementation recognizes that code’s going to be there for a long time, and what we build should be re-usable components. Ok, they don’t build bridges that way. But then again, the cost of building the second copy is a little higher.

If there’s one thing we can learn from the TQM experts, and even one might be optimistic, it’s that code reuse is the single most important thing you can do to improve your development organization.

If there’s one thing we can learn from experience (which might be even more ambitious, seeing how people drive in snow), it’s that Code Reuse is hard. Hard, and expensive.

Getting code that works properly is tough. It sure is nice to use something that already works. Tends to decrease the bug rate, increase development effectiveness, and best of all, gets the product to QA with fewer bugs.

Don’t forget that the amount of time it will take to get the product _out_ of QA is a function of the number of bugs it brought with it _into_ QA in the first place. An exponential function. Which, for those of you with Art History backgrounds, is a bad thing.

Code re-use is like changing the oil in your car. Slows you down, costs you money, but in the long run will save you a bundle.

Sin #5: Manual Processes

If you are going to have to do the same thing five hundred times, you’d certainly automate it. Same if you were going to have to do the same thing fifty times. How about five? With testing, the answer is yes, even if it takes ten times as long, as to do it once, you should automate it, because you’re very likely to be wrong and you will end up running the test twenty times.

This sin is pretty much the sin of “sloth” of which my grandmother used to accuse me every time she saw me pull off my shoes. Every development manager who has put on the stripes knows that good architecture code re-use, and automated testing is big. But each time we have short term project pressure, we find it hard to spend the extra time, and it’s not a little extra time; to invest in the infrastructure, streamline the functionality, expand the testing, and document the function, so we’re ready to meet tomorrow.

Part 2 conclusion

Build management is a long-overlooked area of software development. As is often the case with underserved areas, the open source community has several good solutions. Maven is among the most interesting and functional solutions for Java developers. I had the chance to take the AccuRev-Maven m2eclipse integration out for a test drive recently. This is a recently announced integration (read the press release here if you are interested, and see my video demo here).

The integration follows the pattern of other software configuration management (SCM) integrations with m2eclipse. A backend provider interface was written to support AccuRev, and the provider was integrated into the m2eclipse environment via the SCMHandler mechanism. I used m2eclipse in conjunction with AccuBridge for Eclipse (the AccuRev-provided Team plugin) to materialize Maven projects into a new AccuRev workspace from within Eclipse, and then did some basic Maven build and AccuRev SCM operations.

To get started, I needed to install m2eclipse from Sonatype. I used the Eclipse Update Manager to do this, by creating a new remote site in Update Manager for Sonatype (http://m2eclipse.sonatype.org/update/). I already had the AccuBridge for Eclipse plugin installed, also obtained via Update Manager (http://www.accurev.com/download/eclipseupdate/32/). After restarting Eclipse, I was ready to test.

In my test environment, I had an AccuRev stream called maven_int that I had pre-loaded with (of all things) the source and test code for the Maven integration itself. My goal was to create a new AccuRev workspace based on this stream from within Eclipse that was Maven- and AccuRev-aware. To do this, I used the Eclipse Import functionality and selected the “Checkout Maven Projects from SCM” option. Since I was using AccuRev, I chose the AccuRev provider from the drop down list box. Like other integrations with Maven, AccuRev supports a URL format for specifying where to obtain code. The URL lets you specify the AccuRev user and login credentials, as well as the exact depot and stream from which to import the code. I also chose the make workspace checkout option, which tells the plugin to create an actual AccuRev workspace in a specified location.

After pressing the Finish button on the Import wizard, m2eclipse called out to AccuRev, created a new AccuRev workspace, and created new Eclipse projects (based on whatever Maven POM files were found in the maven_int stream) containing the source code. I then associated the Eclipse projects with AccuRev using the Team Share option so that I would have full access to AccuRev functionality.

Since the projects were all Maven-based, building was done by right clicking on the POM file and selecting one of the build options. To convince myself that the AccuRev functionality worked, I did some edits to a few files, saved the changes, and then used the AccuRev promote option to version that file in the AccuRev repository.

Overall, the integration worked as I expected. The installation of the plugins was fast, it was easy to materialize Maven-based projects from AccuRev, and all of the important Maven and AccuRev functionality was available in the respective plugins. If you are an AccuRev user and want to use Maven, then the combination of m2eclipse and AccuRev integrated inside of the Eclipse environment is a practical desktop tool for managing your local builds.

We’ve been using CruiseControl productively for a number of years. First as a stop gap in ensuring build success on multiple operating systems, later as a quick check of tests. More recently we’ve added reporting, and tests as part of a larger memory analysis platform.

But, being a bunch of software developers means we are continuously craving something different, like switching to Haskell and using Ruby on Rails. Joking aside (and nobody panic) it is more that we look at areas of our build processes to identify the pain points, and what can be done to improve them. I mean, that’s how we provide value right? By continuously improving processes and features.

This time we took a look at things we don’t change often, but end up injecting a lot of pain into the process each time they are done. And these pain points become more obvious as we increase our agile usage, as they occur more frequently than they did in the past.

How often do you go through your “official” release process? In my past life it used to be this occurred every six months at best, a year or so on a bad year and a long time ago (in a far far away land) I had the opportunity to work on a project that lasted 7 years. Now granted I certainly wasn’t on it for seven years, people tended to drift on and off the project but it took seven years to ship. That was a long time ago.

Today we are looking at monthly cycles, or in the case of very specific changes even two week cycles. Those painful processes that were blotted out with 6 months between them now happen pretty frequently. We used to not bother with the problems, just moan a little and trudge through it. But agile changes that. Continuous Integration changes that. These processes should work, be easy to change, and adapt quickly. Anything that doesn’t adapt you want to drop as quickly as possible.

To do that we’ve started looking at new tools for our processes. Because new tools solve all your problems right? As soon as you started compiling in C++ from C all your problems went away right? Okay not really. Tools are nice, tools make a good impetus for change, but change solves your problems. Yes moving to C++ provides you with access to new functionality, but only until you actually implement and use exception handling in a structured manner do you really get value out of the tool.

Sometimes it’s felt that the tool is enough. I mean when you switched SCM products you kept your old processes. Sure, maybe they didn’t quite fit the new tool and you had to write a lot of scripts, but it was what you were used to. You may even be nodding your head right now. Nothing like shoe horning a process you created 5 years ago into a tool adopted last year. If you didn’t change your process how did the new tool provide value? Performance and scalability may get you some value, but new features and usage patterns get you a lot farther.

As part of examining our build and integration tools, we looked at processes. What areas of our process are not formal? Is there a specific person who knows the incantations to make it work? What happens when machines fail, do we have alternative machines that can take up the slack? Can we run multiple builds on the same machine? Multiple tests? How do we get and review our results? What are the top 3 pain points for each person involved?

Not only does asking these questions help us understand the process better, but it identifies the areas of change. And with these changes we can leverage both our existing tools as well as the new tools we’ve chosen to acquire. It helps our existing team, and it helps those who join us in the future. They’ll be more productive faster. We’ll have time to work on the features our customers want, and instead of just getting by we’ll be able to use forward looking technologies.

Today, AccuRev and Rally announced our technology partnership. You can read the press release here. Since I was part of the engineering team that did the initial proof-of-concept integration between AccuRev and Rally, I thought I’d spend few moments writing about the integration and how it helps customers connect requirements managed in Rally with code changes managed in AccuRev.

First, for those of you who prefer the movie to the book, you can view a short video demonstration that I recorded here. It highlights the main functionality of the integration.

Now to the details. Rally provides agile project management, including story and defect tracking, to assist customers in managing the rapidly changing flow of requirements and issues that are common in Agile development processes. AccuRev provides innovative stream-based SCM and integrated issue tracking to enable software process automation within the SCM tool. The integration ties AccuRev and Rally together to tighten the loop between requirements and defects, and the code changes that developers perform in order to satisfy those requirements or fix the defects.

The integration, written in Ruby and Perl, consists of three parts.

1. The integration queries AccuWork, the integrated issue tracking system that is available with AccuRev, for all ’New’ defects. It then transfers these defects into Rally, and makes an annotation in a custom Rally field called ‘AccuWork’. This field stores the AccuWork issue ID number.

2. When developers working in AccuRev make a code change, they will promote that code to an AccuWork issue, and place the ID of the Rally defect (created in the first part of the integration) in the promote comment. The AccuRev server_post_promote trigger (written in Perl) then fires and executes another piece of Ruby code that parses the promote transaction and sends relevant information about the code change to the Rally defect specified in the promote comment. This information is entered into Rally automaticaly and shows up as a ‘Discussion’ entry on the defect. Currently the integration posts the names and version identifiers of the AccuRev files that changed, the user id of the developer who did the change, and the timestamp of the change.

3. Finally, when a developer or Product Owner using Rally sees the code change, they can set the status of the defect to ‘Fixed’. Ruby code can then be run automatically that looks for all ‘Fixed’ issues in Rally, and changes their status to ‘Fixed’ in AccuWork. It does this by looking for the custom field ‘AccuWork’ created in the first part of the integration, extracting the issue ID number, and formulating an update XML message to AccuWork instructing AccuWork to update the specified issue.

That’s pretty much it. Working in Ruby and using Rally’s Ruby REST API was very straight-forward, as was working with the AccuRev XML API for querying and updating AccuWork. The end result is an early stage integration that provides basic requirements traceability between issues in AccuWork and Rally, and the coding activities of developers. I hope that if anyone is interested they’ll view the video and let us know what other features they’d like to see, so we can add them to our backlog and to future iterations of this integration in engineering.

Yesterday I was a panelist for a Webinar on agile tools, focusing on software configuration management (SCM), build and software process automation (SPA), the latter term referring to the set of defined, repeatable and measurable automated development workflows that engineers use to transform requirements into shippable software products. Contrary to what I’ve read about the disdain that some agile devotees have for tools, most of the attendees were hungry to know what features their SCM tool should have in order to support agile software development and SPA. Here are some of the highlights, and of course, my take on why I think AccuRev is the best tool for agile software process automation.

There are five key feature areas that an SCM tool needs to support in order to be ready for agile:

* Support for flexible process models

* Continuous integration support

* Support for issue-based development

* Efficient branch and code management

* Private version controlled developer workspaces

Let’s take a look at each of these in turn.

* Support for flexible process models. Agile is often one of several processes being employed within a software development organization. Unless your SCM tool is flexible and process-neutral, you will have a hard time implementing agile (say, for product development) and more traditional processes like waterfall (for example, for product maintenance work) in the same SCM tool. AccuRev streams are a natural way to model any process, and thus are a good fit when agile needs to coexist with other development processes. As for software process automation (SPA), AccuRev streams again are a great fit, since they enable users to model any arbitrary stages of code transformation that a development team sees fit to define as part of their process. By adding triggers and workflow to a stream hierarchy, teams can implement SPA directly in AccuRrev.

* Continuous integration support. Continuous integration is one of the core process elements associated with agile development. By building and testing frequently and acting on the results of tests, teams can uncover defects or test gaps earlier in their development cycle, saving time and money compared to such discoveries late in the cycle. But continuous integration goes beyond just testing the nightly build. With multi-stage continuous integration in AccuRev, code is automatically promoted up the stream hierarchy into more stable configurations as it passes tests. At each stage, continuous integration takes over to build and test, typically with a wider scope of testing as the code nears the release stage. Legacy SCM tools make this type of automated integration factory somewhere between difficult and impossible due to the complexity involved in setting up the hierarchy and in automatically moving and merging code as it flows up the hierarchy.

* Support for issue-based development. Apparently there is a lot of contention about the need for filing issues and defects in agile development. This has puzzled me greatly. While I’m in favor of developers identifying and fixing issues as they are discovered, you lose valuable process information when a defect or enhancement ticket is not filed and later associated with a code change. Without an issue that describes what the problem was, someone looking at the code changes for audit purposes or for group code reviews is at a disadvantage. Why was this code change made? Is it related to other changes? How long did it take? Was it done to fix a bug or to add a feature. In AccuRev, issues either in the integrated AccuWork issue tracking system, or in a 3rd party issue tracking system, can easily be associated with code changes via the AccuRev Change Package mechanism. This establishes basic traceability between issues and the code changes that developers make in order to satsify the requirements of those issues. Issue-based development is well-defined, repeatable and measurable - all hallmarks of good software process automation.

* Efficient branch and code management. Any time you’re working on more than one project, you need to isolate that project’s code from other projects. With agile and multistage continuous integration, even a single project requires multiple code lines in order to separate in-progress code from unit tested code from system tested code that is ready for release. If an SCM tool makes branching, merging and labeling difficult, teams tend to practice branch avoidance, which I sometimes like to call “fear of branching.” This is a classic example of letting a tool dictate what processes you can implement. In AccuRev, streams replace branches as the mechanism for isolating codelines. Since streams are represented inside of AccuRev as data separate from the actual file versions, creating streams is fast - really fast, like, a second or two - and managing a system with hundreds of streams spanning multiple projects and processes is easy.  For continuous integration, AccuRev snapshots and time-based streams are also fast and easy to create and manage, and give users a straight-forward way to “label” an interim or milestone codeline without having to place markers in thousands of source files.

* Private version controlled developer workspaces. Software developers are the heartbeat of any engineering organization. Executives at any development shop will tell you that hiring talented engineers and keeping them well-tooled and productive is the single largest challenge that they face. For agile, this is even more of a challenge, since coding cycles tend to be shorter, and thus anything that gets in the way of individual or team productivity tends to have a greater negative impact on the project. Private version controlled workspaces like the AccuRev workspace model improve productivity, since they enable developers to work in isolation (while they are ‘heads down’ coding). Private workspaces in AccuRev also give developers full SCM capabilites in their workspaces without the need to share in-progress code prematurely. By using the ‘keep’ operation, developers make safe copies of their work in the AccuRev repository, and later can ‘promote’ the code to an integration stream to combine their work with that of their teammates. Individuals are more productive in this way, and if continuous integration builds are frequently testing the integration stream, so are teams.

In a nutshell, agile requires tools, and these tools need to support different modes of operation than with other processes. SCM can help or hurt you in setting up and executing an agile process, so these guidelines are a way to help you get your SCM tool ready for agile - easy of course if your tool is already AccuRev!

If you’re interested, you can view the webinar recording.

Is Your Software Development Environment Agile-Ready?
Free On-Demand Webinar