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.

Multi-Tasking is Killing Your Business

I read a couple of articles recently and can now distill the vague feeling that I've always had that multi-tasking is not a good thing down to a simple statement that it is certainly a very bad thing.

And I can prove it.

Watch, nothing up my sleeve...

We all know there's thrash when switching, but let's assume that you've got some kind of dream team that can switch tasks perfectly. I do this because I don't want to get into a long discussion of "how good I am at multi-tasking".

Suppose we have 4 projects of 6 months duration each. Let's have the team multi-task and do all those things in parallel. They work one month on Project 1 , then move on to Project 2, and so on. Since there's no thrash it shouldn't hurt much right?


The average time to complete the projects is 22.5 months or just short of two years.

Now let's have our same team concentrate on one project at a time and see what happens.


This time the average time to complete is 15 months. That's 2/3 of the average for the multi-tasking schedule. But wait... it gets worse. What if those four projects are not of equal value.

We know that all projects are not created equal. Some are more valuable to your business than others. It is quite possible that your highest value project is a factor of ten more valuable than your least valuable project (or more). Let's model this by saying that each project on our stack-ranked list is twice as valuable as the one below it. Remember, I'm talking value not effort here.

Let's look 30 months out and see what each method has delivered in value to the business. Here's what the plots look like when the vertical scale is business value per month. The light green shaded area is the total value the projects have generated 30 months after project initiation.


So the multi-tasking project management method has delivered 124 units of value (8*9 + 4*8 + 2*7 + 1*6 = 124). But the single-tasking project... whoa... look out!


That's a whopping 294 units of value (8*24 + 4*18 + 2*12 + 1*6). More than DOUBLE.

In other words, if I worked for Single-Tasking Enterprises and you worked for Multi-Tasking Incorporated we'd be kicking your ass. (And no, you wouldn't be an acquisition target since we don't want your crappy multi-tasking IP.)

Okay, so multi-tasking sucks. What can you do about it?

I think the most important thing is to work off of a single prioritized list. You need one single list stacked top to bottom by priority for your people to use. The list must be public within your company. That way everyone is on the same page as to which project gets worked on first.

But I can hear you saying, "Hey, we work on many things at once because we're so busy and need to get all this stuff done yesterday!"

Yeah, and you can keep doing that. And as I've shown it will keep killing your business.

As leaders (and I mean anyone who has people under them) we must set hard priorities and stick to them. Constant switching of a person's "top priority" is a sure sign of weakness as a leader. If you are doing this STOP.

But what if you made a mistake in the priority order?

Look, even if we reverse the business value order and deliver the lowest value projects first we still come out ahead single-tasking. We get 156 units of value at the 30 month mark (1*24 + 2*18 + 4*12 + 8*6). That's still 25% more than the multi-tasking result with the "proper order".


The lesson is that it is less important that you pick exactly the optimal order in which to do projects. It is critically important that you build teams that focus on delivering one project at a time. Your teams must be empowered to protect their time and their schedule by telling all distractions to "piss directly off". Your leads must understand this and be rewarded for protecting their folks from distractions.

I find this stuff fascinating. How could I have run projects for all these years and never noticed how bad this is before?

Statistical Frustration

Okay... I must be getting old.

Anytime you find yourself saying things like, "Friggen kids these days know nothing about statistics", you pretty much know that oldness has happened. It's just driving me crazy that people don't understand what the hell "expected value" is or what the difference between the mean and the median is. Golly, people have a hard time with standard deviation, how the heck am I supposed to explain confidence in an estimate to them?

At the heart of this is the problem that most people don't get what is meant by probability or what is probable. Suppose for a minute that the VP of Customer Placation comes into your office and asks, "How long will it take to add frammerstammers to the hoopydo?"

Now, because you're not a n00b at estimation you hand him back a range.

"That'll take 5-20 days", you say. And you add, "I'm about 90% confident."

This is where about an hour and a half of useless discussion about "what the heck you mean" is going to go on because Mr. (or Mrs., Ms., Miss) VP just doesn't really want to know what is going on here. They just want a date that you promise that the hoopydo will have frammerstammers.

While willful ignorance is pathetic and deplorable (like spam) it is just a fact of life (like spam). Lecturing on probability and what it means to be confident will do you no good. They want a social contract not a lesson in Stat101.

So what to do?

Well, I think you need to know more about statistics than they do and be able to abstract away the math and crap like that from the discussion so that they come away with a good english language understanding of what you have promised them.

You need to explain that you don't know how long it is going to take. "Whadda I look like? The amazing Randy?" Then you can go on to explain that

You need to explain to them that if they make you promise to give them frammerstammers for the hoopydo on a specific date that the date will need to be out past the end of your range and that no, you can't just take the average and call it the promise. Be wary, be very wary, of giving a single number at this point. They will want to start using one. Don't fall for it.

Because the minute that you use a single number it becomes the default promise date. 3 months from now nobody but you will remember that you said 5-10 weeks. They'll only remember the 7 week number that everyone kept saying in the meeting. "Seven is in the middle, right?"

Yeah... uh... right.

If people could just grasp a couple of simple concepts from statistics this would all be so much simpler. We'd have a shared vocabulary to use when talking about estimates.

At its heart a good estimate is a range of values that you think the actual value will fall inside of. The narrower the range, the less likely you are to be right. Let me give an example. I'm going to give several estimates of the number of teeth you have.

32 is a bad estimate. It's a perfectly good guess. But a bad estimate. Because it is only correct if you have the normal number of teeth for an adult human and have not had your wisdom teeth removed.

0-50 is a better (though nearly useless estimate) since I'm almost certain that the actual number of teeth you have falls somewhere inside that range (100% confidence). Knowing nothing else I'd estimate the number of teeth you have at 25-32 and 80% confidence.

With more information my estimates get better. If you tell me that you are a 90 year old ex-hockey player I would estimate that you have 0-20 teeth. For a 16 year old bookworm I'll estimate 27-32 teeth. Again, 80% confidence.

The confidence part there is important. It helps tell you how statistically likely I think the actual value is to fall within my range. Once you start viewing these things as statements of probabilities a whole world of possibilities opens up. I'll explain some of the fantastic things that simply fall out of using probabilities in 2-5 future posts.