Posts Tagged ‘development process’

Three Absolute Requirements for Successful Offshore Application Development, Part 3

November 2nd, 2007 by lorne cooper

 

Requirement #3: Match the Project to the Team

You can put lipstick on a pig but it doesn’t do much good. It’s not much to look at, and it annoys the pig. You can assign any old set of tasks to the offshore team, but if they CAN’T succeed at the project, or DON’T CARE about succeeding at the project, you won’t get much value and you’ll have ended up annoying the team.

Agile methodologies have taught us all the benefits of keeping the customer tied into the development process. We know the offshore team will have less of a context for managing changes and usually will average less years of experience than the corporate team.

That doesn’t mean you can try to do the “thinking” for them. There are as many smart people in Moscow and Bangalore as there are in Silicon Valley, just fewer Starbucks.

There are two common failure modes in defining projects for the offshore team:

  1. Asking a remote team to solve a complex problem the customer might not understand; or
  2. Asking the remote team to grind through endless bug fixes to a stable product line.

In the first, it’s easy to see that the customer isn’t getting any happier with each release. In the second, the failure will be the Dutch Elm Disease of application development: developer turnover.

Developer turnover comes from multiple sources, many of which you don’t control. Given the heavy cost of recruiting and training new hires, it pays to stay on top of the factors you do influence. Everybody wants to be successful, and will stay on a successful project longer than on an unsuccessful one. So pick the project wisely.

Great projects for remote teams are ones that have very well defined deliverables but ambitious long-term goals. Projects like cloning capabilities of one system to another, changing platforms or improving performance of an app, all benefit from clarity of definition and sufficient technical challenge to keep the remote team productive and engaged.

Epilog

In my humble experience, meeting these three requirements eliminates the additional risk created by an offshore development group, and reduces the problem to the same set of risks as an onshore development group. Not that onshore development is easy.

Are three requirements really all it takes? Yes, because all three are meta-requirements that cover the most important challenges of offshoring. In fact, a superstar remote team lead (Requirement #1) can be enough in itself to deliver success. Superstars are so hard to find we can’t count on finding them. That’s why you need to maximize your success rate by meeting requirements 2 and 3 as well.

Bonne Chance, Bueno Suerte, Удачи, and Good luck!

AccuRev TimeSafe makes retrieving code from "anywhen" easy

October 24th, 2007 by jtalbott

One of the problems frequently faced in traditional branch-and-label version control systems is how to retrieve a particular configuration of code from the past if it wasn’t tagged or labeled at the time. You forgot to label the release-candidate-6 branch from last month before building it, and now you have no way to accurately pull the correct files.

AccuRev, through a combination of its TimeSafe architecture and the power of its streams, makes this easy. Say you have a development process where code follows a promotion model from individual contributors to an Integration area, to a QA area, to Production. The release candidates are based on the QA stream. The QA team built and released RC5 on Friday, June 7th at 11:00 pm, but unfortunately neglected to snapshot it. In the following weeks, additional changes were promoted to the QA stream.

To get guaranteed access to the code configuration as it existed for RC5, you could do the following:
* create a stream off of QA and assign it a time basis of June 7th, 11:00 pm
* run “accurev pop” to retrieve the contents to disk

anywhen stream AccuRev TimeSafe makes retrieving code from "anywhen" easy

It’s as easy as that! Furthermore, if you want to automate this process, how about creating a stream for all your source pulls, call it something like <depot>_source_pull (or equivalent, doesn’t really matter). Then, whenever you need source files, use the “accurev chstream” command to first move it to whatever parent stream you want the files from and second to change the time-basis on it to the correct time or transaction. Lastly, you pop from that time-basis stream to place the files in whatever location you want:

“accurev chstream -s <depot>_source_pull -b <depot>_target_stream”
“accurev chstream -s <depot>_source_pull -t 356″
“accurev pop -R -O -v <depot>_source_pull -L c:\build_dir .”

There are other ways to skin this cat in AccuRev, as there usually are, but this is a quick way to get guaranteed results.