Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Live Hideout
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Mornings in the Temple of Perpetual Reconsideratio...
 
Friday Cat Photo: Flying Cats
 
Friday Cat Picture: The Return of Shmoo Cat
 
Productivity: This Is Not a Kanban
 
Sympathy Strike: Don’t Gag the Net
 
I Blog, Therefore I Am
 
Amma Vicki and the Monks
 
Let It Rain, Let It Rain …
 
The Fate of Microsoft Outlier Customers
 
Just a Little Bit Facebooked

Raymond Chen: Celebrating the Old in the New

Raymond Chen’s The Old New Thing arrived within the original delivery promise, even though amazon.com had beseeched me to approve a delay. 

{tags: orcmid Raymond Chen Windows software development}

The problem with the book’s timely arrival is I’m in the middle of a crunch and I don’t dare let myself get lost in 21 chapters of amazing material, some I know I’ll be using real soon now.

OK, I peeked at the table of contents, read the preface, and scanned the first couple of articles.  To protect myself, I decided that my wife, Vicki, would enjoy some of the first articles on user-interface design, and I handed it off to her.

Enjoy?  She hooted, howled, stamped her feet, and had tears in her eyes.  She did that all the way to around page 29 where the technical aspects left her behind.

This is probably the most fun I have seen Vicki have over geek pleasures.  She’s a potter.  Computer techie conversations leave her shut out and cranky.  But Raymond has the knack of seeing things from more than one point of view and explaining it at the level where it works best.

You might not display The Old New Thing on your coffee table (but then you might).  Yet there’s more than one reason to possess the book (and the downloads that are also available): A megadose of Raymond Chen might help you learn to look at your software involvement in ways that recognize the ridiculous and honor the tried-and-true.  And have a lot of fun doing it.

I can’t wait to start listening to the interviews he’s giving as part of his duty to promote the book.  Hmm, how about a bookstore event within Raymond’s bicycling range?  If I bring Vicki I wonder if she's let it count as a date night out?  Well, best not suggest it, geek codger.

Awesome Breakthrough: Lousy Estimates

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

{tags: orcmid Lifehacker Chris Sells Joel Spolsky Peter Denning productivity reliability accomplishment}

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.

4. 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.

 
Comments:

 
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.

# posted by  Chris Sells: 26 January, 2007 15:32

 

Post a Comment

Don Ferguson: Near Death Experience

I’m putting the Release Candidate of RssBandit 1.5 through its paces and my “Update All Feeds” brings me Near Death Experience from September 2005.  I am not sure why this particular blog article was refetched by RssBandit.  It might be part of the random time-machine feature of the aggregator or the web site.

{tags: orcmid Don Ferguson IBM Microsoft}

This was long before the January 2007 news that Don Ferguson has moved to Microsoft.  Shortly after that became public, there was some blogosphere griping about how IBM-site blogs of alums tend to be removed.

The masthead over the September 2005 article does point out that “Dr. Ferguson is no longer an employee of IBM,” as does the front page of that blog, with its last entry dated September 22, 2006 (one year later, which I didn’t cotton to on first look).  So far, Don’s blog is still proudly hosted at IBM developerWorks, although he is not listed in the directory of IBM bloggers.  Fair enough.

I subscribed to Don Ferguson’s blog because of his architectural perspective, and I look forward to reading any blog he takes up elsewhere now that IBM developerWorks is no longer a haven for his postings.  His past postings are also a treasure and it honors IBM and Don’s contribution there to have preserved them.

Ferguson was also an ecumenical participant in the Web Services work jointly sponsored by IBM and Microsoft.  It’s not unnatural to see him want to deepen that contribution in some way where he finds Microsoft a suitable home. 

I wonder.  Did he think he needed that Black Belt before signing on at Redmond or to remain on at IBM?