2010 Schedule

Twist of the Wrist II Now on DVD

After the Oregon Desert Tour it was definitly time for a new rear tire. My 2001 Ducati ST2 came to me with an inexpensive tire with OK performance and I wanted something like I had on my 1998 ST2. I also wanted to tackle doing the work myself. After spending hours pouring over the internet I ordered a Diablo Strada Rear Tire.

Here is the bike with the tire removed. No big surprises here except the shop manual doesn't say what size the axle nut is (30mm) and I had to go buy one.

Here you can see the end results next to the old tire - definitely time for a change.

Total time to change the tire was about 3 hours. Mostly because I was being careful and it was about 98F. I expect next time it should take me about an hour. The Dyna Beads seem to work great.

Tom DeMarco, arguably one of the key thinkers when it comes to how we develop software has been reflecting.

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

-- http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

If that doesn't rock you back on your heels, then you need to re-read that paragraph.

Next you need to go read the whole article (2 pages).

As someone who prefers the agile approach I have been pushing the value based approach over the control based one for nearly a decade now. But to see someone like Tom question publicly what he (and we) have been doing for the last 30 years makes me respect Tom even more, and give me hope that as an industry we are heading in the right direction.

Jack Milunksy of Brightspark and AgileBuddy was reacting to a Agile Project Management forum topic on metrics.

Jack was of the opinion that:

the more one spends time tracking metrics, the less time there is for development

While I have some sympathy for this point of view having worked for larger organizations in the past, I have come to realize that you do need some type of metric that is understandable to the rest of the organization. All the other departments in your organization have an overriding single number that describes how they are doing, why not software development?

As I mentioned in my No More Iterations post, throughput is my metric of choice. The cost of collecting this metric is so low that it doesn't matter.

Now I have been asked to provide all sorts of low level metrics in the past not knowing how they were going to be used. I was not inclined to cooperate in those cases since the time required to collect them was never going to be offset by any value coming back to my teams. And this is most likely what Jack is protesting.

I like being proactive and providing a metric I think is useful, rather than waiting for someone who doesn't really understand software development ask me to have my teams track actual effort against estimated effort in units of 0.1 hours (really I have been asked to provide this!).

My talk at the Rose City SPIN last night went very well. We had a small core of dedicated people. Lots of good questions and we could dive into the specifics. Thanks to Rhea for doing a great job organizing the event.

You can find my presentation here.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

• Software by Numbers: Low-Risk, High-Return Development
• Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
• Lean Software Development: An Agile Toolkit (Agile Software Development Series)

Once a year I get to be a guest speaker for Wil Wu's Software Engineering class (MIS 488).

This year's class was great. Lots of good question and a nice level of engagement. You could tell several of them were really thinking about how Scrum is so different than a waterfall style approach.

As promised here are the slides I used.

My talk at PADNUG last night went very well. We had standing room only, with many new faces. Rich and Jason run a great meeting - thanks guys.

There were a few requests to post my "slides" which I have done. Be sure to check out Prezi, the company who is making this cool presentation tool.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

• Book: Software by Numbers: Low-Risk, High-Return Development
• Book: Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
• Book: Lean Software Development: An Agile Toolkit (Agile Software Development Series)
• Site: The Agile Manifesto
• Site: Real Options (podcast)
• Tool: Trichord

Update 3/28 - I forgot to give credit to Karl Scotland for a couple of the diagrams - Sorry Karl!

The situation:

Things have been slow for a year. Next year isn't looking any better. Not that this is a unique experience. The company is generally fine, but with everything on a downward trend we want to stay healthy financially.

My budget is about 98% people. The other 2% was examined closely last year, and while I was able to take out another couple of tenths, it just wasn't going to cut it.

My team doesn't have performance issues to speak of, so there is no easy out.

I've made my decision and acted on it. A challenging part of my job, but maybe the least enjoyable.

For those of you in my position how do you choose what to do?