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.

Last Work Day of Summer

The end of summer always makes me feel a little down. When I was a kid it always seemed like summer would go on forever. They get shorter and shorter (and I seem to do less and less) the older I get.

Working at a startup again (requisite plug: http://liquidplanner.com) has been really interesting. This team has gone into it with a very specific product in mind. The last startup that I was involved with could never really figure out what it was building. This is very different. For one thing, we drink a lot more coffee!

Building project management software is kinda entertaining and kinda frustrating all at the same time. So much of the software out there is so friggen bad that it feels like, "Hey, this should be easy!" And that's also where a lot of the frustration comes from as well.

My office upstairs at home has cooled off from the heat of the day. Soon the Seattle rains will start again. That'll be nice because I'll feel much less guilty about spending my life thinking about statistics, software, human interaction and project management.

See, everyone thinks that this should be an easy problem to solve. How hard can it be to figure out when a project will be done?

Well let me tell you that it is pretty goddamned hard.

Even the simplest little thing like figuring out how much time it will take to do a simple, simple task is nearly hopeless. And it isn't just because we're concentrating on solving this problem for project management of software projects. You hear all this crap about how building software is not like building houses because the houses have a plan and defined methods and blah blah blah.

Bullshit.

If you think that building a house is all cut and dried and that all of that is a "solved problem" and that there is little uncertainty in home construction then you've obviously never built a house. As someone who has personally done a major remodel (as in, I swung the damned hammer and cut the damned two-by-fours) let me tell you that you make a lotta shit up as you go along.

So what's the difference? Well, I think that like a lot of things it is the people. When you work construction you show up at 8am and work through 5pm (provided you're on schedule). It is not that construction workers are predictable robots, it's that software workers are unpredictable flakes. And I'm fine with that.

In fact, if I had to punch a clock again I'd quit. Period.

We want those people to be allowed to work however makes them the happiest. Even if it would be easier to schedule zombies to do the work would we really want to encourage that? What I want is to liberate the knowledge workers from the tyranny of their schedules. Free them to work however and whenever they want and still have their projects succeed. Hell, not just succeed, friggen ROCK. Exceed all expectations for function, cost, schedule.

The tricky thing is that we're trying to build software that predicts a schedule from the most vague information. And we're trying to do it while not interfering with the poor bastard who has his head full of Amazon Web Service APIs while rewriting the chunk of code that is going to actually get his company paid but is already looking kinda sketchy because it's a rewrite of Jimmy Foobraugh's port from Fortran-77 of the linear regression algorithm and Jimmy got fired for never commenting anything.

Yeah.

I should have drunk more rum this summer. That is my conclusion.

Hi {SalesWeenie.FirstName}...

Nice title! Feels real personalized.

Yeah almost as personalized as this knee slapper from SalesForce.com:

Hi {Lead.FirstName},

Salesforce.com is above Siebel CRM for the first time as “Leaders” in the 2007 CRM/SFA Magic Quadrant, the industry’s most prestigious and valued ranking of CRM products and services.

Previously, Siebel was the only leader, and now Salesforce.com is above Siebel. This is a milestone for the industry and shows that an on-demand service can replace traditional software in a leadership position!

"We predict that within three years the majority of SFA deployments will be based on Software-as-a-Service."
--Gartner, Inc.

View the entire report here:
http://www.salesforce.com/form/pdf/sfa_magiicquadrant_gartner.jsp?d=70130000000DFHo


Regards,
Nicole

The irony is exquisite.

Come on folks. You sell software that does CRM and I'm supposed to trust your software when I get something like this?

Please!

Isn't this exactly the kind of thing that good CRM software is supposed to prevent? But that aside, the real problem is that there is a not so subtle distinction between personalized and personal emails.

Send me a personal email. Send me an email that shows that you know me; that you know my dog's name; that you know what I had for lunch; that you know I'm partial to rum. Send me an email that lets me know that I'm important to you as a person (not just a {Lead.FirstName}).

Or alternatively, don't.

I mean it. You don't know me Nicole. Just admit it. You don't know me, my dog, my lunch, or that I am very good friends with Jerry. Just send me a sales email like every other crappy sales email but which at least has the honesty and integrity to admit that you don't know me.


But whatever you do, just don't let me know that you think of me only as {Lead.FirstName}.

That's just pathetic.

Quick Notes from Ignite Seattle

So tonight I went to tonight's Ignite Seattle event.

Dude! I mean DUDE!

The talk format is 5 minutes with automagic 15 second slide changes. The talks were GREAT!

The stand outs were Rob Gruhl's talk about "How to Buy a New Car" (strategy), "Startup Metrics for Pirates: AARRR!" by Dave McClure (my personal favorite), and Leo Dirac's "Venture Capital Term Sheets". These were really great, informative 5 minute talks. You can see the video from the talks and the decks (I think) on the Ignite Seattle site.

One disappointment was Werewolf Strategy by HB Siegel. While he talked about the game, he never really got into the strategy. In part it was disappointing because I guess I had really high expectations for the talk. In retrospect it really wasn't a bad talk (in fact it was really entertaining) I just hoped for more meat about strategy. The game itself is perfectly suited to this short format of talk since in the game there's no objective information that is usable in each round. Thus the game is played at a higher level by playing the players rather than playing the game. If I lost you on that one just drop me a line an we'll play it sometime.

I'm dying to do a talk at one of these. If you have suggestions for a topic that would fit nicely in 5 minutes please leave a comment.

Anyway, I'm exhausted but totally energized by tonight's events. If you get a chance you MUST go. It is one of the best geek-fests I've ever been to.

-------------------
Follow up from 8/11/2007

Dave McClure nicely posted a comment with the deck from his talk. You can find it here at Startup Metrics for Pirates: AARRR!.

Busy, Busy, Busy

Holy crap I've been busy!

It's been like two months since I last posted and all kinds of stuff has been going on.

First off, it's getting really exciting at LiquidPlanner! We're getting ready to come out of that highly secretive and mysterious "stealth mode" that all really cool start-ups do (well, it seems all cool at the time).

We've re-named "Team46" as "LiquidPlanner" and I've been running around showing the product to anyone who will sit still for two hours and look at my laptop. Patent drafts are about to be handed back from the lawyers and then things will really crank up.

On Friday I drove all the way up to Snohomish to pick up a server rack (well, half-height rack) to go in the office for us to configure our servers before moving them to the co-lo. After all that and dragging the damned thing back and hauling it upstairs to the office I discover that it won't fit the rails we've got for the servers. That's $40 bucks and 3 hours that I'll never get back. Oh well.

I'm SO stoked to get the servers up and running so we can start showing people what we've been building. Just a little longer and we'll start handing out logins to the private Alpha servers so that more folks can take a look and see what they think. I've got to get the forum software up and running too. We're a Rails shop so we've chosen Beast and I think I'm gonna be really happy with it. It seems simple and straightforward while still allowing most of the features that we want.

I've been reading just about everything I can get my hands on about probabilistic scheduling and some of it is at once cool, and nearly incomprehensible. As we work on this and I dig into the subject I become more and more convinced that most scheduling woes in projects are caused by Murphy's law and Parkinson's law (work expands to fill available time) colliding with bad estimates (like saying 10 days instead of giving a range like 8-15 days) and the usual way that Gantt charts get drawn.

There's this industry report called the Standish CHAOS report (gotta love that name) that says that something like 80% of projects miss their schedule, budget, or scope. I think that I understand where that number comes from and here's the kicker... it isn't bad project management. It is the system itself that is causing the misses. You want a hint... it's all about the log-normal distribution.

Writing can save your teeth!

I was going on a writing-fest today. This was only half intentional. Here's what happened...

I was going to a whole friggen big list of sites to see what they were about and how their user communities behaved and what features they had that we want to steal emulate and I found all these cool topics that I wanted to chime in on.

But the minute that I wanted to dash off a 5 minute note I started thinking about the topic, and that lead me to Wikipedia to research the topic, and before I know it about 2 hours has gone by and I've got about 6 paragraphs of research with friggen footnotes and crap all ready to post to some forum that I've only ever been to once and will probably never visit again except that now I'm getting email responding to my post saying, "That's exactly what I think" or "You're full of crap HotKatie80".

... um... sorry, that was a different forum.

Anyway, what I started to notice was that as I wrote the posts my ideas kept changing. I'd write, think about what I wrote, revise what I wrote, read what I wrote, and that would change what I thought, and...

Yeah... you can see where this is headed.

So now I'm thinking (as I'm writing this) that this might be a really good explanation for why spec reviews are so important.

What!?!?!

Okay, bear with me...

The thing is that a written spec can't "wave its hands" at a problem. You really have to think through how the thing will work and make it all simultaneously consistent. Since a written spec is random access (in a way that a conversation is not) you can compare one section to another easily to find "bugs". So the act of writing the spec is the important thing. And it can't be just for yourself, but for public consumption (or as public as your spec can be which is probably a spec review).

Talk is a high bandwidth but essentially serial access connection with another person's brain. But the written word can be jumped around in really at random. This allows you to put facts side-by-side easily and compare them to see what likely outcomes or problems might arise.

For example, when I was a kid if I had written down that I was going to take my friend's soapbox racer to the top of our (very) steep hill and ride down to stop in the cul-de-sac with no brakes and no plan for how to stop at the end I can tell you that it would have seemed just as dumb as it does now when I stare at it in print.

That's because I can put "steep", "no brakes", "stop", and "cul-de-sac" all side-by-side in a way that just wasn't possible when we talked over this "plan" for the half-hour it took Jon & Dave & my brother & I to put it together and push the soapbox racer sans brakes to the top of the (very) steep hill.

Hell, we even had a "spec review" before we went forward.

Bruce:
"Okay, I'll jump in and you push me off and then I'll drive down to the bottom of the hill and stop in the cul-de-sac."

Dave:
"Sounds good."

Jon:
"Go for it."

My Brother:
"You're an idiot... er... Yeah, go for it!"


If only I'd written it down first.

I might not have done it (okay, it's still a toss up).

I might still have most of my front tooth.

The Joy of Patent Work

I've been trying to get the patent applications in order for the stuff we've been working on at Team46 for the past couple of months. Oh the joy of government legalese!

The US Patent & Trademark Office says:
------------------
“The USPTO will accept color drawings in utility patent applications and statutory invention registrations only after granting a petition explaining why the color drawings are necessary. Any such petition must include the following:

the appropriate fee set forth in 37 CFR §1.17(h)

three sets of color drawings; and

the following language as the first paragraph in that portion of the specification relating to the BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING. If the language is not in the specification, an amendment to insert the language must accompany the petition.”
------------------

Blaarghh!!! Please, kill me now.

Oh yeah… and THIS gem…

------------------
“The number of each sheet should be shown by two Arabic numerals placed on either side of an oblique line, with the first being the sheet number and the second being the total number of sheets of drawings, with no other marking.”
------------------

Oh, is that a fancy way of saying number sheets like 2 of 5 in this way; 2/5 ?

An oblique line!!?!? Grrr….

So if you've been tasked with taking care of IP stuff for your start-up let me give you some handy tips that I've come to so far...

Hire a lawyer
No, really. Time is one of your most precious commodities. Don't waste it on crap like trying to figure out the fancy government talk above.

Really prepare to talk to your lawyer
I like to write down all of my ideas, no matter how wacky or obvious, and get them in one big list. I write a short description (like two sentences) so I have a good idea of what I'm talking about. I also include diagrams or screenshots if I have them. Then I print out the list of ideas (with the numbers) as a table of contents and the ideas with their short descriptions with one idea per page. This way I have plenty of whitespace on my pages to take notes on what the lawyer says.

Types and Costs of Filings
There are two types of patent filings; Provisional (PF) and Utility (UF). Utility filings are what people typically think of when they think “patent”.

Provisional	Utility
Cheaper ($500-$5k)	More expensive (see below)
12 mo. then abandon or file utility	20 yrs from filing or 17 yrs from issue
Establish date for “prior art”	Establish exclusivity protection
Cannot be “tweaked” much before U.F.	Can be tweaked or amended significantly
Not published	Published

Figure 1 – Comparison of Provisional and Utility Filings

For Utility filings the costs based upon size and complexity of filing are t-shirt sized like this:

Size & Complexity	Initial Filing	2-3 Years Later
Low	$12k +- 2k	$12k
Medium	$15k +- 2k	$15k
High	$18k +- 2k	$18k
Gov.t Fees	$1.5k - $2.5k

Figure 2 – Estimates of Costs for Utility Filings

One advantage to a Utility Filing is that it forces you to go through the whole process and see what needs to be shored up in any Provisional Filings you want to file.

It may also be worth your while to read through a few actual patents. Once you get past the language you can start to see how they are organized and what they are looking for in terms of specificity and organization. The US Patent Office has a pretty usable patent search site that covers both applications and grated patents.

That's about all I can think of right now. My eyeballs are about to fall out. Time to go home and drink myself to sleep. Thanks Patent Office.

To bug or not to bug

That is the question.

I used to be a software tester. In a way that's like saying, "I used to be an alcoholic." Just because you've moved on doesn't mean it stops defining a lot of your behavior. You see a bug and... well... it bugs you. You want it fixed.

So you see some trivial but vaguely troubling thing on a site and because your fingers can type a bug report on their own without your actually having to tell them to, bada-bing; the site owner gets a little nasty bomb in their inbox.

You're trying to help. You "just want to help them make their site better." But what you're actually doing is sucking the gumption right out of them. It isn't helping, it's hurting.

I did this recently.

The nice folks at Construx (who I think are quite good and who I rather like personally as well as professionally) put up a forums and blogs site for their training & consulting firm.

Now in my defense I wasn't trying to do something completely insane. I created a account, logged in, and could not see the forums or the blogs. This struck me as something they'd like to know about.

And here's where I went wrong. I wrote a bug report...

---

Sent From: brucephenry
Subject: Bug: If not logged in email form blanks after login
__________________________________

Repro:

1. goto http://blogs.construx.com/members/EarlBCx.aspx
2. Login
3. Open another tab in your browser
4. Click Send Earl an email link on the right
5. In other window logout
6. Type your message to Earl and hit [Send Email] button

Result:

Prompt to login followed by a blank email form.

Expected:

Prompt to login followed by "Thanks your email was sent" page (presumably along with sending the email as typed).

Bruce P. Henry

---

Why does the bug report have nothing at all to do with not being able to see the forums?

Well, I tried to send that one but as you can see above, if you're not logged in, you can't send email.

So why was I logged out?

Because if I was logged in I couldn't see the forums and so I also couldn't get the link in the forums to send mail.

As Earl says, "Arrrgg!"

This doesn't make me right. It just makes me a dork.

Earl is right (and he calls me on it). It really is a selfish thing to send this kind of crap.

He didn't ask me to test his site. He asked me to use it. To read it. To come play in it. He was my host and I threw rocks through his windows.

I was a poor guest. But it didn't have to be like this.

I just as easily could have sent a conversational, friendly email that said things like, "Hi! How's it going? It's really great that you guys have these blogs and forums and I'm looking forward to reading them." All of which is absolutely true.

"Hey I've noticed that I'm having trouble reading the forums and blogs when I'm signed in. This makes it hard for me to write comments on your blogs or post to the forums. The site looks great though and I'm really happy to see you folks building more of a community around your best practices stuff!"

That's all it would have taken. Just a little conversational civility.

I'm such a dork.

Essential Interface Complexity

After reading a very interesting and insightful post on the Subtraction Blog I got to thinking about what it means for an interface to be "as simple as possible".

The kernel of the post is that for most software if you are going to offend/annoy anyone, you want it to be the experts. This is because for most software the experience level of users is distributed along a bell curve. And that mean that the vast preponderance of users live smack dab in the middle (or at least in the suburbs of the middle).

Now, while true for some software, I think it is far from true for all software.

It is obviously true for the majority of consumer software (and products in general). I want my tools/products to do one thing and to do it clearly and well. Less really is more in this kind of simple "I want my music to play" or "I want that text to be red" kind of tool.

However, there is another kind of tool. That's a tool for dealing with very complex problems. There is an entire class of problems sometimes called "wicked" problems (ref. http://en.wikipedia.org/wiki/Wicked_problems) that don't really have a simple solution. In this case it may be best to think of the problem (and the UI) as having no beginner/intermediate users.

There are numerous tools that take this approach when the problem is hard (or there is a negligible number of non-expert users).

• Mathematica
• Call Center Tools
• Development Tools
• etc

It is perfectly fine to want an interface as simple as possible. But it still needs to be complex enough to capture the essential complexity of the problem you're trying to solve. And the problem(s) that these tools are trying to solve are either extremely complex or the novices get "learned up" real fast.


The Eclipse IDE is a good example of a product geared directly to an expert end user. There is little done to hide the complexity of the tool from the user. In fact, the tool allows an enormous amount of complexity (compare it to an iPod) in order to perform all of the tasks that are essential to the product.

But in a sense it is also about as simple as you could possibly make it without losing the essence of the problem that they are trying to solve with the IDE. On the other side of this is booking some travel on a site like Expedia. Here the actual moving parts behind making a booking are incredibly complex (I used to work for them and let me tell you, airlines and hotels do not make it easy on them). But what the user wants to do has little essential complexity.

"I want to go to Hawaii for 5 days next month and stay at the Hyatt on Maui" is pretty friggen simple.

That's why a "give me my crap and here's some money wizard works so well for sites like Expedia and Amazon. The user really wants something conceptually simple. It is also why a "write Office 2011" wizard would not work so well.

Easy? Yes.

Simple? Yes.

But it lacks something essential.

Organizational Breathing

So, I find myself sitting in my office watching the sun set over Seattle and thinking about organizations and how they change over time. It's interesting because I've now been around the proverbial block enough that I can start to see some patterns emerging.

Orgs need to go through a consolidate/diversify cycle to open up gaps that allow the high performing individuals to move up in the organization.

Static organizations tend towards hierarchical, seniority based promotion. This drives out some of your best performers.

It is natural from time to time to need to centralize or decentralize the functions in an organization. There are certain things that are easier to do when you have centralized a function (e.g. standardize process, share best practices, exchange tribal knowledge) and other things that are easier to do when you have decentralized a function (e.g. experiment with new methods, adopt new processes, eliminate old processes). Each of these is valuable in its own time. There's never a "perfect" organization just as there's never a perfect organism. Both organizations and organisms need to change, adapt, grow. At best they are dynamic, living things that need the freedom to change, but also the evolutionary pressure to cull the weak from the herd. That's where organizational breathing comes in.

I thought about this for quite a while when I worked at Expedia. I would often have people in my organization ask me what we were doing with the overall structure of the software development team and what would be next. They wanted to know if we would be reducing the number of independent project teams (centralizing functions like testing for example) or if we would be allowing specific business functions to "spin-off internally" (like making our corporate travel team a separate organization). Which one is right? Where are we going? Didn't we just finish centralizing (or decentralizing) that function? Can't management make up their damn minds?

Didn't you just finish inhaling (or exhaling)? Can't you make up your damn mind and just stick with one?

If we make the organization completely static then let's see what happens.

At first everything seems sane. Just business as usual. Good people get promoted. Bad people get fired (ideally). But occasionally someone makes a mistake. And then the proverbial wild rumpus starts.

Because now you have a manager or a director (or worse yet a VP) that's in over their head. They aren't doing a good job and it is affecting everyone below them. Additionally as that person's manager it may be hard to admit or see that they are in trouble. Heck, they may in fact be very gifted at "managing up" and effectively protected by that skill.

Now because the organization is static, there's no real way to move them "laterally" into a less sensitive position unless you just happen to have one open. In fact you've likely got no other option than to give them the boot because they just are not a good fit for the current position. And this is important, even if they are an otherwise excellent asset for the company overall.

"You have failed me for the final time director. Hssss. Whooosh. Hssss. Whooosh..."

That hissing and whooshing may be the breathing of an upper management despot, or it may be the talent escaping from your company.

And what of the otherwise excellent people who get stuck under great managers?

"Now wait a minute." you say. "What's so bad about being under an excellent manager?"

"Nothing at all." I say. "Provided you don't want to move up in the organization."

Ideally excellent managers tend to bring up excellent employees. So you get a bunch of excellent people reporting to your excellent manager. But in a static organization the excellent people below excellent managers end up fighting among themselves for the one spot (since we're certainly not going to reshuffle the whole org once a year or so) that your excellent manager is occupying. And then in the end you get a bunch of excellent folks leaving because of "politics" when it was really just that the game was rigged for exactly this outcome from the start.

Your excellent manager may end up leaving too since she may get sick of being undermined by the otherwise excellent people she's been training.

Sigh...

So breathe damn it!

Move people around.

Breathe in. Centralize functions (like DBAs or Testing or Program Management) when you want to spread best practices and when you want to do just a couple of LARGE projects. Or when those functions are just getting started in your company (like formal project management).

Breathe out. Scatter people into little pods of developers, testers, PMs, project managers, etc when you want to focus on a specific area of your product (like hotel search results, or better UI for selling cruises).

And each time you do it, just like breathing, go "out with the bad and in with the good." You'll be okay as long as you don't stop doing it.