Monday, May 17, 2010

FloorSweepings: Efficiency and Trust

My friend recently went on this tirade at FloorSweepings: Efficiency and Trust about ceremony and dress code. Though I should probably be chopping it up about ceremony with him, the dress code part ignited some emotions.

I've always thought that people shouldn't judge you based on what you wear. Instead, they should look at the work you perform, and the value that you bring to your team and your organization. Unfortunately, people aren't so rational.

I've been reading Influence by Robert Cialdini. It's chock full of anecdotes, backed up by real research, about why people act the way they do. It's been quite eye-opening. In particular, one area of research deals with how people respond to others "in uniform". His examples include people posing as security guards, priests, and businessmen in pinstripes. In every case, people are able to exert significantly more influence when the look the part. That is to say, "customers" and "suckers" are more likely to believe your message when your clothes match your role.

Back to my friends rant, I don't think that his consulting manager is out to get him four days a week by asking him to dress no jeans, no sneakers, with dress shirt. Nor is it declaring itself "Old Biz" or non-"Agile" by requesting a certain level of dress. This company understands that most people aren't so enlightened as to focus on the work you do and the value, and is playing it safe by dressing "one-level up". Add to it that most consultancies should be called what they are -- staff augmentation firms -- and you can see why consulting managers want to do everything they can to exert any influence possible on an organization.

So, do you prefer your shirts on hangers or boxed?

Tuesday, May 11, 2010

Good enough software

Around 2000-2001, the Pragmatic Programmers introduced me to this term. At the time, I took it to mean doing just enough design to get your feature working. I didn't really take to heart the longer-term trade-offs that lingered around, including technical debt.

Fast-forward to the spring of 2010...I've run across some great articles by Ron Jeffries and Josh Kerievsky addressing this topic, and framing it against product value and productivity.

Take-aways:

  • Extremely poor quality slows us down. Striving for perfection also slows us down. We need to find the sweet-spot somewhere short of perfection, where we are not slowed by neither defects nor perfection.
  • We need to design towards perfection on the more important, more valuable parts of the system. Here, value is what the customer perceives, or areas of code where we spend much of our time and cannot afford slow development.
  • We should back away from perfection, and spend less time designing the areas of the software that are not as critical.
  • These decisions should be based on the value of the features we are developing, and on how much the design gets in the way of future work.

There is alot of subtlety here, and getting good at this comes with mistakes and experience.