If you scratch any software configuration management (SCM) system hard enough, what you’ll really find is a source control system. In reality, SCM and source control are basically one and the same. Having truly effective SCM is all about having good source control.

The challenge today for any software developer is the rapid pace and simultaneous development that has dramatically changed the development landscape over the past few years. Throw in the latest Agile development processes, mix in some more traditional methodologies, including XP and waterfall, and now you’ve got a real witches’ brew of development activity that can put a strain on source control.

One of the reasons we’ve developed AccuRev SCM is to provide a sound source control system. Something that enables distributed teams to communicate, collaborate, and integrate code as seamlessly and effortlessly as possible while providing full transparency to all source file changes.

So what exactly are the benefits of a source control system? Here are some main ones:

• Source control enables multiple development teams to access and share code simultaneously, enabling effective parallel development
• It enables code to be managed and protected to help ensure file integrity
• It provides a way to label, or version, a chunk of code — even whole sets of code — so that a complete file history can be maintained for faster, more effective development and revision
• It helps with change management so that new software versions or added functionality can be tracked and approved

As a source control system, AccuRev SCM really helps developers by providing process visualization, drag-and-drop SCM automation and issue-based workflow using something we call “streams” – a type of architecture that’s a sort of “intelligent” branching. This type of architecture provides outstanding source control because each stream contains every file for a specific source code configuration. This, in turn, makes branching and merging easier, even in a distributed, parallel development environment. This streamlined architecture enables teams to store their work and test it before sharing it so that merging code becomes a lot easier and safer.

With a good source control system, you’re able to accomplish some pretty amazing stuff. We’ve found that AccuRev SCM can:

• Improve Agile/hybrid process project collaboration
• Improve software asset reuse
• Accelerate time to market
• Lower total cost of ownership
• Accelerate the software development process by 30%

Efficient, optimized software development starts with solid SCM, and that means a good source control system.

Related Recipes: AccuRev + Eclipse + Ruby.

In this developer-centric recipe I am going to setup a power-tool trifecta consisting of Eclipse, JIRA, and AccuRev. I’m not talking about installing each independently. No, no, no. This recipe is going to take things one step further and configure full bidirectional integrations for a wickedly powerful, fully integrated development environment where the majority of common day-to-day development tasks can be done right within Eclipse (right picture). Integrations are the crux of setting up a best-of-breed tool strategy and if you use these three tools you definitely want them talking together (left picture). Enough chop, let’s rock.

Install Applications

Let’s start by covering the basics and installing the latest versions of all three tools.

1. Install AccuRev 4.6.x. download. Follow the install wizard. See the quick setup guide to import code and setup streams [Windows page 1 / Linux-page 13].
2. Install Eclipse 3.3.x. download. Follow the install wizard. See documentation if needed.
3. Install JIRA 3.12.x. download. Follow these instructions.

At this point, you have three independent tools installed. Developers can checkin/checkout code from AccuRev, use Eclipse to modify the source code, and track bug/feature development with JIRA. In all, not a bad setup. But toggling between all these tools just takes valuable time away from coding and there is no mashing of logically related meta-data to generate useful reports… such as:

• “Which files/lines fixed issue #1234?”
• “Was bug #5678 fixed in mainline, 2.x, and 1.x codelines?”
• “Release is this Friday. How many issues are unresolved in the QA area and who are we waiting on?”
• “Which fixes went into Release 4.5.101?”
• “If I start working on the 4.x codeline, which known fixes will I be compiling against?”

Integrate Eclipse + AccuRev

Let’s eliminate jumping between Eclipse and the AccuRev CLI or StreamBrowser GUI. Rather, why not just keep/promote/update/merge directly within Eclipse. You can install our native Eclipse plugin via the Eclipse software updater.

1. Help –> Software Updates –> Find/Install
2. Select ‘Seach for new features to install’
3. Create ‘New Remote Site’ named ‘AccuRev’ with URL http://www.accurev.com/download/eclipseupdate/32
4. Checkbox ‘AccuRev’ and select Finish

When you create a new Project, choose to “Checkout from AccuRev.” Now the Eclipse ‘Team’ menu has a sleu of AccuRev commands available for inline use and your file navigator has icons for version control status. Sweet. Note: there is an AccuRev quickstart PDF located in your Eclipse plugin directory (e.g. /opt/eclipse/plugins/com.accurev.eclipse_4.6.1.32/UsingAB4Eclipse.pdf).

Integrate Eclipse + JIRA

Have you heard of the Eclipse Mylyn project? Seriously, it’ll bring a tear to your eye. In short, Mylyn is a generic framework for ‘task management’ within Eclipse and has a number of connectors to tools like JIRA, Bugzilla, and Trac. Guess what? You can interact with JIRA directly within Eclipse. It’s sick! seriously. Once again, you can install directly from the Eclipse software updater. First install the Mylyn framework and then the JIRA connector.

1. Install Mylyn 2.0. Follow this setup guide. Basically, just like the AccuRev plugin above, create a remote updater site with this URL: http://download.eclipse.org/tools/mylyn/update/e3.3
2. Install JIRA Connector. Follow the short setup guide provided by Atlassian.

As a developer, your world just got a whole lot better. Not only can you commit/update file changes directly within AccuRev, now you can open/close/update JIRA issues all without leaving Eclipse. Nuts!

Integrate AccuRev + JIRA

The final piece to the puzzle. Wait? What does hooking AccuRev to JIRA actually mean?!

Lets take a step back. Back in the day, using one of those other traditional branch-based SCM tools, you probably entered your bug #id into the commit comment. Commit 10 files. Enter bug #1234. Commit another 7 files. Enter same bug #1234. Very loose. And you probably had some validation and reporting scripts all stacked on top to keep things (hobbled) together. At the end of the day, this was far from a ‘tight’ integration and a struggle to maintain and enforce. Answering the simple question “which files -and- lines were fixed for bug #1234″ was not easy (probably impossible!).

AccuRev Change Packages. AccuRev has an out-of-the-box feature called Change Packages that natively tracks a set of files (as patches) regardless of the number of commits. Change packages are first class citizens in AccuRev. You can promote multiple times to the same change package and even remove files. The trick is to understand that a change package has a 1-to-1 relationship with… an issue! And those issues can come from JIRA. So as you work in your AccuRev workspace coding day-to-day you can promote your changes and assign them to a JIRA issue. Then make more changes and promote to the same issue. Think of it like this: creating a feature or fix may take 1 day or 100 days; 1 commit or 50 commits; Change packages don’t care. They just track the current set of files that you claim are ‘logically’ related as part of a fix or feature. That’s it! I’ll keep this short, but basically, you can now use the change package / issue as a new, first-class currency for promoting further up and/or patching those changes to other codelines! It’s very powerful. See pg 33 of our Concepts Guide for details. But I digress.

Back to the recipe. Hooking up AccuRev and JIRA means that AccuRev receives issues from JIRA and JIRA receives meta-data such as fixed files and versions for each issue. The setup requires our own connector technology called AccuBridge for JIRA. It’s pretty easy to setup and simply requires mapping JIRA fields to AccuRev fields and setting up the data synchronization. There is a well written ‘quick start’ guide to walk you through the entire setup process.

1. Install AccuBridge for JIRA. download (link half-way down). Follow the setup guide located in the download package: doc/ais4jira_quick.pdf. [Note: Additional licensing may be required]
2. Enable Change Packages. See pg 75 of the Admin Guide. Basically, you need to tell AccuRev ‘when’ to prompt users for issues, ‘which’ issues to query for, and which data columns to display in the lists. [Note: AccuRev Enterprise Edition is required]

At this point, developers are promoting file changes to JIRA issues and JIRA can report on ‘who’ fixed ‘which’ files for any given bug/feature/task. Now that’s what I call traceability!

All Together Now!

With everything hooked up, what do we have? Simple. As a developer you can do just about everything directly within Eclipse. Edit files. Commit and update changes from AccuRev. Create issues and update comments/status/fields in JIRA. And behind the scenes, the JIRA records are being annotated by AccuRev as files are promoted out of Eclipse. Eclipse is your one-stop-shop workbench for developing, tracking changes, and managing task workflow (see picture).

Next we’ll add a build tool to the mix that integrates with AccuRev, JIRA, and Eclipse… But that’s for another day. Sounds great though, doesn’t it!

/happy coding/ – dave

I’m happy to announce the latest release of the GNU Bash programmable completion for AccuRev 4.6!

For those AccuRev users out there that know the true power of the GNU Bash shell, life just got even better.

This GNU Bash plugin has its own site at http://bash4accurev.wordpress.com for downloads, announcements, documentation and user feedback (ala blog style). You can download the plugin from the download page.

The plugin requires GNU Bash 2.05+ and supports AccuRev 4.6.x. It was developed and tested using linux (Ubuntu 7.10) and GNU Bash 3.2.25.

Important note: While the plugin was developed by an AccuRev employee (me) and GNU Bash user for 10+ years, it is considered a third-party open-source plugin and is not officially supported by the folks @ AccuRev support. That being said, I’m proud of the plugin and welcome feedback and enhancement requests for the next release. You’ll find my contact information on the plugin website.

/happy tabbing/ – dave

I keep expecting customers to ask me “Is it contagious Doc?” Or state, “but I am an only child!!!!!” What am I referring to? Evil Twins!!! Sounds menacing right? It really is not, but to a first-time user or someone who has never encountered the warning, “Name already exists in backing stream,” it can be rather perplexing.

So what exactly is an Evil Twin you ask? It is a situation where two completely separate file elements in the same directory structure have the same name. It is actually a common problem across many software configuration management (SCM) systems. So how does this happen exactly? All it takes are two well intended individuals with their own workspaces. Lets use the following scenario, User A and User B both have their own workspaces attached to the same development stream. Currently we have the following directory structure;

\.\dir1\child_dir\

with the following files already under source control:

file_a.txt

file_b.txt

As part of our software project, we also need to create one additional file:

file_c.txt.

User_A creates and adds file_c.txt to source control in the child_dir directory and promotes this newly added file into the development stream.

At the same time, User_A was creating and adding file_c.txt, User_B did the exact same steps. However, A was first to promote so in effect User_A won the race. When User_B attempts to promote his/her file_c.txt the “Name already exists” error pops up front and center and does not allow the promote to continue. Evil Twin prevention at it’s best.

AccuRev tracks an element by its eid (element identification number) and not its name. This is how an Evil Twin is detected. When User_B attempts to promote File_c.txt AccuRev knows that there is already a File_c.txt in the development stream but notices that the eid’s do not match. They are truly separate files since they were independently created and added by different users. They are Evil Twins because they look identical but are different. Really only one of the two is Evil and that is typically the file that ends up getting removed/renamed. But that is another story for another day.

So what should an AccuRev customer do when encountering this problem? Give support@accurev.com a shout and title your email “Need Evil Twin resolution help” or “Name Already exists in backing stream error.” Or you may also take a look at the AccuRev Online FAQ’s in the Customer Support Forum.

Please feel free to let me know if this helps you out!

AccuRev 4.6 for ClearCase, which includes our new ClearCase Coexistence Adapter, has been selected as a Finalist in the 2008 Jolt Product Excellence Awards! James has been sharing with you some of the core new features in AccuRev 4.6 in his previous posts, such as the VersionSlider and viewing work-in-progress at the Issue level, but for a more detailed look, check out the What’s New in 4.6 Web page.

2007 was truly the year of both SCCM conversion, and co-existence (a relatively new concept). While AccuRev added significant new features to its core offering this year, enabling co-existence with leading SCCM solutions is jolting in a number of significant ways.

AccuRev is the glue that allows teams to continue using their existing SCCM infrastructure, while integrating AccuRev into new or existing projects.  This eliminates risk and potential disruption associated with a comprehensive one-time conversion, and provides freedom of choice.

AccuRev 4.6 for ClearCase enables adoption of AccuRev in previously homogenous ClearCase environments, through real-time bi-directional synchronization without rework or porting. Ultimately, these organizations will save time, money, and deliver higher quality software.

Jolt Product Excellence Winners for 2008 will be announced at the SD West conference in March.

Happy Holidays!

One of the things that frightens anyone who develops code the most, or more accurately the people who are responsible for releasing or deploying that code, is the possibility that you might not have access to it within your software configuration management tool or version control system when you need it. Computers are fickle things; unless you are prepared to spend fantastic amounts of money for a truly redundant hardware/software infrastructure, there is always the chance that your system could be inaccessible when you need it most. And this doesn’t even begin to address potential network outages.

AccuRev, because of the ease of backup and restore for one thing, and the always accessible locally resident Workspaces for another, is a great insurance policy against data loss and brings developer down-time to zero. But let’s say that one of those dreaded network outages or hard disk failures occurs exactly at the time when you need to pull the latest source over to your build system for a critical release. Or imagine any kind of similar roadblock you’ve run up against in your own environment. This is yet another area where AccuRev, with just a tiny bit of prep and foresight, can save you hours, if not days, of aggravation by ensuring that you always have access to your latest “buildable” code.

How does this happen? Well, consider first the AccuRev stream paradigm where – unlike branches – there is a well defined progression of code, from the high instability of a developer’s Workspace to the “always buildable” top-level release stream. You simply have to choose the stream that you would consider as your ideal location to retrieve “offline” code from. In the following StreamBrowser, I’ve chosen the top-level “Claims_Client” stream.

Create an AccuRev reference tree based on your chosen stream. Define the location on disk where that reference tree should populate the code to. Then, use a trigger (we provide examples with exactly this functionality) to Update that reference tree anytime a Promotion happens into this stream. The end result is that you have a specific file-system location that is *guaranteed* to have the latest and greatest code from any given stream that you want. Also, this approach is optimized because it only has to transfer changes, not the entire source tree, and there is zero manual intervention required! So in the case where the network or SCM server goes down, no problem for you; your code is happily hanging out right where you need it to be.

Some organizations are much more tolerant of this kind of scenario than others. If so, can you think of other times or examples where this kind of functionality would be helpful to you?

by Damon Poole

Comparing SCM Tools

People often ask me “what is the best SCM tool” or “is there a comparison of SCM tools available.” I would say that generic comparisons of SCM tools are sort of like generic comparisons of cars. Somebody looking for something that is fast and doesn’t care about gas mileage probably wouldn’t think much of a Prius.

Currently, IMHO, the SCM market is not a commodity market where the products are generally about the same. There is a wide range in both pricing and functionality. So, you really have to know your requirements and the priority of those requirements. A good initial priority to figure out is: which is more important to the organization; price or return on investment? There’s no sense in looking at all of the tools on the market if there’s not enough budget.

Determining Requirements and Building Consensus Among All Stakeholders

Generally, a good way to acquire a new SCM tool is to start from a well defined set of requirements, create a shortlist of 3-5 candidates that seem close, take a closer look and narrow that down to 2, and then do a proof of concept on those 2 and pick the 1 that most closely meets your requirements.

Depending on the size of the development group and the size of the company, acquiring a new SCM tool can be an eye-opening experience. Finding a tool that meets your requirements is perhaps the easiest part of the process. Some of the harder parts are: figuring out who all of the stakeholders are, getting all stakeholders to consensus on the requirements, getting upper-management buy-in, and securing the budget for the purchase. Getting budget and requirements to match is generally the hardest part and typically involves writing some sort of business case to justify the purchase.

Here are some typical stakeholders: CEO, CFO, Purchasing Agent, Legal, VP of Engineering, Director of QA, key developers, and Release Engineering. Some of these may seem to have nothing to do with SCM, but they do get involved in large purchases that affect the whole company. It is better to make contact with all of these folks early to get the full scope of what is required to change SCM tools so as not to get surprised later and potentially impact release schedules.

If you make a recommendation that fits the budget and best meets the other requirements, but there is still a big gap in the requirements, don’t despair! If you’ve involved all of the stakeholders and built consensus, you have a good chance of leveraging that gap to increase the budget.

Start From High Level Use Cases

When moving from one software configuration management SCM system to another, it is often the case that people concentrate on “Which of the pains that I have in my current SCM system will this new system alleviate?” This is certainly a valid question. However, it is also important to ask “What benefits will the new system bring that perhaps I haven’t considered?”

Another common question is: “Our old system is missing a certain feature to compensate for a certain problem that the system has. We’ve developed a work-around for the missing feature. Does your system have the feature that is missing in our current system?” If the new system doesn’t have the problem that the old system had, then the need for the feature is often eliminated.

A better way to compare SCM systems is to start from high level business use cases. There are many ways to implement business level use cases for software development. Some of the implementation choices include: components, streams, tasks, and branches. An example of a business level use case is: “There are different versions of software installed at different customer sites. A defect is reported by one of the customers. The defect needs to be fixed in the version that the customer has as well as all other versions which have that problem.” The implementation of this use case will be different in a component-based and a stream-based system for instance.

When changing from one SCM implementation to another, be sure to start from your business level requirements instead of mapping from your current implementation to a different implementation. The reason for this is that the high level use cases do not require a particular implementation; they can be implemented using a variety of methods. If you have currently implemented the use cases with components, it is unlikely that directly mapping this implementation into streams will be the same as starting from the uses cases and implementing with streams. For most use cases, it does not make sense to map the way they would be implemented in your current system into a your new SCM system. While it is possible to do it, the result can be difficult to set up, understand, maintain, and use. This sort of implementation will also generally make it more difficult to realize the potential of your new SCM system. In other words, you may end up with the drawbacks of both worlds and the benefits of neither. The most successful approach will be to implement the high level business requirements into your new SCM system.

As a developer I’ve found it necessary from time to time to generate reports, especially for internal consumption. Internal reports tend to be more adhoc than those presented to clients or non-technology managers, and therefore have less time devoted to their care and feeding (and cost). While I’ve used Crystal Reports and similar tools for external reporting, most development reporting has consisted of spreadsheets and any charts that they generate in the ten minutes I have before a review meeting.

Always wanting to explore various technologies, I took the opportunity to try my hand at using the BIRT (Business Intelligence and Reporting Tools) implementation in Eclipse. If you’re interested in finding out specifics about this plugin, you can find it on the Eclipse web site. While I find the tool to have a higher learning curve than I would have expected, it shows promise for the future.

There are a number of data points that we generate as part of our development, and capturing all of them in a report format proves to be a surprisingly complex task. It is a task that gets little time and investment, as development goals are not report oriented, they are product delivery oriented. I’ve attempted to capture some of the more mundane details, and set aside future report details that require a larger effort. I’ll be describing what I’ve done to create the reports, but not really discuss about why or how to interpret the data. A discussion of some other data and what you can do with it can also be found here.

Here at AccuRev our projects are issue oriented. We use AccuWork, which is our own tightly integrated issue management environment.

Given that, and the goals for the reporting that I defined, I had to find a way for AccuWork to communicate information that BIRT could interpret. In the past using Excel, I’d simply query issues in AccuWork and export the data into an HTML table that Excel could then read in and, with the help of pivot tables, generate the desired reports. The basic information reported included:

1. Number of issues per developer
2. Count of issues by priority per developer
3. Distribution of issue resolution (Whether issues are duplicates, regressions, cancelled, deferred, etc)
4. Distribution of issue severity (Whether issues are crashes, major implementations, cosmetic, etc)
5. Weekday issue completed per developer
6. Weekly Find rate vs. Fix rate
7. Weekly average number of days to complete issues

Using this information, it is easy to see projects taper off to closure, as well gather some ideas as to how the developer workload was being distributed. Some developers cringe at this information, but I believe as long as it is used positively and to evenly distribute work, then everyone gains from reviewing this information.

With these same charts in mind, I loaded up my version of Eclipse, installed BIRT and its associated plugins, and started to figure out how to get the data into the tool.

BIRT provides a number of different data sources, from file based to database, to XML. While I would like a little more flexibility in the XML source, like the ability to preprocess data before usage, it provided me with the means to bring in issues from AccuWork, with a little external help. The first thing I needed to do was get the information from AccuWork.

I used ‘accurev xml -l getActiveIssues.xml’. The getActiveIssues.xml file I used looks like this:

<acRequest>

<issuelist show_active = “true”>

<user>myUser</user>
<depot>myDepot</depot>
<stream1>myProjectStream</stream1>
<issues></issues>

</issuelist>

</acRequest>

This tells AccuWork to return the active issues in the depot for the given stream. This will return a full description of the issues, with all the fields populated. This is where I would have liked a preprocessor. Instead I massaged the data myself, removing fields like description. It wasn’t necessary, but given the number of issues fixed it can improve performance when you generate your report.

With this information I was able to generate charts to answer the first four questions. Now I was left scratching my head on the next set, so I went back to the spreadsheet to see how I had solved this problem. I realized after importing the data into Excel, I had a number of columns that were computed values. Here BIRT shows some flexiblity, with its own computed columns.

I added the <dateClosed> field that is part of the issue description in AccuWork to the column mappings in BIRT, and created a computed column and used the following as the formula:

( row["dateClosed"] – ( row["dateClosed"]%(60*60*24*7) ) ) / (60*60*24*7)

AccuRev communicates information in seconds, so using this calculation I can compute the number of weeks since Jan 1, 1970 when a particular issue was closed. I did the same for dateSubmitted and dateCompleted. Finally, I created a computed column to determine the weekday completed using this formula:

(new String(“SunMonTueWedThuFriSat”).substr( (new Date(row["dateCompleted"]*1000)).getDay() *3, 3 ) )

This one is a little messy, so let’s break it down. Using the bolded section I compute the day of the week as a numeric value (zero based, starting with zero as Sunday). I then used this value to determine the substring as an offset in a fixed length string. Not so bad, and avoided the dreaded mid-processor (something sitting between AccuWork and BIRT) that I was afraid I would have to write.

So, using a single query from AccuWork, and computed columns in BIRT, I now have the data I need to generate the 7 charts I described earlier. Next time I’ll talk about what I had to do to get the information to chart in BIRT, and show some of the output.

Managing software development is tough enough as it is. Managers take responsibility for the results their teams deliver. They’re on the hook for hitting schedules, delivering quality, and meeting customer requirements. Worst of all, if they’re saddled with slacker engineers, they still have to get the work done, and done right.

Tools are needed to help managers stay on top of their projects and find problems when there’s still time to fix them, before the schedule pressures explode. Project management tools are valuable, but their schedules only reflect the quality of the information that went into making them. Garbage in, garbage out.

The SCM system is the source of the information that drives smart decisions. Here are four sources of real data that can come out of any quality SCM system. I’ll illustrate with AccuRev because, well, because it’s the best.

1. Bug Arrival Rate
2. Churn rate
3. Task Estimate accuracy
4. Complexity Creep

1. Bug Arrival Rate

A key graph in any project manager’s arsenal compares bugs reported over time against bugs closed over time. Here we use AccuRev’s AccuWork issue tracking tool to store all issues, whether reported by QA, sent in from customer service’s CRM, or entered by the powers that be as customer requirements. Since our iterations are four weeks long, we use the week as a reporting time period. Some AccuRev customers use days.

In AccuWork, queries are easy to create, and we get a report from AccuWork in XML covering all the issues opened or verified [foot note: In our terminology, developers “close” issues, and QA “verifies” them. Other companies have developers “submit” issues and QA “close” them] against a particular iteration.

The XML slides right into Microsoft’s excellent Excel 2003. I use PivotTables and Excel graphs for all my reports. Others might leverage their superior Perl skills.

Here, we add a “week” field based on the AccuRev time field.

2.Churn Rate

A key metric for quality is how often different parts of the code base have to be modified to address issues. Here, the AccuRev code repository has all the information we need. I use the AccuRev Hist command

accurev hist –a –s “release candidate stream” –fx –t “2006/1/8 – 2006/1/1”

to get an XML file of all the “Promotes” (sort of like “check-ins”) to a release candidate stream within a time range. Some use a separate “hist” command for each release period. Personally, I take a big time range and then use Microsoft’s Excel 2003’s XML file support to slice and dice into tasty chucks. I tried it once with Excel 2007. Once.

Since we component-ize our code base based on directories, the “path” field is particularly interesting, as directories can be as significant as individual files.

Loading the XML file into Excel, my macro deletes some unneeded columns and creates a Pivot Table like the following:

Here I’ve filtered the data to not include the binary files, and used the Excel Pivot table’s advanced feature to show the top ten in descending order. AccuRev.c takes a beating every release but it isn’t significant. Server/diff.c and Client/stat.c seem to be at the center of a lot of changes that release, and are probably candidates for some code reviews.

3. Task Estimate Accuracy

Along with dates of issue opens and issue closes, we have chosen to include a user field for the original estimate of the length of time it will take to complete the issue. That gives us something to compare to when we “close” an issue and send it to QA, and an opportunity to correlate against the length of time before an issue gets verified.

As a best-practice, we try to normalize issues to a couple of days in length. Longer and you haven’t really figured out what needs to be done. Shorter and you’re liable to strangle in your own spit, a management practice I can’t recommend having seen the results.

We get this data out of AccuWork again, and can slice it by group, release, or even individual developer. This is a quick way to quantify the subjective feel we all have for who is slow, who’s fast, and who’s clueless. Here’s a scatter plot for a group. Note that they are generally on the high side of their estimates, and that they haven’t done a very good job normalizing tasks to 2-3 days:

4. Complexity Creep

As software gets modified, and especially when managers become conscious of the amount of time taken to fix a bug or implement a feature, there is a tendency for developers to make the code base less maintainable. There are some metrics for code complexity that can benefit the manager when trying to assess when it is time to refactor. A frequently used metric is cyclomatic code complexity.

While we don’t do any code complexity measurements here, some of our larger customers do. This is easy to collect using a trigger on changes being sent to a release candidate (or QA candidate) stream, where the trigger calls the analysis tool and puts the results into a tab-separated file for later plotting from Excel.

A simple (Perl) implementation of the server side “server_post_promote” trigger creating a file “complexity.txt” looks like:

open COMPOUT, “>>complexity.txt” or die “Can’t open complexity.txt”;
if ($stream eq “acmeProj_QA”) {
$complexity = complexity($stream, $version, $workspaceDir, $filePath);
print COMPOUT “$user\t $date\t $transaction\t $stream\t $version\t $filePath\t $complexity\t $issueNum\n”;
}
close COMPOUT;

Together, these reports provide a good mix of data around schedule, estimation and code quality, giving our beleaguered project manager a pretty nice set of armor.

Please post your favorite management reports, even if you don’t (yet!) use AccuRev.

AccuRev is tremendous when it comes to managing the Software Development Process; you have complete visual control over how code will flow and progress through the stages you feel necessary as an organization.  This kind of capability generally appeals to folks at the executive level, or release and build engineers, or project management.

We haven’t forgotten about the developer though!  In 4.6 we’ve introduced the “version slider,” which allows  for a complete visual history of any element under source control, along with complete groupable annotation.  Quickly drag the slider to any previous point in time and you’re able to see what changes encapsulated that version, who made them, and group by various fields. You may have seen a similar screen capture to the one below from AccuRev in the pages of SD Times recently? Here’s an article on change management you may find of interest there as well.

I’ve never been a fan of the expression “blame game,” but for the detectives out there, this puts the clues to the Who, What, When, Where, and maybe even Why (if comments are used appropriately) of code change at your literal fingertips…