Archive for June, 2008

Simple reporting tool for AccuRev

June 30th, 2008

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

2 comments »

Posted in AccuRev, Customer Guest Blogs

Tags:

The Seven Deadly Sins of Software Application Development – Part 2 of 2

June 27th, 2008

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 13th 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.

3 comments »

Posted in Agile, Best Practices

Tags:

The Seven Deadly Sins of Software Application Development – Part 1 of 2

June 26th, 2008

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

5 comments »

Posted in Best Practices

Tags:

Build Management with AccuRev and Maven

June 25th, 2008

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.

 

2 comments »

Posted in AccuRev, Tips and Tricks

Tags:

Continuous Integration: Begin Again

June 12th, 2008

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.

1 comment »

Posted in Best Practices

Tags:

Agile Requirements Traceability with AccuRev and Rally

June 11th, 2008

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.

3 comments »

Posted in AccuRev, Agile, News

Tags: