By implementing solid practices such as coding standards, continuous integration, unit testing, pair programming, and SCM branches, you can reap the rewards of collective code ownership. When it comes to actually putting a product out to a customer that lies outside the boundary of your company (e.g. product development), I’d favor a more-contractual form of what Martin Fowler calls “Weak Code Ownership”: concurrent-collective code ownership (3CO)!
An example:
Your company makes a software package called GoodStuff. Version 2 is the current release of GoodStuff. The upcoming major release, version 3, promises to take GoodStuff to a whole new level with a swell new look and feel, a re-written reporting tool, and more. Your dilemma: (a) maintain version 2 while (b) marching forward to version 3. Solve it by running two teams optimized for each competing goal:
Team Alpha
Mantra: Keep the customer satisfied.
- Work on the “2″ branch off the mainline.
- Fix defects and make critical updates to version 2 of GoodStuff.
- Release patches.
- On release, create a branch off of “2″ (snapshot, frozen) called “2.n” where n is the top sub-branch of “2″+.1.
- On release, merge and integrate it with the mainline branch.
- Continue to work on the 2 branch until 3 is ready for release.
- TEAM ALPHA IS NOT THE CRISIS MANAGEMENT TEAM. Quality practices should control both patch and major release.
- The sprint should coincide with Bravo’s (7-30 days).
- Alpha is more likely to work with the individual customer (customer contact reporting a bug or expressing an urgent need) than the customer team (a special purpose team put together to represent the customer perspective consisting of select customers, domain experts, internal product management, etc.).
Team Bravo
Mantra: March on the product road map.
- You’re working on the mainline branch.
- On release create a sub-branch (editable) from the mainline called 3.0.
- Close the current maintenance branch (2)
- Help your buddies in Alpha with the hand off 3.0. They have to maintain it. Why not do a deeper technical demo for Alpha during sprint review?
- The sprint should coincide with Alpha’s (7-30 days).
- Bravo is more likely to work with the customer team than individual customers.
Some good backgrounder on branching and concurrent development:
http://www.cmcrossroads.com/bradapp/acme/branching/
http://downloads.seapine.com/pub/papers/SCMBranchingModels.pdf
http://www.beust.com/weblog/archives/000382.html
I tend to agree with the article above: Ruby is incredibly elegant and interesting and Rails is a quite nice framework for making web applications, but I don’t see this taking off in the mainstream development shop.
Where Rails could gain traction and be a great choice is in the small, product-focused team… the kind of team Paul Graham talks about (startup, great hackers, etc.). Ruby has a lot to offer in terms of keeping smart people intellectually challenged and happy with their toolbox. The kind of team/product I’m talking about is perhaps best illustrated by 37signals and their backpack (etc.) product.
As far as an enterprise solution, I don’t really see it. You’re faced with the fact that you may need to scale up and maintain applications forever and ever (I read something somewhere by someone saying “Java is the new Cobol”, maybe the Gilmor Gang, not sure). Sad but true…
A thing I’ve found that’s really nice with Rails is that architecture and style are baked into the environment. The way you name classes, files, database tables, etc. must be consistent (you can change it with a re-config). Programming within constraints is an extremely powerful paradigm… especially when they’re native to the tool (e.g. no individual developer buy-in required). I find that when I’ve got my architect/designer hat on I’m more-or-less trying to introduce the right constraints for development… with Rails they’re already there. This philosophy - I’d think - would let you get to the agile principle of “simple design” much, much quicker.
Also nice is the use of MVC and object-relational-mapping. These patterns/tools remove a lot of difficult decisions from an already tough job. Instead of having to evaluate a host of solutions from different vendors, it’s already in the box.
Anyway, initial impressions… I’ve only been playing with this on off hours for a couple of weeks. I’m sure I’ll have more to say later…
http://staff.southworks.net/blogs/matiaswoloski/…
The ClickOnce module loader would be fantastic. Also MVP with DataBinding is something we’ve struggled over. As we make extensive use of DataBinding, we’ve chosen MVC to get testability… We’d like to get on board with MVP (as that seems to be where the community is headed) but have yet figured out a smart way to use it with DataBinding.
http://www.agileprogrammer.com/dotnetguy/…
Some pics of Microsoft’s Patterns and Practices team’s new digs. I especially like the doors and space that slide and can be written on. The shared private spaces are cool, too; glassed so you can still feel like part of the group while you do a voice conference or break off.
An interview with Clinton Keith about agile methods applied to game development…
http://biz.gamedaily.com/industry/interview/?id=11418
More at http://www.agilegamedevelopment.com/
http://martinfowler.com/articles/continuousIntegration.html
Martin Fowler has posted a re-write of his original article about continuous integration (CI). We’ve just implemented CruiseControl.NET: it is an awesome, awesome thing and essential if you’re an agile team working on a team branch. If you’ve been living in a cave for the last however-long, the link above will set you straight.
In a nutshell, CI is about pain management during integration. The theory is that it’s much more managable to integrate your code at the point of check-in. Mix it with a common coding standard, voluntary story/backlog sign-up, disciplined unit testing, and branch-by-purpose CM strategy for maximum results. If you want the team to own the code, it’s a step in the right direction.
Speaking of Martin Fowler, I was catching up on my ARCast backlog (podcast) this weekend… “The Evolution of Architecture with Martin Fowler”. Good stuff. I love the analogy about using unit tests at the consumer level to specify a contract at the provider level. Recommended.
