Planet SCM

Good watch...

Last year I presented on Team Based Development at TechEd - I found a link to the recorded presentation today.  You will be prompted to download the video.

Here is a great video that provides some insight into the impact of Scrum at Google.

Check out this article by Nigel Cheshire - quoting both Sam Guckenheimer and Joel Spolsky about whether or not measuring developer performance is a good thing or not.  Both Sam and Joel say to stay clear away from doing this.  Where do you stand?  Personally, I say that we need to "professionalize" our industry a bit more before we can be effective at doing this.  Tools like Team System make instrumentation of developers a lot easier, however I don't think we can clearly understand the inter-relationship of metrics on individual developers well enough yet.  Nigel compares Sales people to Developers in this respect - asking why we can ask Sales people to hit metrics and not ask Developers to do the same.

 I think we'll be there one day - however, I think the real way to measure developers is how they interact as a team - and from that measure the team by the results of that team - in this case the software they develop.  Our industry needs to has a lot more maturing to do before we should focus on individual developer metrics, as there are likely hundreds of other aspects organizations can improve upon first that have greater value. 

http://au.sys-con.com/read/325131.htm

Just watched an interview with David Anderson, formerly of Microsoft. 

In addition, you can go to his blog where you can read about something he calls Dark Matter.  I find it funny, since I’ve been talking about something similar for years - something I call black holes.  In my definition, every project has at least one black hole – which is something you can’t see into.  In a project, a black hole could be a reflection of quality or certainty.  Ask your team “how many bugs will you have in this project?” and you will be left with blank looks or a whole lot of “pffts’s” – that’s a black hole.  Every defect found results in work.  You can’t estimate the number of bugs on a project or the effort to fix – therefore, every project has a high degree of uncertainty determined by certainty and quality.  Black holes

You can’t get rid of black holes, but you can try to shrink them by scattering your project with things you can estimate or have higher certainty.  For example, you can estimate how long it takes to write a unit test on an object with fairly good certainty.  We know that the more unit tests we write, the less the possibility we let bugs we introduce as a result of change into builds – because we can catch them early.  We know that if we catch bugs early, they take less time and effort to resolve – this reduces the black hole.

Technology is riddled with uncertainty, mostly because of the rate of change of the platform and technologies we work with.  I’m not saying that we should NEVER change how we work, but we can invest heavily in internal education and cross pollination of skills to reduce uncertainty.  You should leverage skills throughout or from outside of your organization to help architect, design, and plan versus review – since, by the time you perform code and design reviews, its likely too lake.  Make sure your teams have every resource you can realistically provide to keep everyone educated and up to speed on all new technologies and techniques.

I’m a believer that you should also consider adopting software factories - for all of the reasons I've just mentioned - quality and certainty.  Do you ever debug the code generated from the winforms designer in Visual Studio?  Well, some of you may – but the majority of you just assume it all works.  The winform designer (a mini-code generator) is a much more consistent coder than most humans and it would be foolish to simply write all the code by hand these days.  Use tools that generate code – because these tools will do this more consistently and repetitively than any human can.  If your code generation tool introduces a but – you fix the code generator – and that bug won’t get introduced again.  Now, software factories are much more grand in concept than a winforms designer - but you get the picture..