Rose Parade 2008

 
City of St.Louis float

A few years ago, my son went to the Rose Parade as a spectator. This year, he worked as a volunteer float decorator with a community service group from his high school.

They worked on the City of St. Louis float, which won the President’s Trophy for most effective floral use and presentation. Yeah, I know pretty much every float wins some kind of trophy, but the President’s Trophy is one of the good trophies.

To give you the flavor of the thing, here’s the list of “suggestions” given to volunteers by the float-building company:

  1. PLEASE DO NOT BRING RADIOS, WALKMENS, CAMERAS, HANDBAGS OR JEWELRY. BRING YOUR I.D. AND MONEY ONLY. FANNY PACKS WORK GREAT.
  1. WEAR OLD BUT WARM CLOTHING AND STURDY SHOES WITH CLOSED TOE AND HEEL. TIE BACK LONG HAIR.
  1. FIRE LANE MUST BE KEPT OPEN AT ALL TIMES AND THE AREA AROUND THE FLOAT SHOULD BE KEPT CLEAN.
  1. PLEASE DO NOT EXPECT TO USE THE OFFICE PHONES. THERE ARE PAY PHONES LOCATED OUTSIDE THE NORTH DOOR FOR YOUR USE. INCOMING CALLS WIL NOT BE ACCEPTED FOR WORKERS AND NO PAGING WILL BE ALLOWED FROM THE OFFICE. WE WILL TAKE EMERGENCY CALLS ONLY. [Pay phones . . . how quaint! — PE]
  1. NO ONE IS ALLOWED INSIDE THE BUILDING DURING JUDGING. WHEN YOU ARE ASKED TO STEP OUTSIDE PLEASE DO SO PROMPTLY AND REMEMBER TO TAKE OUT ANY PERSONAL ITEMS WITH YOU.
  1. ALL BREAKS ARE TO BE TAKEN OUTSIDE.
  1. VOLUNTEERS ARE HERE TO WORK. THERE WILL BE SOME NOT-SO-GLAMOROUS JOBS THAT NEED TO BE DONE BESIDES DECORATING; IT ALL HAS TO BE DONE.
  1. NO SMOKING IS ALLOWED IN THE BUILDINGS.
  1. NO MORE THAN 3 PEOPLE ARE ALLOWED ON SCAFFOLDING AT A TIME.
  1. DO NOT WEAR FLOWERS AT ANY TIME, EVEN AFTER THE FLOATS HAVE LEFT THE BUILDING.
  1. PLEASE SIGN-IN WITH YOUR CREW CHIEF WHEN YOU ARRIVE AT YOUR FLOAT AND WHEN YOU LEAVE. SIGN-IN SHEETS ARE COLLECTED DAILY.
  1. HAVE FUN!!

Playing the Expert Game

 

If . . .

  • you are able to get important things done
  • you are seen learning things on your own
  • you are seen trying to do things even if you aren’t sure how
  • you share freely the things that you know
  • you don’t hide your ignorance, but also don’t rest on it
  • you honor what other people know
  • you know more often than not how to find out what you don’t know
  • you know how to ask for help
  • you offer to help people on their own terms

Then . . .

  • no one will care whether you succeed by learning or succeed by already knowing
  • no one will care if you mess up occasionally because they assume you learn from it
  • no one will mind if you forget (or don’t know) any given fact or method at any given time
  • you will be treated as if you’re smart and useful, even though everyone knows you have a lot to learn
— Jonathan Bach, “Playing the Expert Game”

Torvalds on Specs

 

A “spec” is close to useless. I have _never_ seen a spec that was both big
enough to be useful _and_ accurate.

And I have seen _lots_ of total crap work that was based on specs. It’s
_the_ single worst way to write software, because it by definition means
that the software was written to match theory, not reality.

So there’s two MAJOR reasons to avoid specs:

– they’re dangerously wrong. Reality is different, and anybody who thinks
specs matter over reality should get out of kernel programming NOW.
When reality and specs clash, the spec has zero meaning. Zilch. Nada.
None.

It’s like real science: if you have a theory that doesn’t match
experiments, it doesn’t matter _how_ much you like that theory. It’s
wrong. You can use it as an approximation, but you MUST keep in mind
that it’s an approximation.

– specs have an inevitably tendency to try to introduce abstractions
levels and wording and documentation policies that make sense for a
written spec. Trying to implement actual code off the spec leads to the
code looking and working like CRAP.

The classic example of this is the OSI network model protocols. Classic
spec-design, which had absolutely _zero_ relevance for the real world.
We still talk about the seven layers model, because it’s a convenient
model for _discussion_, but that has absolutely zero to do with any
real-life software engineering. In other words, it’s a way to _talk_
about things, not to implement them.

And that’s important. Specs are a basis for _talking_about_ things. But
they are _not_ a basis for implementing software.

So please don’t bother talking about specs. Real standards grow up
_despite_ specs, not thanks to them.

Linus

Another Difference Between Dogs and Cats

 

PULLMAN, Wash. — A 6-year-old border collie died in a house fire after waking up his owner out of a deep sleep to warn her of the blaze.

Marilyn Harvey and her son, Brent, rushed out the basement door, but Sandler turned back. Marilyn’s husband, John Harvey, who was in Seattle at the time of the fire, thinks it was because Sandler wanted to save the family’s 17-year-old Australian shepherd, who was still inside the house.

Both dogs died in last Friday’s fire, along with a bird named Kellogg. A cat named Raja escaped unharmed.

Blame Roger Goodell

 

My son’s explanation to his mom on why he can’t turn off Madden 2008 like she asked him to:

I can’t stop in the middle of a game. Roger Goodell has not sent me a notice that we can do that. Unless there’s a weather delay or fans throwing things on the field, which there isn’t, so that can’t happen.

Schedule Crunching

 
Crushing an aluminum can

Many wise people have said that what you put your attention on is what you will create around you. This is true in project management. If you concentrate on meeting the plan and slipping when big problems arise, you will, at best, ship on time, and more likely, you will ship late. . . .

To change your results by changing the way you look at how your team uses time, you must put your attention on how to make tasks take the least time possible. Replace “sticking to the plan” with “looking for ways to decrease the time spent.”

A Christmas Story

 
A Christmas Story

One of the cable stations had a 24-hour A Christmas Story marathon. I’ve never understood the mania some people have about this movie. I mean, it’s a nice movie, but 12 consecutive showings?!

Anyway, my son turned on the 10 p.m. showing last night and we all watched it. My wife fell asleep as she often does watching movies, but the boy enjoyed it.

Merry Christmas to everyone who’s taken the time to read this site over the past year.

Informed Consent

 

I work in the IT department of a health care organization. I’ve noticed before that health care professionals are much better than IT professionals when it comes to setting the expectations of customers.

Last week, I found a handbook around the office called Risk Prevention Skills: Communication and Record Keeping in Clinical Practice. Substitute “customers” for “patients” and “software development” for “medical care” and you can apply the same advice to IT:

Some patients are unreasonable in their expectations of medical care. . . . If a complication does occur, the patient or family with unreasonable expectations will usually conclude that someone must have done something wrong and should be blamed. The only way to correct unreasonable expectations is to accurately explain to the patient, before care is provided, what problems may be encountered.

An accurate description of the range and likelihood of possible outcomes, and the reasons why an unsatisfactory result can occur, may be the most important elements of an informed consent.

50 Years Ago Today

 
Dec. 25, 1957 Los Angeles Times cover

According to the Los Angeles Times:

  • Red Sanders decided to stay on as football coach at UCLA instead of pursuing the football coach/athletic director job at Texas A&M, a job recently vacated by Paul (Bear) Bryant. (Sanders would have a heart attack and die before the start of the 1958 football season anyway.)
  • A father of three killed himself in front of his wife after losing his job on Christmas Eve.
  • Silent-screen star Norma Talmadge died in Las Vegas. The Times gave her age as 60; according to IMDB, she was actually 62.

I Hold in my Hand a 63-Page Requirements Doc

 
Stacks of documents

I hold in my hand a 63-page requirements doc . . .

We spend a lot of time reworking the requirements doc to reflect the reality of the system that we’re actually building. We also spend a lot of time reworking all the docs that derive from the requirements doc — design docs, UI docs, test plans, etc. — to reflect the changes in the requirements doc.

Another way to think of this is that the project is driving the requirements, rather than the requirements driving the project.

So why did we create all these incredibly detailed documents in the first place?

We have a vast collection of well-documented ignorance . . .

Thus spoke The Programmer.

Why There’s No UCLA Store

 
USC Trojans

My son and I stopped by the USC Store at South Coast Plaza today. As you might expect, it was packed with people buying Christmas gifts, Rose Bowl gear and other branded merchandise.

I wonder what a UCLA Store would look like, if there were a UCLA Store. A handful of angry, miserable people milling about, checking out the Las Vegas Bowl runner-up merchandise.

FIGHT ON!

Declaration of Interdependence

 
  • We increase return on investment by making continuous flow of value our focus.
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership.
  • We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • We boost performance through group accountability for results and shared responsibility for team effectiveness.
  • We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Rethinking Success and Failure

 

There’s an old saying that you get what you measure . . .

I recently asked a colleague whether he would prefer to deliver a project somewhat late and overbudget but rich with business benefits or one that is on time and underbudget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.