Dear Joel and Jeff,

You lauched Server Fault for SysAdmins, but you admit to not knowing that crowd as well as you know the programming crowd. That’s fine. But you need to find someone who does understand that crowd — and preferably already has the credibility you two have with programmers. Then you need to get him (or her) to co-host the podcast.

At the moment, your podcast does you no favours in promoting Server Fault: You constantly show little understanding of such things. The entire argument on hosting your own DNS on the most recent podcast is a perfect example.

I’m sure nobody minds if you don’t know everything, but to gain credibility for Server Fault, it needs a ’sponsor’ that can join your team — at least on the podcast.

Cheers!
Rick Measham

Forgive me reader, for I have sinned. It’s been some time since I last posted to this site.

I haven’t stopped writing, but instead have been trying to ’seed’ my new site with content. There’s only so many words in my head at any one time! Anyway, it’s now ready to be revealed to the world.

A year and a half ago I was promoted into management at the company I work for. And then I was left to work it out for myself. Thrown in the deep end.

I’m a resourceful kind of guy so I managed to find many resources to help me become the best manager I could. The more I studied the topic, the more I wanted to have my say on it too. I wanted especially to talk about people management (leadership) from the ‘vertical’ slice of Software Development. That’s what I’ve done as a career for many years, and it’s who I’m now leading. So, without further ado, I present http://geek-herding.com

While this blog will continue, I’m going to be restricting it to thinks that aren’t work related as I want to really push Geek Herding.

I’m interested in your feedback, though if you’re not in the software development industry, or interested in leadership and people management, it might be a little bit boring.

On the other hand, if you’re interested in either topic, I’d love it if you:

• Read the articles
• Commented on the articles
• Promoted the articles (if you’re tweeting, please use #geekherding so I find the tweet!)

Even better, I’m going to be looking for Guest Bloggers soon, so have a think if you have anything you might have to say on the topic.

Marketing: I have an idea for a new product, how long will it take to build?

Developer: We’d need a more complete spec.

Marketing: OK, but just putting your finger in the air ..

Developer: Maybe two weeks, so call it four.

January 23, in the customer newsletter:

Marketing: Our new product will be released on Feb 28th! Huzzah!

Sound familiar? I’m sure this happens again and again in software development companies the world over. I’ve certainly experienced it many times.

The problem, of course, is made up of many issues. Here’s three obvious issues:

1. Marketing just have an idea for a product. There’s no detailed spec. There’s no screens, no functional spec. yet they expect an estimate.
2. The developer provided an estimate without qualification
3. Despite a long history of ‘bad’ estimates from developers, marketing believed the estimate and passed it on to customers.

And here’s two more not-so-obvious, but very real issues:

1. The estimate give by the developer is given in isolation. Even if accurate, it totally ignores existing workload.
2. A new product (or feature or enhancement) isn’t just about writing code.

Fixing the problem

Let’s break the problem down into the listed issues and explore each of them.

No detailed spec.

When there’s an idea mooted, a lot needs to be considered before going to market. But if you were to write a detailed spec for everything  –  including mockups for every screen and functional detail for every action — without discussing the basic concept with every stake holder, you’d often waste a lot of time.

So the normal practice is to discuss the idea with each stake-holder to get a basic understanding of the project.

Imagine you rang someone to build you a pergola and you had not measured the size you wanted or considered any of the details like materials. Before you go ahead and research all that detail, you need to know if the project is even feasible. So you ring a random builder. What’s the best way to get an estimate without tying each other down to price? I like to call it the zeroes method. ie, “how many zeroes”?  Will it cost two-zeroes? $0 to $99? Or three? $100 to $999? Four? Five?

For development, I think the best question (at this stage) is what time-unit are we looking at? Is it days? Weeks? Months or Years?

The developer gave an estimate without qualification

OK, so it’s what was asked of him. And we do like to please. At first the developer doesn’t want to give an estimate. After all, he hasn’t seen the full scope. But then he figures that marketing aren’t dumb, they know that without a full scope there’s no way the estimate can be anywhere near accurate. So he caves in and thinks about the product.

The developer’s initial thought is ‘2 weeks’. But he’s aware that things never go as planned and so ups that to a month. (Note that he’s switched units .. when you hear that happen, it’s a good sign that the estimate is just a guestimate)

At this point the developer should have said: I cannot give you any reasonable estimate that will assist with product planning without a full spec.. But I understand that you don’t want to spend the time writing a full spec if the development time isn’t feasible. From what you’ve told me *thus far*, we would be looking at weeks rather than months. That said, I’d be happy to give you a proper estimate once the full spec is clarified.

Marketing believed the estimate

This is probably the biggest mistake in this scenario. Marketing always want estimates. Developers give estimates. Development always takes longer.

There’s a two-fold problem here:

First, marketing treated the estimate as an actual estimate rather than as a finger-in-the-air estimate based on a totally inadequate solution description.

Second, they compound this mistake by believing the number. The developer knows that estimates are always wildly optimistic, so he says “Maybe two weeks, so make it four”. But marketing should, by now, also know that anything the developer says is wildly optimistic and say to themselves “It’s always under, so let’s make it 8″.

Once both parties have over-estimated, we now have enough information to write a full spec but not enough to to to market.

* * *

Now, let’s consider those other two issues that compound the problem. These two issues exist even when the developer is making an educated estimate based on a fully delivered spec.

The estimate is given in isolation

When a developer is asked how long something will take to write, even if he has every bit of information he needs, the answer will be given in man-time, not clock-time. This means that a four-week development job will take four man-weeks. Or 20 developer-days if you prefer.

An estimate of four weeks only means “in four weeks time” when:

• he is sitting around waiting for the next project to start
• the previous project has no outstanding bugs that will need fixing
• he doesn’t need to provide assistance to customer service
• he doesn’t have meetings with his manager or team or company
• he doesn’t need to help the boss set up his new laptop
• his brain isn’t also worrying over the global financial crisis
• there are no public holidays and he has no annual leave booked
• he doesn’t get sick
• … and probably another thousand or so caveats.

When marketing is given an estimate from a developer, they need to consider scheduling as well as the actual estimate. They need to consider that the estimate is in man-days rather than calendar days.

A new product isn’t just code

This issue has nothing to do with the developer, but has everything to do with communication between marketing and the product owner (or whatever your company calls the person who manages the entire product).

If a developer estimates (once given a full spec) four weeks and the scheduler says it will start in two weeks and the developer will have around 80% of his time to give to the project, then the estimated date for completion of development is in 7 weeks time.

But that isn’t a go-to-market date. That is the date at which the documentation team can start to prepare the new user manuals. It’s the date that customer service can begin to learn how to support the product. It’s the date that user acceptance testing can begin. It’s the date from which the accounts team can get their billing systems ready. It’s certainly not the date that the product is going live.

In order to estimate the go-to-market date, every one of these (and many other) tasks need to be similarly spec’d and estimated. Will user-acceptance testing take two weeks? What if there’s serious usability problems? Does the acconts department need the developers to do some extra coding in order to be able to properly bill the service? If there’s any changes to the service after UAT, what does that mean for documentation.

So, given all that, why is only the development team expected to estimate the time to build before there’s any sort of spec? And even after there’s a spec, why isn’t anyone else expected to talk about time estimates?

Wrapping it all up

Before there’s a complete spec, any estimates are finger-in-the-air. This should never be assumed, both parties need to agree on this every time:

“I’ll give you a finger-in-the-air estimate, but I need you to understand that it is no way binding or anywhere near accurate”

Give finger-in-the-air estimates as a time unit:

“Weeks rather than months”

If there must be a number, over estimate until you have every bit of detail — on both ends:

“I think two weeks, so I’ll say four”

“He said four, so I’ll think eight”

Agree that once there is a full spec, a tighter estimate will be given, but that it is given in isolation:

“Now I have the full spec, I’ve mapped it out to take about 12 weeks to write the code. However this is 12 weeks in isolation. Experience shows that between everything else that happens, I get the equivilent of 60% of my time I can dedicate to a single project, therefore you should expect the project to go to UAT in 20 weeks.”

Acknowledge over and over again that development isn’t the only part of the project:

“While I’m happy to give you this estimate based on the full spec, we need to agree that after I’ve finished writing it there will be an undefined amount of time required to do user acceptance testing as well as sales, support and accounts product training and anything else that needs to happen before the product goes to market.”

If I haven’t made it clear already: Never assume the other party is thinking about things in a complete and rational manner. Even if you’re “just a developer”, make a list of things that need to happen after you’ve finished, before the product is released, and ask how preparation is going for each of them. You’ll earn a lot of kudos for knowing to think about these external things as well as possibly saving yourself (and the company) a lot of grief.

I hereby promise not to rant. Much.

Hey all you zealots .. give up and use tables.

If you have to have a meaningless <div>, you’re no longer semantic .. give up and use tables.

If you have to use Microsoft’s conditional comments just to get it to work in Internet explorer .. give up and use tables.

If you have to ask a chat room or forum how to get your three-column layout to work .. give up and use tables.

If you need to vertically center one piece of content against another .. give up and use tables.

If you spend more time arguing with someone than you can save by avoiding tables .. give up and use tables.

If you care so much about avoiding tables that you don’t have any time left to help people with their actual problem .. give up and use tables.

If you end up with classes in your CSS that are designed to give you the benefits of tables without using a table tag .. give up and use tables.

Seriously folks, you’re spending too much time avoiding them and proselytizing about your avoidance of them and not enough time creating useful content that the semantic nature of that content is worthless.

Update:

Woohoo! I just got banned from #html on freenode because I argued for using tables. There was no argument and no discussion. (OK, so I was mocking his inability to justify his contention, but seriously? banned?) BTW: I’m ‘Woosta’, ‘[wito'] is the zealot in question.

[22:53] <to_> which tag would you use to wrap <label> + <input> tags in a form?
[22:53] <[wito]> to_: I’m a fan of <fieldset><label><span>Text:</span> <input/></label></fieldset>
[22:54] <Woosta> I think it would be best defined by the design
[22:55] <to_> [wito]: but if you want to make input floating to the right of label in a 2 columns presentation layout, don’t you use a wrapping tag to clear float ?
[22:56] <[wito]> to_: actually, I use a display:table hierarchy
[22:58] <Woosta> just use a table
[22:59] <[wito]> Woosta: WRONG
[22:59] <Woosta> no: it works and it’s fast
[22:59] <Woosta> piss farting around with CSS is a poor use of your time
[23:00] <[wito]> Woosta: protip: you don’t argue with me.
[23:00] <Woosta> Bwahahahahha
[23:00] <[wito]> Especially not when I tell you to stop offering destructive, counterproductive advice as you are now
[23:01] <Woosta> Zealots make me laugh
[23:01] <[wito]> How about you spend some time in the quiet corner?
[23:02] <Woosta> Why me? I have plenty of time up my sleeve. I think you need the time out so you can get some work done as your stupid-ass CSS crap takes you 20 times longer than a simple table would.
[23:03] [Notice] -ChanServ- You have been quieted on #html by [wito] (wito)
[23:03] *** ChanServ sets a ban on __________.
[23:03] <[wito]> Let’s have some quiet time for Woosta

Update 2:

Found this funny mug on Zazzle

It’s a nice neat truism, that strangely bears itself out in the real world. Approximately 20% of the population pay 80% of the tax in most economies — 80% of the reward coming from 20% of the populace. Microsoft say that if they can fix 20% of the bugs, 80% of people would be happy — 20% of the effort resulting in 80% of the reward.

It even works with the most mundane of matters. Think about your wardrobe and compare it to what you wear. If you’re like most people, you wear 20% of your clothes 80% of the time and the other 80% of your clothes you wear just 20% of the time.

But I digress. Read more about the Pareto Principle over at Wikipedia.

Here’s the thing: When you’re working on some sort of project that has a finite scope, at the time you have done 80% of the work, there is only 20% of the final result in any tangible form. It’s discouraging if you only look at the result obtained, but hugely encouraging if you focus on the work left to do.

Consider all the effort that goes into planning a wedding: there’s nothing to show for it other than a pile of tick-boxes on a todo list until the Big Day when all that effort suddenly bears its fruit.

Think about installing blinds: 80% of the effort is to get the fixings in place. At this time, there’s no shade being provided by the blind, and all you can see is a pile of brackets screwed to the wall.

Be encouraged: This moment in time, when you have completed 80% of the work, is huge. Before now, every percentage of effort resulted in just 0.25% of result. From now on, every percentage of effort will result in an average of 4% of result. So it’s worth celebrating.

And if it’s worth celebrating, it’s worth naming. Therefore, let me present the story of a software development team, making a game. The story goes (you can read it at Tales of the Rampant Coyote) that the development team spent much effort (80%) just to get to the point where a triangle was rendered on a monitor. Those not on the team just saw a black triangle. They couldn’t understand how the many months of development resulted in something so simple. Even more, they couldn’t understand why the development team were so happy. But we know, right? 80% of the effort. That triangle was the 20% of result. After finally getting the triangle to render, the rest of the development was easy. As they say “It’s all downhill from here”.

So I propose that we take this story as a great example of the 80/20 rule in action and use the Black Triangle as the name for that point at which you have ‘broken the camel’s back’.

What Black Triangles can you celebrate this week? When you find one, savor it and celebrate it. Even if nobody else understands.

My RSII avatar is now also my gravatar, and it’s let me add my other email addresses to the one account. So now my CPAN modules all show my RSII Gravatar. When you look at CPAN, you’ll know that the Rick Measham over there, is the same as the Rick Measham over here. Now if only we can convince more sites to implement gravatar-managed avatars!

I’ve just installed gravatars on my blog here, so if you have a gravatar it will show up next to your comment. If you don’t have a gravatar, you’ll get the default silhouette.

Most of today’s online development work is build-it-as-you-fly. Even with passengers on board.

In the early days when the plane is just flyable but has no seats, windows or walls you stick up a sign that says ‘Beta’ and welcome people on board. If you’re nice, you only invite your friends and called it a ‘Closed Beta’.

Then once you have the seats, windows and walls you call it ‘gamma’ or ‘release 1.0′ and welcome the public. There’s no flight attendants and certainly no parachutes yet, but it initially feels like it’s all done.

The problem is that at about this time, someone notices that the windows could do with shutters, but that means replacing them. So that’s where development priorities go: back to the windows, while we’re still flying, and while we still don’t have flight attendants or parachutes.

This all works rather well, and (thankfully!) people are now so used to it that you hardly even need to apologize when something goes wrong. But we really need to change this. Rapid prototyping should just be that: it should never get outside the company. Once it does, the sales and marketing types will start to sell it as finished-or-nearly-finished.

Instead we need to take our rapid prototypes as being as useful to the final product as a scrawl on a whiteboard. They’re a proof of concept, or something you can show your VC partners at the same time you show them your napkin sketches.

Just because our programs won’t kill people if they’re not finished properly when we invite passengers aboard doesn’t mean we shouldn’t treat is just as seriously.

As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.

I now introduce Measham’s Law:

As an online discussion regarding the features of a piece of open source software grows longer, the probability of someone saying “It’s open source, you write it” approaches one.

Bacn is the wrong term.

Bacon is the king of porcine produce. Bacon is smoked, fried, savored. If someone offered me ham or bacon, I’d take the bacon every day. Almost everyone I’ve spoken to has the same reaction. There is no better way to eat pig than thick slices of double smoked bacon. So why on earth would PodCamp decide that it was the right word for messages that come between ham and spam?

I don’t know, but I plan to stop it.

These message should be called ‘Sausage’. A pork sausage is still an enjoyable way to eat pig, but it’s grissly and made from the parts of the pig you’d prefer to not talk about (seriously, if you ever try a saussage made from prime-cuts, you’ll hate it!)

A sausage, like notification email, is nice. But it isn’t the best. It’s not full of useful or enjoyable information, gossip or photos from friends, but is made by a machine to tell you something you may or may not overly care about.

From now on, I plan to append the words “Sausage Damnit!” to any posts I see that relate to so called ‘Bacn’.

Please join me (and feel free to link it to this article if you don’t want to write your own!)