HN Books @HNBooksMonth

"Estimates are non-negotiable." - https://www.amazon.com/Software-Estimation-Demystifying-Deve...

I am really surprised no one has mentioned that a whole book devoted to this topic has existed for 15 years: https://www.amazon.com/Software-Estimation-Demystifying-Deve...

It's by Steve McConnell (also author of Code Complete) and largely covers what this author does (but more, and in more detail). I have found it consistently one of the more useful books in my library - particularly for its emphasis on error bounds and on how bad people are at estimating confidence intervals...

I remember going to a conference in the 1980s (MacHack), and attending a "Software Project Estimation" workshop.

The guy basically listed excuses for padding the estimate.

Steve McConnell wrote a book about it, using a much more rigorous scientific methodology[0]. He has also written some other stuff about it[1].

This one is really the big one:

"9. Both estimation and control are needed to achieve predictability. "

In my experience, we can accurately estimate software projects that have iron-fisted control. No deviation from the plan. If we use quality-first techniques, like TDD, we can do a fairly good job of hitting targets.

Also in my experience, this results in software that no one wants to use. It doesn't crash, ticks off the punchlist, and basically sucks.

I avoid estimates like the plague (a rare luxury, but I can do it). I like to "wander down the garden path, and see what sights there are," so to speak. I call it "paving the bare spots."[2]

It results in software that comes very close to the user/stakeholder "sweet spot," with great quality. It also tends to come together fairly quickly, and allows for excellent early project visibility.

But that won't work, beyond a fairly humble scope.

[0] https://www.amazon.com/Software-Estimation-Demystifying-Deve...

[1] https://stevemcconnell.com/17-theses-software-estimation/

[2] https://littlegreenviper.com/miscellany/the-road-most-travel...

Read

https://www.amazon.com/Software-Estimation-Demystifying-Deve...

and

https://www.amazon.com/Rapid-Development-Taming-Software-Sch...

Also think: if the business does project A, how much money does that make for us or save for us? From a developer standpoint I have gotten the business people to tell me a value that is a fraction of the cost of the product. You fold that one and free up resources for project B which is the other way around.

This is better than not breaking it down, but it's still not very good. McConnell advocates this approach strongly in his book on software estimation[1], and I've seen it work to some extent. It works for reasonably repeatable projects that are very similar to earlier projects you have experience with. But when we get into seriously non-trivial projects that are more "R" than "D"... well, it just isn't enough.

The problem is that on a non-trivial project, these breakdowns are guesses which carry considerable uncertainty. And the less you know, the more the unknown-unknowns get you. If you write a detailed breakdown of a major piece of software before writing a line of code, at the end of the project you will look back and laugh and laugh at your own innocence.

As just one random top-of-mind example, consider Carmack writing Doom's rendering engine[2]. He tried several approaches that didn't work before striking the right balance with pre-computed BSPs. Some of the things he tried were fundamentally good ideas and would later be used for different games - but didn't work on the hardware of the times. How do you estimate something like that? "I'm going to spend a month on my first approach. That could be one month or two. If that doesn't work, (50% chance), I'll read research papers and textbooks (1 week - 3 months) until I find a promising technique. Then I try the most promising of these; since this is an approach I haven't even read about yet, it could be one week to implement, or six months. And there's some chance that will fail to and I'll have to do it again." The final estimate is anywhere from one month to a year. You just can't know.

[1]: https://www.amazon.com/Software-Estimation-Demystifying-Deve...

[2]: https://twobithistory.org/2019/11/06/doom-bsp.html

⬐ Scarblac

I have that now in a project. I have two things that need t o be made where I just don't know if I'm going to get them to work well within the larger design I have in mind. I wanted to prototype them in the summer but the backend wasn't ready so I only had very small mock data served in an unrealistic way.

The only thing I can do is move them to the front of the project as much as possible, so we have the risky bits as early as possible. Once we get them to work the rest should be smooth sailing, but I'd rather fail when that time wasn't spent yet. PM agrees.

⬐ meh2frdf

That’s why you do a time boxed spike, ie a fixed amount of time to do the investigation so you can work out your preferred approach. After you have sufficient knowledge then you can estimate.

It's not exactly fair.. and also not likely without extensive time spent doing the estimation, like sure - you can be more precise, but the more precise you need to be, the longer it takes you to frame the estimate.

Two books help with methods of doing this.

Rapid Development: Taming Wild Software Schedules: https://www.amazon.com/Rapid-Development-Taming-Software-Sch...

Software Estimation: Demystifying the Black Art https://www.amazon.com/Software-Estimation-Demystifying-Deve...

This likely does mean you'll need to be allowed to deploy automated test cases, develop documentation and the entire nine yards, because it's going to be far harder to hit any reasonable deadline if you don't have a known development pipeline.

You'll need to reduce your uncertainty as much as you can to even have a chance - and even then, things will still blindside you and double (or more) the actual vs. the original estimate.

⬐ b0rsuk

We talked to him, and no. We won't be allowed.

⬐ fenier

Then take it up with his boss, fight him on it, or look for work elsewhere. It's unreasonable that you'd be adversely graded on something that industry has historically struggled with.

Estimation is often challenging and sometimes impossible, but there are in fact many opportunities to deliver reliable estimates.

If you'd genuinely like to learn more about estimating software projects and when you can do so more or less reliably, Steve McConnell's Software Estimation: Demystifying the Black Art provides a great survey of techniques.

https://www.amazon.com/Software-Estimation-Demystifying-Deve...

⬐ afarrell

I bought that book about 4 years ago in an attempt to try to learn how to produce estimates for the sorts of tasks I might do in a given day as a software developer. I read through the first third of it and then skimmed the rest. Unless my memory has wildly deceived me, that book doesn't contain advice on how to do so. Rather, it assumes you know how to estimate ticket-level work and talks about how to estimate on the scale of months or quarters.

https://www.amazon.com/Rapid-Development-Taming-Software-Sch...

https://www.amazon.com/Software-Estimation-Demystifying-Deve...

⬐ newman8r

this is exactly the type of material I was looking for, thanks

@otoolep Have you read Steve McConnell's "Software Estimation: Demystifying the Black Art"

http://amazon.com/Software-Estimation-Demystifying-Developer...

(if yes, then why isn't it on your list!?)

⬐ otoolep

Haven't read it. Good?

I've found that https://www.amazon.com/Software-Estimation-Demystifying-Deve... is a fantastic resource for improving estimation.

Regardless of project/planning methodology, having a ever-growing checklist of less-obvious estimation items is a simple way to avoid forgetting to consider them. The book "Software Estimation: Demystifying the Black Art" [1] by Steve McConnell contains a number of these.

Some examples:

  - Team or company meetings
  - Team member sick days, holidays, vacations
  - Bugs in third party software
  - Maintenance of previous systems
  - Maintenance of build automation
  - Demos
  - Interviews
  - ...

... or your own list of whatever other items you have historically forgotten, or tend to forget when estimating.

In the painting example, the moving of the furniture was something I overlooked, despite having made the effort to carefully think of all tasks. A estimation checklist built up from previous painting projects could have triggered me to consider this task.

[1] http://www.amazon.com/Software-Estimation-Demystifying-Devel...

Get these two

http://www.amazon.com/Rapid-Development-Taming-Software-Sche...

and

http://www.amazon.com/Software-Estimation-Demystifying-Devel...

If you want to get deeper into project management I suggest that you become a member of the PMI and possibly get certification from them. The training and testing are rigorous and it is a certification that means something both from the knowledge you get and the benefit of having it on your resume.

⬐ narrowrail

The OP discusses Product Management, which usually falls in the Marketing Dept. (at most corporations I've been and heard of), while you are suggesting project management and engineering management books. I'm not sure that makes sense; and, being at a startup I'm not sure certification of any kind would be worth the time.

You bring up a specific challenge, how to handle it when you realize a deadline is probably going to be missed. That's one aspect, but you also need to look at why your deadline is going to be missed more broadly.

Here are some challenges that come to mind in software estimation:

1. Estimates are almost always done too quickly, with too little information. If you can wait, spend more time, or reduce the unknowns, do so. If nothing else give it an extra fifteen minutes. If you can say "I'll get back to you with an estimate by ..." (e.g. tomorrow or end of day) that's even better.

2. Estimates are ranges, a probability that the work will be done across a range of time. but are often given as a specific date or amount (e.g. "It will be done tuesday/take 5 working days"). Early or quick estimates may be ranges of 15x or more (e,g, "it will be eight hours to three full work weeks"). Don't be afraid to capture that ambiguity in a range. Others may not understand ranges, so give them the high end if needed, but at least be aware that ranges exist. Often ranges, or high estimates get push back. This is your opportunity to specify what questions need answers, what requirements need refined, and what areas need more design and architecture to reduce ambiguity. These things can reduce ranges of estimates.

3. Know the difference between estimates, targets, goals, and commitments. Confusion between these leads to miscommunication and frustration. Often we'll make a guess like "maybe two weeks" which is a wild instant estimate, and others will see how nicely that lines up with their target date, and believe you have committed to that goal. Commitments should be explicit, and part of your process.

4. Do not negotiate estimates. Managers are trained to negotiate, and a naive manager will almost always reduce estimates through negotiation, which is a distortion of reality. Developers should collect the information they need about the requirements, ask questions, then produce their estimate in isolation, and refuse to change it. The way to change an estimate is to change the requirements, often addressing ambiguity and questions, and re-estimate the work given the new information. This is hard to do, because a "better" timeline can make everyone feel better in the moment, but will lead to problems later.

5. Renegotiate when change happens, or when you are in danger of failing a commitment. This one answers half of the original question, to my mind. If you didn't make a clear commitment, or requirements are changing with out any renegotiation, you have to fix those first. After that, keep a close eye on scope creep, and changes. Change happens, accept that, but make sure that those you have commitments to understand that change has impact on your commitments, and you can either commit to the original work and timeline, or you can commit to the new work, and a new timeline. Holding you to new work on an original timeline is not fair to you, and not a problem to be solved at the developer level. This one can be quite challenging, some people use "change management", itemized / ticket based change requests, even explicit signoffs. If you have trouble here, find what works for you.

6. Learn from history. You won't get it right. A lot. Keep track of how you are doing, improve processes and spend more time refining requirements/acceptance criteria etc. Make sure commitments are negotiated and explicitly agreed to. Keep learning.

7. You will make mistakes. If you uncover new questions, requirements, found work, it was in a certain sense an estimating error, but it has a different fix. If you had a reasonable view of the work to a fair level of detail and spent reasonable time on the estimate, and are still missing your commitment, you have made a mistake. That's OK, especially early on, or in new areas for you, if a team has shifted etc. The answer is, communicate. Let your manager know immediately, as soon as you realize it, that you feel you are at risk of failing a commitment, and you need to revisit. From there, you can investigate the new work, or re-estimate based on your increased understanding of the problem. Perhaps note some data for your historical tracking. Learn. Next time, make a better estimate. It does feel bad to miss a commitment, or even to not make a deadline that someone else set up. That's very human. The way to feel better about it, is to get better at it.

The above is based on my decade of experience as a software developer, and a solid foundation from Software Estimation: Demystifying the Black Art, By Steve McConnell http://www.amazon.com/Software-Estimation-Demystifying-Devel...

I highly recommend the book as a learning resource, and having the whole team, managers included, read at least the first portions of it. It also has specific tools for various estimating challenges.

This McConnell book[1] is a must read on the subject. Generally developers just fail at estimating at a fine grained enough level and forget about all the ancillary tasks that take up a majority of a project's time.

[1] http://www.amazon.com/gp/aw/d/0735605351

Terminology nitpick: this article is not about planning, it's about estimation.

Estimates, plans and commitments are three different things (see http://www.amazon.com/Software-Estimation-Demystifying-Pract..., which is the best book I've read on the subject).

The problem with estimation in many cases is that people who dictate requirements often dictate commitments as well, and do so without estimation-based feedback. In other words: "Your ten-week 'estimate' isn't acceptable; we have to have this done in seven!"

⬐ ColinDabritz

Another interesting division, from Software Estimation by McConnell is Estimates vs Targets vs Commitments. You could add "Goals" and "Plans" to that perhaps.

⬐ zawaideh

In this example I would say commitments are getting in the way rather than the estimates, and the overall plan gets messed up.

The way I see it, good estimates are simply a prerequisite to good planning, so they tie in together.

http://www.amazon.com/Software-Estimation-Demystifying-Pract... is fantastic for giving many approaches to the topic, and counseling for non-technical stakeholders where it isn't a negotiation, but math.

Reminds me of a great Steve McConnell book, Software Estimation: Demystifying the Black Art. http://www.amazon.com/gp/aw/d/0735605351/ref=redir_mdp_mobil...

⬐ jacques_chester

I agree with this recommendation. McConnell has done his usual trick of distilling lots of material into a concise, readable account.

⬐ None

None

As usual, Steve McConnell has done the hard yards of turning literature and research into something readable and instantly applicable.

http://www.amazon.com/Software-Estimation-Demystifying-Pract...

Every time I estimate for clients I always talk about the Cone of Uncertainty.

⬐ jwhite

Thanks!

⬐ reedlaw

This is why I agree with the original article over these comment parents. I work in a small software agency for clients who would never grasp the Cone of Uncertainty. They are much closer to the pointy-haired boss type than the type of person who appreciates the finer points of software project estimation. While reading the literature is good, the average developer will seldom find the time to do so. And even if they do, an off-the-cuff estimate is often better than carefully planned specification documents that no business stakeholders will ever read.

Of course accurate estimates have tremendous business value. But in reality they often come at the expense of what the client really needs which is delivery of features. I have seen estimation and tight project control taking up substantially more time than delivering actual features. And it was exactly as the OP stated:

> Software projects that require tight cost control are the ones delivering little or no marginal value.

The lesser the project value the tighter the control leading to a vicious cycle of developers cutting corners and increased micro-management.

⬐ jacques_chester

> I have seen estimation and tight project control taking up substantially more time than delivering actual features.

It sounds to me that what you saw was a conflation of estimates and plans. Which is a common error.

⬐ reedlaw

Clients sometimes want an estimate of how long a single feature or fix will take, even when it will take only 15 minutes. The communication overhead and time spent estimating easily outweigh the time to implement.

⬐ jacques_chester

I'm ... not sure what this proves?

⬐ reedlaw

Nothing, just an explanation of what I meant by estimate.

He's sometimes right. There are lots of good reasons why you might need software schedule estimation. When you do, there is no point in throwing up your hands and saying, "You can't do that, everybody knows it." Instead get http://www.amazon.com/Software-Estimation-Demystifying-Pract... and teach yourself how to do it.

Why would software estimation matter? For many companies it matters a lot if you can announce something in time for Christmas. Or you might have to hit a deadline for compliance with a legal contract. Or you may be trying to prioritize two different possible products - without a sense of the effort involved you're lacking one of the parameters you need for such an estimation.

That doesn't mean that you always estimate. If the value proposition is clear enough, you're going to work on it until you're done and then you will be very happy. But the real world does not usually work like that.

⬐ gadders

I wonder what would happen if the rest of the world took this approach?

Customer: I was thinking of getting an extension built on my house

Builder: OK

Customer: How long would it take and what would it cost?

Builder; Sorry, but to tell you that would slow down the process of building your extension. It will be quicker if I just get on with it and tell you what you owe me at the end.

⬐ foobar99

What would happen? The customer would know beforehand what is true, anyway.

Berlin Brandenburg Airport was estimated to be opened in October 2011, then 2012, and currently 2013. Costs were estimated with 630 million. The current estimate is 1.2 billion.

Not giving an estimate isn't the entire solution, either.

The problem with an airport is that every time a deadline arrives, all you can do is notice that you don't have an airport, yet. You must estimate again (and you're wrong again).

With software you can say: "We're going to give you a shippable version every week. You can cancel the project at any time and you keep what you've paid for so far. We can screw up completely and you still have last week's shippable product."

Personally, I'd love that pay-as-you-go approach for the rest of the world.

⬐ MattRogish

"For many companies it matters a lot if you can announce something in time for Christmas."

It will be done by xmas or it won't. I don't recommend "no estimation", but intense estimating won't make you hit xmas. Not estimating may give you several weeks that you could be coding.

Either way you're takin a mighty big risk when you publicly commit to that. Welcome to hell, population: Dev Team. I've known of no major software project that has a public date that hasn't resulted in major delays, feature cuts, or massive overtime to try and hit that date.

"Or you might have to hit a deadline for compliance with a legal contract."

That is also a suitably terrible position to be in. I recommend you don't take such contracts. Again, your estimates will be wrong. Even if you spend months doing them. Then you're in the same spot.

"Or you may be trying to prioritize two different possible products - without a sense of the effort involved you're lacking one of the parameters you need for such an estimation."

Which delivers most business value? I find it farfetched that both are of equal importance.

⬐ btilly

Estimating may be a way to figure out what is plausible to do by Christmas. Which may help you scale your desires up or down to have the best deliverable product that you can.

Also in any contract negotiations, someone has to take the risk. The more risk you take, usually the higher margins you can get. (I am currently working on a contract where my willingness to take on all of the risk of not delivering value has improved my likely profit margins 10-fold.) Thus if you're willing to do fixed schedule and/or fixed price contracts, on average you can charge more. But it would be insane to attempt that without being able to estimate your likely costs and schedules.

Sure, that estimation is an intrinsically hard problem. That is why you get to charge extra for having done it. But it is not trivially the wrong business decision to make.

As an extreme example, I offer you SpaceX. Which signs lots of fixed price bids on development tasks that make the average software project look like a cakewalk.

⬐ swalkergibson

How does this apply in an agency context? I would like to see if this can be applied to my company, but I am a little fuzzy on how this theory can work with paying customers who want to get an idea of cost up front.

⬐ Someone

"your estimates will be wrong. Even if you spend months doing them. Then you're in the same spot"

If you spend months doing estimates you will never do "nothing else". At the very least, you will have a much learnt a lot about the problem domain, and thus you will have a better overview of the work to do. You likely also will have discovered a few pitfalls to avoid, and you already will have changed the requirements of the project at the moment when it is cheapest: before you have a pile of code.

⬐ gadders

The FSA (and other regulatory organisations) frequently give a set date when a feature (EG Souped up trade reporting or similar) needs to be in place by.

⬐ jt2190

> It will be done by xmas or it won't.

You claim to be talking about estimation, but I believe that you're actually talking about being given unrealistic, non-negotiable deadlines. (How did we know that the estimate was unrealistic, you ask? We did an estimate.)

⬐ squirrel

I have just moved from B2B, where many "deadlines" were largely artificial and driven by sales targets rather than real business need, to online retail, where the deadline is often concrete, immovable, and external (trade show, Olympics, Christmas). In both environments I found it most useful to encourage my team to commit to completion of _the best solution they can manage_ by a business-meaningful date (picked by the team after suitable consideration, of course). In this model the team do not agree to a specific solution or scope, though to pick the target date at the beginning they usually have an initial solution in mind; as they work toward the date, they (working with the customer representatives in the team) have the freedom to cut features or components, or to add new ones, as they grow in their understanding of the feature and the limitations on delivery (legacy code, lack of experience, unclear business needs). I have generally found that in an environment where development teams are trusted (yes I know such environments are far too rare) this produces results that are as good or better than the recipients expected, and almost always on time or nearly so.

⬐ Domenic_S

driven by sales targets rather than real business need

If you're in the business of selling software, sales targets are a real business need.

⬐ squirrel

I should have said "sales quotas" rather than targets. Your target to sell £x million in June reflects a real revenue need for the business, but the deadline of 30 June this implies is artificial, and the business would (in most cases) do just as well if you delivered the feature and took the revenue on 1st or 10th July.

⬐ btilly

Features, budget, schedule. The development team has to have control of one of those three.

Generally schedule is fixed by external factors. Budget is fixed by the existing team size times the schedule. Therefore the corner that makes the most sense for the development team to control is features.

A big part of the problem is that management often isn't interested in honest estimates.

You can certainly find better practices in some organizations, but in many organizations, a certain team gets tasked with completing a certain assignment by an arbitrary deadline and no attempt is made to reconcile the triple constraints with reality.

In a context like that, developers may not be asked to make estimates, and if they do make estimates they don't believe that they'll be taken seriously. So they never develop the chance to learn how to estimate.

The accuracy of estimation also depends on the context.

If, for some reason, I had to fix a difficult-to-reproduce bug in a large system written in COBOL that runs on a mainframe, I'd have very little idea of how long it would take me to learn COBOL, understand the codebase, figure out the tools, and track the problem down. A COBOL jock would obviously do better.

On the other hand, I've worked on greenfield well-specified business CRUD apps based on a correctly aligned framework where I could estimate that something would take 21.25 hours and I'd really get it done in 19.75 or 22.50.

I've met developers who will absolutely refuse to estimate anything but I think more often developers don't believe their estimates will be listened to.

The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast. See the classic book

http://www.amazon.com/Software-Estimation-Demystifying-Pract...

⬐ Natsu

> The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast. See the classic book

It's not hard to learn to make reasonable estimates. Even for unknown problems, I can often say that X has usually taken about Y time in the past and be right most of the time.

The real problem comes when the estimate you give is not the one management wants to hear.

⬐ redthrowaway

Or when you're tasked to do something you've never done before, and your initial thoughts of "I bet y is like x" turn out to be terribly wrong.

Something so seemingly trivial as a different API can make two similar tasks take vastly different amounts of time, especially if you're approaching the second problem with the mindset induced by the first API.

⬐ kragen

> The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast.

To an extent, though, the better you are at programming, the worse you'll be at estimating.

A bad programmer, given a one-week task similar to one he's done before (when it took him two and a half weeks), will estimate it at two weeks and do it in two weeks, plus or minus a bit.

A good programmer given the same task will try to apply the previous solution, or use a library that solves the problem, and usually get it done in two to four hours. But some of the time that won't work, and then they will spend three days doing what would have taken the bad programmer two weeks, and a fourth day generalizing it so that when they have to do a similar task the third time, they can do it in two to four hours.

The good programmer's estimate will, therefore, frequently be off by a factor of ten or more.

In short, the better you are at automating what you've previously done, the more time you spend doing things you haven't done before, and so the more uncertain your estimates are.

The central limit theorem says that if you add up enough independent random variables from whatever distribution, their sum will eventually start to look like a Gaussian normal distribution. Unfortunately, this isn't as useful as you might think for software project estimation, both because different tasks aren't independent and because when the underlying distribution is heavy-tailed (e.g. lognormal, exponential, etc.) "enough variables" can be much larger than the number of tasks in your project: in the hundreds or thousands.

I prefer to take my advice from someone who has demonstrated the ability to repeatedly run projects and estimate them in advance to surprisingly high accuracy. I therefore recommend Software Estimation by Steve McConnell, available at http://www.amazon.com/Software-Estimation-Demystifying-Pract....

⬐ None

None

⬐ ashleymoran

btilly, thanks for the reference to this. I've added it to my Goodreads list.

⬐ netghost

If you like Steve McConnell's work, you should take a look at http://www.LiquidPlanner.com, we built our entire product around the notion of ranged estimation so that your schedule actually captures some of uncertainty involved in estimation.

Also if anyone wants some more good books to read we have a list of some of our favorite project management books at http://www.liquidplanner.com/recommended-reading.

Check out (non-aff link) http://www.amazon.com/Software-Estimation-Demystifying-Pract...

It's a good summary on a several techniques, how to apply them, and how to pick how in depth of a one to do, as well as how to talk with people who try to negotiate with them.

Here's what I use and recommend:

* Mike Cohn resources were the most helpful to me:

- free presentations around estimating and planning (eg: http://www.mountaingoatsoftware.com/presentations/131-agile-... and others on the same site)

- the "Agile Estimating and Planning" book (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp...)

- Mike Cohn "Agile Estimating and Planning" course (2 days) was worth taking

* Software estimation: demystifying the black art (http://www.amazon.com/Software-Estimation-Demystifying-Pract...) is a very useful book too

* For lightweight project management tool: I use a mixture of Acunote (for estimating and burndown chart - I even generate my quotes out of it using Ruby and Prawn) and Freckle to monitor the time spent.

I tried many other tools (including Mingle, Pivotal, etc...) but Acunote is the only one that works well for us.

Steve McConnell, in his book "Software Estimation: Demystifying the Black Art" [1] gives this advice (paraphrased):

Never give off-the-cuff estimates, no matter who is asking.

Bosses and project managers tend to hold you to those estimates regardless of the caveats you give. Also, of course, an off-the-cuff estimate is very likely to be more wrong than a detailed estimate.

Here's why this is relevant to the OP: by withholding your estimate until you've had a chance to give it enough thought, you relieve the social pressure that is created in the moment by the project manager or boss who is saying, "we must have it and it must be easy, can you do it today?" Just say, "let me get back to you," and follow up with a reasonable compromise that is healthy for the project and meets the business goal.

Never give off-the-cuff estimates, no matter who is asking.

[1] http://www.amazon.com/Software-Estimation-Demystifying-Pract...

I don't multiply by 6, instead I use various techniques that works quite well:

- http://www.mountaingoatsoftware.com/books/1-agile-estimating... (with free chapters; also read the various presentations on the site)

- http://www.amazon.com/Software-Estimation-Demystifying-Pract...

One key point is to really understand what is risky in terms of estimating (either technically or politically or because it's too vague).

At some point, you can really become accurate as long as the scope is well understood.

In my case, the Fred Brooks technique does not apply: my last customer iteration was 70% infrastructure, 20% code, 10% pm. The one before was 70% code, 10% infrastructure, 10% documentation, 10% pm.

I went to a school (Georgia Tech) where the CS degree is made up of a core and several specializations which actually let you have a huge swath of classes relevant to what you want to do. I had only 2 "math type" CS courses (within the college, I additionally had Combinatorics and "Calculus 3 for CS" which was basically matrix math methods, but they we taught by the actual math department).

I do think this approach where there are lots of specialties (Software Engineering, Game Prgramming, Systems Programming, etc) allows people to get experience and training relevant to where they're going in life.

All that said: I really really really want to see realistic mentored debugging go on in a CS program. I want to see 2 students and one experienced adult, sit down and learn next to someone the ins and out of all the modern debugging techniques (debuggers, binary search, profilers, memory leak detectors, etc). None of the classes had anything like that, and that was the biggest thing missing that comes to mind.

The second biggest thing is realistic estimation methods! Until I read a book on it and practiced a lot, I was horrible at it. Very little was taught on actual methods to make useful estimations.

(Here is a non-aff link to the book who's material I'd like to see covered in a college CS curriculum): http://www.amazon.com/Software-Estimation-Demystifying-Pract...

The skill you're looking for here is called meta-knowledge. It is knowledge of your level of knowledge about a given topic.

It is a teachable trait, arguably what very selective schools with hard grading curves teaching difficult things teach people to develop (as you have to determine what you don't know to pass/excel/etc there).

I've always personally believed the test: "What would you need to get going on these 5 projects?" Is a great question. If talking about researching X Y or Z don't come out of the candidate's mouth (and it's not an old solved problem, like self-contained embedded C code), you mark them down as less meta-knowledgeable. (Doesn't mean unhireable, but you don't want them in highly independent positions or constantly learning new things; people with low meta knowledge appear to actually be quite happy in places that high meta people hate, such as long term maintenance programming).

In software particularly, study of estimation (and it's continual use) can teach people the practice of evaluating all risks, including metaknowledge. I like the book: http://www.amazon.com/Software-Estimation-Demystifying-Pract... (non-aff link) for getting people going with the practice.

I found this book to be really helpful in learning different approaches to estimation at different points in the project.

http://www.amazon.com/Software-Estimation-Demystifying-Pract...