One question I hear a lot is “what’s so important about change and configuration management systems? Isn’t that just another layer of software that can clog up the software development process?” The fact is, a majority of software projects fail because of poor change and configuration management and improper use of SCM systems.

So what seems to be the problem? Well, efficient software development is often muddied by the increased use of outsourced development teams spread out over a variety of geographic locations, using a mix of Agile and waterfall modeling processes, and working on parallel projects. Choosing the wrong SCM system can reduce development efficiency, lock engineers into inappropriate processes, and cause defects to ship that can cost a boatload to fix and adversely affect overall product quality and, ultimately, customer satisfaction.

The right SCM tool, however,

• enables flexible processes for easier change and configuration management
• stands up to demanding frequent build, test, and release cycles
• helps improve quality while reducing the cost of the shipped product

In other words, the right SCM system, properly implemented and used, will make the entire software build, test, and release process faster, easier, and more successful. And isn’t that the whole idea?

Any good, comprehensive SCM system consists of four basic elements:

1. Version control, which tracks changes to a file over time
2. Build management, which enables developers to track a build’s progress and what goes into it
3. Release management, which handles the transition from initial build to shipped product
4. Process control, which ties it all together

The right mix of these four components will depend on the project size – more complex projects might require more build management, frequently-updated products might need more release management.

Size matters.
One of the most important aspects of efficient and effective SCM is right-sizing – making sure your SCM system is scalable to meet the size and scope of your development projects. Too often, organizations struggle with a one-size-fits-all SCM system that is simply inappropriate for the project at hand. Likewise, use scalable best practices; for example, don’t waste precious time and resources collective extensive project metrics for one-off projects – save the thorough data collecting for more complex builds, potential version updates, and product line extensions.

Managing change and configuration
All development processes, waterfall or Agile, need to handle branching, merging, and refactoring as efficiently as possible. Code often needs to be modified or revised for maintenance purposes or to facilitate emergency releases associated with defect repairs. Your SCM system needs to be able to handle branching, merging, and refactoring effectively to ensure that any fixes carry forward from maintenance releases to major future releases so that any errors or bugs don’t perpetually pop up as ongoing problems after their initial fix.

SCM Best Practices to improve your software development processes
To help you implement the ideal SCM system or improve your current one, here are eleven SCM Best Practices to aid process improvement and make your SCM as efficient and effective as possible:

• Forget one-size-fits-all SCM
• Design scalable Best Practices
• Plan your SCM environment carefully
• Ensure absolute reproducibility for all artifacts
• Require change requests and change packages
• Maintain private developer workspaces
• Create and work from appropriate baselines
• Leverage metrics for process improvement
• Create reusable components
• Merge and integrate as often as possible
• Structure for distributed development

The proper SCM system, implemented well and thoroughly embraced by your development teams, can make the difference between having a wildly successful product or an error-prone disaster that sucks up time, money, and resources in ever-increasing amounts.

Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

1. Denial: It’s never going to work (in a timely manner).
2. Anger: Why do I have to do the merge?
3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.

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 Matthew Laudato

When I read the following blog, Developing in branches, releasing from trunk about a software configuration management development process that was constrained and tortured by branches, I had an ‘aha’ moment. Actually, I had three moments. They went something like this:

1. Branches are obsolete, so why does anyone still use them?

2. People use them because they are unaware of the alternatives – specifically streams.

3. I must act quickly to save my coding comrades from any further branch related pain.

If there is a cyberspace equivalent of shouting from the rooftops, then this blog post is it. My goal is to help the author to simplify his development process, and to free him and his team from the time-wasting, error-prone, outdated branch-induced hysteria that is clearly evident in his post. OK, so maybe that last sentence was a little hysterical, but you get the point.

In the post (which I encourage you to read first), the author outlines a branch-centric process that goes something like this:

- create issues in JIRA for feature (defect, etc) work

- create a Subversion branch for each JIRA issue, named by the JIRA issue ID (eg, SUP-3452). Developers write code on these feature branches.

- create a JIRA release (for example, R4.2) and target the issues created above to this release

- create a Subversion branch (off of the ‘trunk’) with the same name ‘R4.2′.

- Write a bunch of scripts that look at the JIRA release, find all the issues for that release, look at Subversion for the branches that are named for said issues, merge these branches to the release (R4.2) branch.

- Do some testing on the R4.2 branch

- Tag the release R4.2 branch

- Release software

- Merge the R4.2 tag back into the trunk

Rinse, repeat for the next release.

For some reason, I’m reminded at this point of a character in Tom Robbins’ “Even Cowgirls Get the Blues”. The character had a little business card that he would hand to people. One one side it read, ‘I believe in everything, nothing is sacred’. On the other side it read, ‘I believe in nothing, everything is sacred’. When I think about the author’s process, one side of my brain says ‘there is nothing wrong with this process’, and almost immediately, the other side screams ‘there is everything wrong with this process’. The truth is somewhere in the middle, and it all comes down to branches.

The problem with this process is that branches get in the way. The idea of isolating features in your SCM tool is a good one. Although I don’t personally agree with the idea of dedicating an SCM construct per-feature, there are plenty of people who do. (See Stream-per-task paradigm, for example by Dave Thomas). But that’s not the point. Whether you put one feature or ten in it, a branch constrains your ability to work efficiently. Once you create a branch, it loses all contact with the outside world, most importantly, with its own history and its relationship to other branches. The author even admits jokingly that a ‘release manager’ will likely be needed to handle the merges. Ya think?

Here’s an alternative process that uses AccuRev streams:

- Create issues in JIRA as before for the desired features and fixes and assign to developers. Use AccuBridge for JIRA to sync those issues into AccuRev

- Create a stream for R4.2

- Create (or reparent existing) developer workspaces off of this stream.

- When developers finish coding, they use ‘promote to issue’ to push the code to the R4.2 stream (automatically creating a change package that associates the code changes with the JIRA issue, and automatically updating the JIRA issue with an annotation about said code changes).

At this point, the R4.2 stream contains everything that you want to release. If you decide to back out a feature, you can use the revert by change package feature to remove it from the stream. The code changes are always available in the developer’s workspace if you need to revive them in the future. Once it is time to release, you can create a snapshot of the R4.2 stream to preserve it, and then you can go about working on the next release. If R4.2 and R5.0 (The Next Big Release) are happening in parallel, you could create an R5.0 stream as a child of R4.2, so that the R5.0 stream automatically inherits all of the R4.2 changes.

The advantages are many:

- Fewer and simpler merges

- Right-sized feature isolation and management

- Inherent parallelism through code inheritence

- Fewer process steps

- Built-in automation and thus fewer opportunities for manual errors.

I could go on, but I hear the footsteps in the hallway. There are people out there who don’t want you to know about streams. “We’ve always used branches,” they’ll say. “We’re too smart to use some vendor’s solution,” others will say. I say, don’t listen to them. Fight the power. Walk right up to them and say “Why branch when you can stream?” And then go ahead and watch your team spend less time fighting with branches and merges, and more time writing features and fixes for your customers.

One of the most common and problematic challenges that exists in today’s software development environments is how best to support a Globally Distributed Development organization. In ye olden days, you had the entire team co-located in the proverbial cube farm under a single monolithic roof. If Brad wanted you to review the code he just wrote, he would literally turn around in his chair, ask you to come in and look over his shoulder.

Times have definitely changed. Now, your team might be headquartered in Boston, separate R&D sites in California and London, with some specialized groups in Bangalore and Shanghai. But that’s not necessarily the hard part. Where it gets complicated is when all these developers are trying to work on the same source code at the same time. Mastership issues questions, latency, mismatched process across sites; communication problems, lack of project visibility; these things all lead to significant decrease in productivity, not to mention the chaos for those trying to manage the effort.

Enter AccuRev. Uniquely architected to support remote and geographically distributed development (GDD), there are several key built-in capabilities that make the challenges of the past disappear. Consider the following graphic:

• AccuRev’s Stream Browser presents a dynamic visual representation of the software development process that is both fundamentally tied to the source code itself as well as being flexible and enforceable. At a single glance, *anyone* working on the project anywhere knows exactly what the process in place is. (See example AccuRev annotated screen shot here from the Alaska Airlines success story).
• Geography has zero impact on your position in the process; a developer in the UK can happily use a Workspace on the same parent stream as a developer in the United States. For low bandwidth locations, AccuReplica can provide LAN-quality access without introducing the traditional mastership and latency problems of other replication solutions.
• The private nature of the Workspace means that these remote developers can “share” code while still determining when to deliver their changes publicly.

Here’s the scenario: Developer ibergman works out of London, while jtalbott works in Boston. However, they are both part of a virtual team working on ComponentC. With AccuRev, the normal boundaries and limitations of time and space – not to mention being constrained by an inadequate SCM tool – no longer apply. Okay, I took some verbal liberties with the “time and space” bit, but it’s actually not too far from the truth.

In London at noon, ibergman wraps up a section of code she’s been working on and performs a Keep, which in AccuRev is a private check-in. The change is versioned yet stays within the confines of the Workspace, not yet ready for public consumption. But ibergman wants some validation, and asks jtalbott to review her code. Using instant messaging (IM), she pings him and catches him as he’s having his first sip of coffee, probably a colombian supremo. In other tools, how would someone review a private change that was just committed on the other side of the ocean? Would they even have private commits in the first place? In AccuRev, the moment ibergman performed that Keep in London, a visual identifier is available to anyone viewing the StreamBrowser, such as to jtalbott in Boston. So jtalbott clicks on the icon, and now has immediate access to operations like View, to see the file, and Diff, to compare against any previous revision of this file:

Did I mention that jtalbott’s access to these operations is instantaneous, as soon as ibergman performs the Keep? He can even take her version and send it into his own workspace if he finds it interesting enough to want to do additional development on.

So the previously mentioned problems of mastership, latency, visibility, communication, and most importantly Process, have all gone away. No more waiting on a 24-hour turnaround to get that Shanghai code copied into the branch. No more working in the dark not knowing exactly where your piece of code fits into the puzzle. Each team can regain the responsibility of merging in their efforts into common integration points, using a well-defined process implemented with streams.

It’s a remarkably simple and elegant solution to a complex and challenging problem. Of course, it’s still not going to solve the amusing problem of both the London and Boston developers feeling like they are superior to each other, but at least now they can actually review each other’s code real-time to help figure that one out

James from AccuRev: You want answers?

Tom the CC User: I think I’m entitled to them.

James from AccuRev: You want answers?!

Tom the CC User: I want the truth.

James from AccuRev: You can’t handle the truth! Tom, we live in a world that has complex software. And that software is going to be coded by men with computers. Who’s gonna do it? You? You, Tom with your CC? We at AccuRev have a greater responsibility than you can possibly fathom. You weep for CVS and you curse SVN. You have that luxury. You have the luxury of not knowing what we know: That the AccuRev SCM tool, while special and unique, probably saved jobs. And AccuRev’s existence, while grotesque and incomprehensible to you, saves jobs. You don’t want the truth. Because deep down, in places you don’t talk about at tradeshows, you want us for your source code. You need us for your source code. AccuRev uses words like Keep, Promote, Update…we use these words as the backbone to a life spent managing source code. You use ‘em as a punchline. We have neither the time nor the inclination to explain ourselves to a man who drinks coffee and programs under the blanket of the code management we provide, then questions the manner in which we provide it. We’d prefer you just send us a P.O. and went on your way. Otherwise, I suggest you pick up an IDE and start programming. Either way, I don’t give a damn what you think you’re entitled to.

James from AccuRev: Did you order something besides AccuRev?

Tom the CC User: I did the job that the IBM bigot made me do.

James from AccuRev: Did you order the CC?

Tom the CC User: You’re damn right I did!!!

James from AccuRev: All you did was weaken a company today, Tom. That’s all you did. You put software projects in danger. Sweet dreams, son.

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!

by Damon Poole

From time to time, people ask, “What is a Stream?” At this point pretty much anybody associated with software development has heard of branches, but streams are a relatively new concept which is similar to, but at a higher level than branches.

Here’s my .02 on streams, coming from the AccuRev point of view. First, I think that at some level the various SCM systems which talk about “streams” are probably all trying to achieve something fairly similar. That is, a “stream of development.”

My initial exposure to “streams” was from hearing folks talk about “streams of development” independent of the SCM system that they were using (which did not have such a concept). The idea was that you had work which was towards a particular purpose, such as new development, maintenance, a team working together on a sub-project, etc. Each of these was a “stream of development.”

I have also heard the terms “codeline,” “development effort,” and “line of development” used in the same context. At the end of the day, the folks which initiate these things (managers, business people, etc) don’t really care how they are implemented, they just want to ask questions like, “How is 4.0 coming along?” and “Are all of the fixes from maintenance in the latest release?” Somebody else then translates that into the appropriate queries, which may be in terms of branches, scripts, streams, or something else.

Prior to AccuRev, I found the need to translate somewhat mystifying. ‘Why should there be any difference between the mental model of “streams” and the implementation model?’

Thus, in AccuRev, the mental model and the implementation model are the same. Streams are the basic building block of the architecture. There are no branches or labels, just streams. There are streams for releases, streams for active development, streams for end users, etc. Each stream except the root stream is defined in terms of a parent stream and inherits everything from the parent (recursively).

So, if you want to do maintenance on the 4.0 release, you would create a new stream based on 4.0 . Through inheritance, it is the same as 4.0. The definition itself is all that is required. The definition is simply “4.0_maint” is everything in “4.0″ plus all of the changes in “4.0_maint.”

Since streams are first class objects, you can act on them directly. You can assign security attributes, lock them, define other streams in terms of them, compare them directly, do queries on them without having to understand how the streams themselves are composed, etc.

For the curious, I’ve written a whitepaper which describes AccuRev’s stream architecture at an even deeper level.

And if you want to go even deeper than that, the basis of AccuRev’s streams is TimeSafe .

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.