Orcmid's Lair status 


Awesome Breakthrough: Lousy Estimates

I just had a wonderful breakthrough.  Here’s how it unfolded.

{tags: }

  1. Yesterday, on Lifehacker, I was fascinated by the question topic, “What do you wish you learned in college?  That led me to examine my own collegiate experience, spread across the 48-year period 1957 through 2005.  I laid it out in three consecutive comments, starting with this one.  The first comment became a lament about where I find myself falling short over and over again.  I don’t know that this is something to learn in college, but I have this consistent failing that I would love to conquer.  I’ve been beating myself up over it lately.
  2. Chris Sells’ great article, Boogers and My Writing Process, unlocked a problem for me.  The article’s start-up is a little distracting (what is this booger humor anyhow?)  But it is a great way to step into a youngster’s world (always start with what they know and interests them) to provide a great worked example of writing process.  It is a delightful simple illustration of “brainstorming + outlining + summary + details = completed essay.” 
    Along with that, I noticed an “overrun” topic left after the summary in Chris’s outlining.  I don’t know what he means by that.  I know what it opened up for me. 
    I have some documents and specifications in my current project.  I’ve resisted revising them, even though I have made breaking changes in the interface contracts and I need to update the Guide and Usage Scenarios document to agree with what the Java interface class declarations and their comments say the behavior is (and what the names of the methods now are).
    Overrun, for me is what I had pulled into the back of my M.Sc thesis draft.  It was a place to collect all of the topics and sections and pulled out paragraphs that I did not know what to do with but that I didn’t want to lose just yet, even if they ultimately moved to some other document and project or would be ultimately discarded. 
    I have been resisting updating my document drafts because there are parts in the introductory sections that don’t belong in those documents, yet I don’t want to loose them. I didn’t see that until I read Chris’s blog post.  I’ll move my little treasures into an overrun section in the back (it is still a draft, after all), and get on with letting people know about the important changes.
  3. Later, I ran up a great debt to Joel Spolsky for the insight I found in yesterday’s review of Dreaming in Code.  Although I first saw Ayende Rahien’s comment on the problem of meetings, I didn’t feel the big KO punch until I opened the full article in my unread items folder late last night. 
    Joel spends some time setting up a basis for an illusion of human perception with regard to what we think we know about something we’ve conceived of.  The kicker: 
    “One of the unfortunate side effects is that your mind gets into a bad habit of overestimating how clearly it understands things.  It always thinks it has The Big Picture even when it doesn’t.
    “This is a particularly dangerous trap when it comes to software development.  You get some big picture idea in your head for what you want to do, and it all seems so crystal clear that it doesn’t even seem like you need to design anything.  You can just dive in and start implementing your vision.”

Aha! says I.  This is great news.  I get it.  The insight: I do suffer under that illusion. I was born with it.  I am a ready-made architecture astronaut.  I design programming languages in the sky too.   The trick, knowing that, is how to be effective anyhow.  How do I do that?  That has been my struggle.  That’s when it all unfolded before me.
Wait!  I do specification and design up front.  In my current project, as a way of avoiding over-specification and and never building it, I chose to specify interfaces up front and then undertake iterative/evolutionary development.  There is always running code and the features are just functioning more fully and better each cycle.  In the first usable trials, most functions fail softly to a null behavior that is actually a potential legitimate outcome.  Later ones provide increasingly more useful results. 
I needed to do that because I had a sketch in my head and I needed the experience to know how to deliver on portions I had never done before (starting with Java JNI as a big question mark, with other areas of my ignorance, such as GUI programming, revealed as I plowed further into the project). 

I’ve also been doing rolling-wave project management (of myself as a solo developer, always a risky arrangement).  With rolling-wave, each new development stage has its broad work items and deliverables refined and components designed until there are small-enough units of work that are well-defined and executable.  Lately, I have been getting down to work items that take hours, not days, and I perform on 2 or 3 per day.  But the key feature is that it is the work right in front of me that gets the design and development attention.  The next stages are still merely conceptual.  I do have my eye on the end-point, and I haven’t gone down any serious blind alleys or crashed into a show-stopper so far.  I also have a long list of pent-up refactoring and improvement urges that I have forestalled in favor of expediting the defined progression and not destabilizing what is already working.
This is a lousy approach for reliable estimation.  I have blown my predicted milestone dates thrice over.  I now see that I didn’t undertake the project in a way where I could have estimated it properly even if I’d known how.  I had neither the required data nor the experience.  The rolling wave of one chunk then another has been reliable for progress and convergence, but not for any kind of manageable up-front estimation.  That’s not a methodology for reliable estimation.  This is an adaptive project methodology, not a predictive one.  The estimate I provided was merely plausible.  It was worthless.  (It’s a good but not great thing that I bid way cheap and that I only receive progress payments on concrete deliveries.)

I was feeling incompetent.  Not so.  I’m just a lousy estimator.   Well, wait.  Good estimation depends on historical experience, right?  I have that.  I have that in spades.  There are three spiral notebooks full of records as I considered and worked through all aspects of the current project.  Those notes include recording the wall-clock time as I began and ended periods of effort.  I also have all of the code, including all of the tests, in all of their stages, under version control (so I can do metrics on the code and on the changes of the code base and the tests too).   The same is true for all other project artifacts, including those documents I have avoided updating.  I have more recording and journaling of this project than any I have ever undertaken.  I can slice and dice this and use it to calibrate my next project, which I intend to be similar enough to this one that I can transfer a good chunk of the experience.

  1. One more thing.   It comes back to the different ways that we learn different things, and how so many of them don’t shoe-horn into classrooms.   Among Peter Denning’s terrific “The Profession of IT” articles in Communications of the ACM, his September 2002 Career Redux article regularly claims my attention (PDF download).  Denning provides a powerful analysis of how getting to the next rung on the ladder of competence doesn’t involved the same skills and experience that got us from the last rung to where we are now (as Wittgenstein and Kirkegaard affirm in their own realms of discourse).   There is also the matter of how much knowledge is embodied rather than learnedtaught as we progress.
    I was referring to this yesterday in challenging Vicki to accept that she is a master potter, not just a potter.
    It is suddenly no surprise that what I have available to myself in being a great student is not the same as what it takes to provide professional results (including an M.Sc dissertation on plan and schedule), and which I had lamented on LifeHacker earlier in the day.
    So what is different now that has me achieve a different level of competence?  In part, there is something about the conversations in the blogosphere that has drawn me into a loosely-knit collaborative style.   It’s not mentoring and it’s not apprenticeship in a direct way, yet I sense that there is more embodiment, perhaps through introspection as well as practice.
    I think I need to create a situation with more collaborative activity and more coordinated effort in some future projects.

Sometimes, the coin just doesn’t want to drop down that skinny slot.  On my next project, I will apply what I’ve learned to practicing estimation and continuing that practice until I establish reliability at it (and recognizing when I can’t provide that).  I’ll also look to participating more directly with others in additional undertakings.
There’s work to do here, and opportunity aplenty.  I feel lighter already.  What a wonderful birthday present for myself.  Thursday is a big one for me, although I’m not sure why 68 is such a significant number in my mind.  Maybe because I’ve been feeling it lately and wondering if I was running out of gas, getting tired of life, needing to give up on computing and software development after 49 years, all of that.  No more.  It’s high time that I stopped being the perpetual rookie.

I invented the "overrun" section in my own writing as a place to keep all the stuff I'd worked hard on, so didn't want to delete, but it just didn't belong in my current revision of the doc. By having a section (or sometimes a whole separate doc) where I could drop that stuff, I could remove it w/o guilt, which improved my writing. Also, sometimes I come back to that material, e.g. whenever I do an new edition of a book, I look at the last edition's overrun to see if there's anything I should be covering this time around.
Post a Comment
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 10-04-05 12:43 $
$$Revision: 2 $