Lack of Motivation for Time Tracking

While waiting in the airport to head back to Seattle from SXSW (SXSWi was awesome BTW) I got to thinking about why it is so hard to get good data on how long it takes to perform tasks.

I ran across the following quote and it got me to thinking:

A typical problem, a few organizations in this industry face is collecting the required and accurate data. The performing teams needs to be oriented towards the importance of collecting data in an accurate manner. The team needs to be appraised on how the data collected is going to benefit their organization in future projects. Once the team is aware of how important the data collected is, how the data is going to be used etc., accurate data collection process will automatically be part of the project execution system.

- Size Based Estimation For Legacy Applications, G. Varghese and V. N. Iyer, 2005

Well now, that’s such wishful thinking I don’t really know where to start. Yup, just tell those developers why it is so important that they fill out the time card and I’m sure they’ll be happy to jump right on it. The key line in this is “how the data collected is going to benefit their organization” (emphasis mine). Few people really give a crap about how something will benefit their organization. They care about how things will benefit them personally. Now if you’re lucky these things are aligned. But in this case they are so not aligned that it would be funny if it weren’t so sad.

If it were that simple there would be no struggle to get folks to fill out timecards or use other time tracking software. They simply would because what’s good for the organization is good for them, right? Rising tide, all boats, blah blah blah. Right.

Let me put it this way. Developers (professional ones anyway) typically demand source code management software. Try telling your developers that you want to get rid of their SCM and use simple file shares because it has less bureaucracy and is faster. Go on, try it. I’ll wait…
.
.
.
Oh, you’re back already? How’d that work for you?

Not so good huh?

Well it’s not friggin’ surprising since the developers can see a clear group benefit as well as a personal benefit to using SCM. They can see an immediate impact upon their own lives and how happy they are from doing this even though for any one action it is clearly harder.

Now time tracking… what’s in it for me? This is one of those “the dog didn’t bark” things. See if it really were true that filling out a time card improved how everything worked then everyone would be doing it. You’d have to fight your developers to pry their time cards from their cold dead fingers. So I’m claiming that the fact that nobody much really likes to fill out time cards suggests that there’s really no personal benefit to doing so.

Until we can make it obviously beneficial to the individual to track their time, they either won’t, or will do it very poorly.

Mmm... Donuts

Amy Hoy has a great little blog called Slash7. I highly recommend it. She recently reposted an old article "The Ape and the Donut Eater" about interaction design and how good humans are at abstract learning about things like ordering donuts at a donut shop, or opening doors (there are a lot of different kinds of doors).

I started to write a short comment but to paraphrase Mark Twain, I didn't have time to write a short comment so I wrote a long one. One that I want to expand upon here...

The gist of her post is that there are all kinds of things that after we have learned to do them seems super simple. But if you're approaching them for the first time they seem confusing or complex. The techniques for dealing with these things are what get us through the day. Those learned techniques allow for a level of interaction with complex technology (like doors or computers , and if you don't believe me about doors just read her article).

This line of thought got me to thinking. For interaction design I wonder if things can't be split into two broad categories. I don't really know how to label them but let's try...

1. Has cultural support desk
2. Has no cultural support desk

Her donut shop example is a good one:

When you think about it, ordering doughnuts is a technique we all know, and if you didn't know, it might be kind of difficult to start. You have to know that doughnuts are generally sold in dozens and half-dozens (otherwise, you pay out the nose), and that when you say "I'd like a dozen doughnuts, please," the person working behind the counter will grab a box, some tissues, and then stand there, waiting for your instructions.

- Amy Hoy, Slash7

In North America there is a culture of how to order at a donut shop. You can watch other people placing their orders and at least attempt to infer what it is you're supposed to be doing. That's a case of there being a culture there to support the new "user".

Suppose that there was no culture of ordering at a donut shop. Then you couldn't even watch the actions of other customers because they don't know what to do either. There's no cultural support desk.

Software, particularly really new software has this problem in spades.

While designing the interface for LiquidPlanner (the product I'm currently working on) we ran into this problem. We needed to show uncertainty in the time it takes to complete a task. Like most problems we could break it down and most of the pieces had parallels that folks would just "get" (i.e. there is cultural support for them). But there wasn't anything out there doing this, so there isn't "some guy down the hall" who knows what the do-dads on the chart mean and can explain it to you when you get confused.

This is the point where I think real interaction designers shine. The good ones out there are worth their weight in proverbial gold because they make the user feel smart with designs that play to your preconceptions rather than fighting against them.

They are also good at dropping little nuggets of information along the way without getting all "RTFM" on you.

Speaking of which... have you noticed that when posting comments on blogs (or forums or...) that folks seldom tell you which markup language to use? Is HTML allowed? Which tags? RedCloth? LefthandedReversePolishPolyMarkDown?

I run into this all the time when commenting. A simple link to a reference and a preview would make me so much more likely to comment since I'd worry less about looking stupid (I still may sound stupid however). Blogger (the site this blog is hosted upon at the time of this writing) is a good example. They give a happy little "these tags are allowed" and a nifty preview button.

Anyway, time to get back to rehearsing my 6 minute DEMO demo. Did I mention that we're going to DEMO?

We're going to DEMO!

So it is now somewhat public that LiquidPlanner has been chosen to debut at the DEMO conference! See, it says so right here on our home page. This is at once exciting and terrifying. I'm gonna have to give a five minute talk about what the heck our product does and try not to make an ass of myself, my CEO, or our product.

The biggest issue so far has been getting time to rehearse. We know we need to rehearse but there just doesn't seem to be any urgency around it. I mean, we all feel like it is urgent, but we never seem to actually rehearse.

In case you were wondering if you really need to rehearse a 5-6 minute talk that much, I'd like to point out that our company is spending thousands of dollars (as in "tens of") to send us down there to make a good impression. While the talk isn't the whole thing, it sure feels important.

And let me tell you, five minutes isn't very friggen long to describe a revolutionary new way to plan and manage projects.

That coupled with the fact that we're still putting the finishing touches on the product and just switched over to running on our shiny new production hardware (thanks to our god of operations, Brett) and running a beta program and are going to analysts briefings and are doing press interviews and are doing demos for investors (or potential investors) and you've got some very busy boys and girls.

So now we've just got to stay calm and... yeah... calm... right.

We'll see you at DEMO if you're there. I'll buy you beer if you meet me down in Palm Springs/Palm Desert anytime from January 27-30. Drop me a line if you have my email or find it on the LiquidPlanner site (hint... it's here). You can alternatively comment on this blog and I'll mock you... er... meet up with you down there.

See you in the desert!

Convention & Configuration

When I took the (very good) Pragmatic Studio Rails training course almost a year ago there was an interesting approach to configuration that Dave Thomas made sure to cover. I remember vividly Dave saying, “Rails favors convention over configuration.” He followed this up by saying that this frees the application developer from having to think too much about configuration.

What the heck does that mean? And how does it make my life better?

Well, to get a running server (for example) there are things that simply must be specified. They may be specified by default, but the information must be contained somewhere, right?

So I've an idea that there is a little wackiness going on here and I'd like to think about it for a few minutes and see if there isn't something there.

I’m going to step away (a long ways away) from software and use geometry in 3D to examine the information required to specify something.

---

Going in Circles

Consider the problem of specifying a circle in 3D.

There’s the brute force method of specifying all of the points on the circumference of the circle. Given that there are an infinite number of them that’s quite a task. But fortunately we can do much better.

Another way to do it is to specify any three distinct, non-collinear points on the circle’s circumference. There is a single distinct circle that passes through all of those three points.

Is this the only way to do this?

No.

We can also specify a plane by giving a single point (p1) in the plane along with a second distinct point (p2) that defines a line normal to the plane. There is only one plane with a given normal that passes through a given point. Now if we have the convention that the circle we want in 3D falls in that plane and has a center at the first point (p1) and a radius of (p1-p2) then we have completely determined the circle.

But wait! Where did the information that was contained in the third point go? Two points don’t determine a circle (in 3D).

That’s right. There is some information implied in the convention that we will use the first point for one purpose and the second point for another purpose and the relationship between those two points for a third purpose. The information is still there. We’re just representing it differently via our convention.

And here’s where things get really interesting. Consider the human interaction of specifying circles as configuring the circle just as you might configure a server.

If you are sitting at a keyboard trying to correctly configure circles and you enter the coordinates for a given point correctly 90% of the time, then the chances are that using the three point method you will get the entire circle right about (0.9^3) 73% of the time.

But using the two point method and our convention, you will get the entire circle right about (0.9^2) 81% of the time.

That’s only one error in five as opposed to one error in four! Hell, you can leave work early and go snowboarding this afternoon with that improvement.

---

Back to Servers

In the circle case we were only trying to get a couple of things right (the points). But when we configure servers there are often hundreds of settings and getting each one right, with the right setting, typed right, saved in the right file, in the right location, with the server rebooted (or whatever) to get it in the right state and you can see how errors add up. With 1000 settings and an error rate of just 1 in 1000 (0.1%) you have just a 37% chance of getting it right.

No wonder it takes so long and is so hard to configure software!

But with strong conventions there are far fewer "touch points" for you to mess up. The more configuration you can push into convention the better off you are. But everyone has to understand the conventions. In a way, those conventions are just shared principles. And they go a long ways towards making things easier and less error prone once you understand the principles that the conventions embody.

So, this has been a bit of a long rambling post. What I'm hoping you get out of this "conventional" discussion (yuk yuk... I make funny) is that there's nothing too wacky here and that conventions are your friend. They encode the exact same information in a more compact and less error prone way.

Breaking Down a Project: How Much Detail?

The Undocumented Features blog is exactly right that we should be aiming at a detail of tasks that are around 1 day in duration when beginning development. But there is a cost associated with having a person crank out those estimates. Often a project will need to “get the go-ahead” from the project sponsor before you can spend development team resources doing detailed estimates.

Those high level estimates are what often are so wrong. I think that one of the biggest reasons is that as project team members we’re giving estimates like “2 weeks”. “2 weeks” isn’t really an estimate, it’s a guess, a prediction.

An estimate is something like “1-4 weeks” or “3-5 days”. It really should be a range. One big downside of single-point guesses is that the guess is likely to be treated like a promise. On the other hand, giving a ranged estimate opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

One of the primary problems is that project managers need a single number to plug into MS Project (or any number of similar tools). That coupled with the observation that these single-point guesses (especially at the high-level) are treated as promises pretty much make a person want to give up on high-level estimation altogether.

If you always give all of your estimates in ranges (e.g. 4-6 person weeks, 1-3 days, 6-9 staff months, etc) it is quite clear that it is an estimate, not a prediction or a promise. Giving a range opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

Another nice thing about ranged estimates is that when you are asked to estimate something with poorly defined requirements you can give wide ranges to communicate the uncertainty. Well defined, believable requirements get estimates like 5-7 weeks whereas poorly defined, nebulous requirements get estimates like 4-20 weeks. This is especially true when giving high-level estimates.

There’s pretty much no way to get around doing high-level estimates. Your business needs some idea of the investment required to complete a project in order to make trade-offs. Hopefully this happens before your development team spends a bunch of time doing detailed estimates. Also folks in other departments (e.g. marketing, operations, manufacturing,…) need some idea of when they are likely to take delivery of the software. A team that can accurately (not precisely) give high-level estimates for these things gives their company a real competitive advantage.

So while it is frustrating, there are ways to do it and retain your sanity.