If you’ve used reddit, you already know how cool it is. If not, you should check it out. reddit allows people to submit any web page as something worth checking out. You can also vote up or vote down things you like or dislike. Now there’s a reddit for AccuRev!
Archive for March, 2008
Surf For AccuRev Using reddit.com!
March 29th, 2008 by damonpoole
Adrift in a Sea of Conflicting Priorities and Assignments? Here's a Life Preserver!
March 28th, 2008 by damonpooleDo you ever feel like things are out of control on your project, that you are adrift in a sea of conflicting priorities and requests? Do you suddenly find out at the last minute that you are the bottleneck and everybody is breathing down your neck asking you what is taking you so long to create the moveStuff() method but you had no idea that anybody even cared about moveStuff() or that you owned it? Do you ever find yourself in the exact opposite position, wondering why Sue and Bob didn’t get their stuff done that you need and then your boss walks by while you are surfing the net waiting for Sue and Bob? And who is Bob anyway?
The solution is simple! All you need to do is get everybody to move to Project. Well, if you have somebody you can spare full-time to keep Project up to date of course. Oh and I almost forgot, you’ll need to start using a requirements tool. But that’s it really, other than integrating them all together over the weekend and of course that’s assuming you’ve already gotten a CRM tool for workflow.
There is a simpler solution. It isn’t perfect, and it doesn’t solve all problems, but it can definitely provide the following benefits:
- reduce the chaos
- increase your vision into where you are and what’s going on
- reduce the number of status and/or project management meetings
- reduce the need to provide the same information over and over again
- simplify collaboration both locally and for distributed teams
- provide a more Agile workflow
The answer is to reduce the amount of rework that you are already doing. Right now you are probably storing defects in a defect tracking system, enhancements (aka RFEs, requirements, etc) in a requirements management tool (usually Excel or Word but sometimes an actual RM tool), and if you are using a project management tool it is probably MS-Project. All three of these product areas evolved to provide different aspects of project management for different groups of people and as a result they have lots of overlap. Considering how hard it is to coordinate three different systems, why not consider standardizing on one system for most of the work? The only question is, which system?
If we are going to try to do most of our project management work in a single tool, we should first decide what the interesting activities are. I believe they are: recording enhancement requests and defects as they are gathered by marketing or reported by users, load balancing, estimated completion calculation, critical path determination, work assignment, workflow, and reporting.
First let’s consider how well suited Project is for doing most or all of these tasks. Project is good at taking a small static collection of large tasks and doing load balancing, estimated completion, and critical path determination. Thus, it is mostly used for the very narrow task of project management of enhancements.
Next let’s consider requirements management. For whatever reason, most people use Excel or Word as their requirements management tool instead of a “real” requirements management tool. Excel and Word are just not appropriate for project management.
Lastly, there is defect tracking. A defect tracking system covers the assignment, tracking, workflow and reporting of defects. There is usually a higher volume of defects than enhancements, and they are usually smaller in scope and have a more complicated and often more time critical workflow. If it works well for defects, it should work equally well for enhancements.
Based on this analysis, it makes sense to extend the project management that you are already doing with a defect tracking system to include enhancements. A generic name for something that is either a requirement, enhancement, or defect is “work item.” By using work items to track all work, it is easy to see where you are and what remains to be done. Now you can use a similar workflow for enhancements as you do for defects, for instance from newly entered, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. You can easily run a query to see which work items have their code written but do not yet have any tests. Similarly, you can see which work items are done from a coding perspective and have tests but have not yet been verified as done by QA. This will give you a much more complete view of your overall project status and progress.
Whatever you are currently using for defect tracking it will be straightforward to start getting the benefits of managing defects and enhancements together. Just add a field that indicates if a work item is a defect or an enhancement. You may need to make a few more changes to accommodate a slightly different workflow for enhancements than you have for defects, but I think you’ll find it is worth the effort. For one example of how this can work, you can take a look at how AccuRev does it using AccuWorkflow.
Pattern for Stable Development
March 27th, 2008 by adminIt’s Wednesday morning. 9:23am. With coffee in hand you execute a simple version control command: update.
Hey, blame yourself! You should have known better than to blindly accept all changes from every developer who quickly committed code the night before just minutes before darting out. What did you expect to happen? For teams that work on a single branch, broken updates can be quite common. For those that branch for isolation, their updates are comparably more stable but they are required to (painfully) merge more often to stay in sync.
Ok, lets get real. On some mornings, performing an update can yield minimal-hassle results and we all know that staying up-to-date is always a good thing. But often when you least expect it, often when it matters the most, often when time is critical, the simple execution of an update results in sheer and utter frustration. You know. The code doesn’t even compile. Forget passing unit tests. Forget working at runtime (these are the worst to deal with!). The last thing you want to do is spend the entire morning scrubbing logs, reverting out changes (complete WOT!), or walking the halls finding the culprit only to see that everyone you need is in a meeting in some cleverly named conference room.
But you had to! You know you need to update frequently in order to stay current with your peers. But back in your mind, you’re worried that their changes are going to negatively affect your changes. Nevertheless, all you can do is…. update. But what if you had control over the situation? In this pattern for stable development, I’ll describe an approach in AccuRev that provides incremental updates based on predefined good builds and minimizes merging (due to implicit merge tracking).
The Pattern. AccuRev’s stream-based architecture with built-in inheritance and time-safe snapshots can entirely eliminate the traditional problems of shared development (with branches). The first thing to acknowledge is that you need to work off of a stable codeline. period. 
I know, I know. Some of you reading this think you need to always be working against bleeding edge in order to move as quickly as possible. Fine. Then you accept the top-half of this blog post and are willing to deal with the pain/time/sleep/sanity lost in the ether. For the rest of us who don’t live at the office, we need to work off of a stable codeline. With AccuRev, this means working from a snapshot (or time-based stream). In a previous blog, I wrote about a pattern for continuous integration (CI) where snapshots are created for each frequent “good build.” Extending this CI pattern, lets use each good build snapshot as the baseline for active development. The idea is simple: Reparent your workspace or project stream to subsequent “good build” snapshots and then update. The update will bring down (delta!) changes to your workspace since the last good build. In this way, you knowingly accept changes that are guaranteed to have passed some level of test criteria. In the meanwhile, changes in the mainline Integration stream can churn-n-burn with various levels of volatility without affecting your active development environments — you’re saved by the snapshot! After days or weeks of hopping build snapshots, when it’s time to deliver your changes to the rest of the world, simply reparent to mainline Integration, perform any last minute merges, test, then promote! For an extra level of stability, consider only working off of certified builds – snapshots that have passed rigorous tests.
Wait. Who does the reparenting? Good question. I say let the developers or team leads manage where and when project streams get promoted. Reparenting is easy and reversible! On the other hand, maybe your CM or Release Engineer takes on responsibility for managing builds and reparenting projects on particular days or by request. You can use stream locks to easily control who can reparent, by user or group!
What about setting a time rule on a stream? As you know, snapshots represent configurations at specific points in time. You may also know that you can optionally set a time rule on a dynamic stream to control (i.e. throttle) when changes are inherited from the parent streams. 
[StreamBrowser: Rclick Stream --> Change Stream --> set time]. Guess what! The effect of reparenting to snapshots can equally be obtained by simply setting a time rule on your parent stream! This works best if you have a stream-per-task paradigm so the time rule only affects your (team’s) active development. The idea is simple – anytime you want more changes, simply (re)set the time forward say an hour or day or week and any newer changes will be available to downstream streams and workspaces. Personally, I like setting time rules only for temporary use cases such as for quick testing or to wait a day for new changes. If I’m doing development that will take weeks to complete, I’d rather reparent to a snapshot because it lets me physically ‘see’ where I’m working. But both options result in the same effect — controlled updates.
This pattern is ideal for letting teams stay up-to-date by reparenting to stable baselines and only updating changes that are known to have passed some level of testing. Ultimately, with clean(er) updates, the results should be increased productivity, increased quality, and happier developers! Happy developers == good.
/happy coding/ – dave