Blogging about Reading and comments about Software Management

Ok. So I have a blog, that I never post to. Here's a post, about what I'm reading. I picked up Why Does Software Cost So Much? from the library the other day, and I was just reading it, and thought, "I would like to write some of my thoughts down". So here they are.

1. I am surpised this book "Why does software cost so much?" was written in 1993; it is extremely relevant today. I enjoy his reference to Mike Hammer, from BPR fame (page 42).

2. Isn't it true that the obvious non-trivial things are most often the most informative.

True Meaniful Productive = Total Dollar Benefit Delivered By Product / Total Dollar Cost of Building Product

(page 43)

This seems to be related to what Joel S. calls Evidence Based Scheduling.... Tom Demarco from the book stated, "...we need to learn that failure to deliver within our estimate is an estimating failure, not a production failure." This is a good point for a distraction. TRAC already has the "Time Management" pieces built in, estimate time to deliver a ticket, and estimated time remaining. These can be populated on check-in comments using the (spent 1h, rem .5h) syntax (I think there is TRAC module that has to be enabled for the integration to work with Time Management). That being the case, I think it would be great to see TRAC working with the Evidence Based Scheduling concepts, where developers could learn there own "developer velocity", which is the estimated time divided by the actual time. It would be great to see changes to TRAC that would produce a developer velocity. It could be open sourced, and maybe hook into a centralized server, so developer velocities across many projects could be collected--that would be very cool! Maybe link it to odesk and rentacoder profiles; but as soon as you do that--then people would likely begin gaming the system--to get there velocities to show something other than reality... like a perfect "1". I suppose no one would want it to be greater than "1", because then you are saying you always estimate too high, and the closer to "0", you always estimate too low. I also wonder if there is a way to calculate the multiple points of time remaining on tickets (a TRAC concept for defect/issues/enhancements/etc.) into the developer estimating accuracy (I'm sure there is).

Here is an interesting post... I just read.... goes over various Metrics... and uses the term devloper velocity, but doesn't seem to define it.
http://geekswithblogs.net/Optikal/archive/2007/02/21/106916.aspx

I definitely think the software industry is getting closer to figuring this stuff out, and the tools are being put in place to assist in accomplishing the goal of increased management/understanding and ultimately productivity of the SDLC or ALM, whatever you want to call it.

It is kinda ironic that I was at a XAML/SilverLight class last week for a few days, and as I was learning about SilverLight/XAML, I felt my productivity go down to zero. Especially, as I was trying to wrap my head around the WPF concepts that have made there way into XAML, where they have very similar meanings to internet and ASP.NET concepts, but different terms are used--I felt my mental model and maybe even my muscle memory wanting to explode.

Oh, yeah, here is what I am currently reading... we'll see how far I get in them.