Hacker News Reader

Comment by willholloway | Hacker News Reader

Imagine if Gandalf acted the way managers and clients do with time estimates when he sent Frodo and Sam to Mount Doom.

"You haven't destroyed the One Ring yet? Why not? You said it would be destroyed by Friday."

If you trust your people to carry the ball as far as they can everyday until it is in the end zone you will get better results.

This is why in my consultancy I have stopped giving time estimates except for very small projects. I take 50% upfront and 50% upon completion so our interests are aligned.

The time and stress of estimates are just not worth it in software development.

View on HN

That's a nice sentiment, but I don't see how you can apply it to any situation that involves estimating a project for a client, based on client's requirements.

I wish the article actually addressed the problem of estimating the time/effort for the whole project. What I'm dying to learn is what one is supposed to do when the client says "I need a system that does X, Y and Z. How long do you think it will take you and how much would you charge for it?"

One thing I'm sure you can't do is say "I don't know, because making accurate long-term estimates is fundamentally impossible. But hey, I know we're going to do a great job, so why don't you just trust us?"

I think what the article is highlighting is that the it needs to do x, y and z for the cost of the implicit budget I have in my head as a client is fundamentally broken and discussions need to address the inherent risk otherwise estimates will continue to be wildly wrong.

It's hard because it takes a mature operator to say no I won't give you a total time estimate for what you just explained to me in 5 minutes.

The context needs to be, crafting software is difficult what's important is that you prioritize your desired features in case delivering those early ones blows out and uses up your budget it's then about hiring developers who you can trust to drive the project professionally and honestly and work hard and not stuff you around. Let's talk about why we think we are the ones worthy off your trust and the sorts of things you should be looking for in hiring a developer.

If the client is asking for an implementation as per your example, you already have a major problem (and are in a race to the bottom as a supplier). The spec should be expressed purely in terms of business outcome (e.g. I need a system that can handle more transactions within the next 3 months). (Not to mention that the most interesting and valuable requirements are usually the ones that the client doesn't yet know about.)

Second problem with this scenario is that if you are charging a fixed amount for a complete system, you are assuming all the risk (and essentially selling a form of product). Generally that's a lousy deal for a client on build cost and maintenance of a bespoke system. Few desired business outcomes are so unique that they require a bespoke solution - so this should really be a very niche business, not the norm at all.

Usually the best reply is along the lines of: Refining the requirements is an iterative process; we'll both learn more on the way about exactly what the system needs to do and how it should do it. So let's break it down into small steps. We'll implement X first, then you pay us for X based on how long it turned out to actually take, then we can move on to Y. If you're unsatisfied at any stage you can walk away and keep everything you've paid for thus far.

I'd be curious where you find these customers that don't care when something gets done. I have yet to find them.

Often they don't care but they ask anyway. Just to keep you on your toes and just to show that they still care about finishing it.

That's not a realistic comparison. More realistic would be if Gandalf said "If the ring is not destroyed by Friday, Sauron will definitely defeat us, and any effort spent on trying to get to Mount Doom will be wasted, and may cost us the chance to defeat Sauron a different way. Given that, Frodo, can you destroy it by Friday?"

Of course, in most shops Gandalf will keep all of that to himself because he hopes that Frodo can get it done sooner (it's just walking, after all) and he doesn't want Frodo to half-ass it, take his time, and not deliver until the last minute. So he'll just ask Frodo when it can be done.

"it's just walking, after all"

I read that in the common dismissive tone that I hear regularly and cringed. I'm not sure it was your intent but when higher-ups try to ascertain the level of complexity/work with little to no knowledge of the problem, these sentences fly.

Having been one of those managers, I understand that they're largely trying to be optimistic and justify their own demands but as a project drags on, it depresses the hell out of me.

You read it exactly right. I've had project managers tell me, in that same tone, that they disagreed with my six month estimate for a project, and said they could do it in a weekend. I tried offering to swap jobs for a while, but they never went for that. I'm not surprised; more often than not I wasn't just the tech lead and architect on my projects, but I did most of the project management too.

> I have stopped giving time estimates except for very small projects. I take 50% upfront

50% of what?

the dough

I think his point is that without a time estimate, you don't know how long it is going to take and thus if you are charging hourly, you don't know what the 100% is that you're taking 50% of. This obviously doesn't matter if you are charging flat rate.

Right. Except that I'd submit that it matters even more when charging a flat rate, as you're bearing all the risk of an underestimate.

I solve this by quoting a price between $xx and $xx, taking 50% of the smaller amount and then if the job takes longer than I estimated I have some room to charge more at the end.

How do you come up with the range?

How do you know how much risk you're taking on that the upper end of your range is not seriously under estimated?

I've just learnt through experience. There is obviously still some risk involved but it's reduced. When I'm working on projects that are similar to ones I've worked on before I use a smaller price range and if I'm working on something totally new to me I will use a larger price range to keep the risk as minimal as I can.

That's an interesting approach, but in fact your range is a time estimate, so it's not quite true that you've stopped doing time estimates, it's just you've stopped telling the cusetomer exactly what they are.

Reply on news.ycombinator.com