> Saying "I don't know" when asked "How long will it take" or "When will it be done"

~5 years experience speaking: How do you do this?

I have a very good boss and he knows things, objectively, like "estimates are very squishy," and "developers suck at estimating time" etc. But he still demands time estimates to give clients.

Our clients are often agencies, and they get it as well.

I do estimates like "10-40 hours, depending on XYZ (things I don't know)" sometimes and it doesn't really raise any eyebrows. That may as well say "I don't know."

Are you better than this? Do you just outright refuse or do you have some way you handle it?

> How do you do this?

Give half-order-of-magnitude estimates as confidence intervals. Avoid using "hours" or "days" as estimates. Story points work really well here.

Be extra clear on priorities and burndowns to make it clear that you're not just blowing them off. Give short but frequent demos (not just reports) of progress. If later they're concerned about progress, you can point back to all the times you reviewed the product, touched base about priorities, and agreed on next steps.

Make risk really clear to them. If the project is 'get it done in three months or bust', then the payoff (ten times the principal?) better be high enough to account for the risk (30%? 50%? 70%) that you won't make it on time and on budget. That is, you don't want to wait until failure to discover a bad business plan.

At the end of the day, you need to be willing to be patient with and/or walk away from 'business people' that can't wrap their heads around the fact that 20% profit on a venture with a 50% failure rate is a bad business plan. Making employees stressed or overworked to compensate is not a humane solution to the problem. To that end, don't work crazy hours to meet a deadline. That is bad for you, bad for your team, and bad for management since it enables dysfunctional planning.

> Give half-order-of-magnitude estimates

My current boss likes to ask "is it a day, a week, a month, or a year" and while sometimes I just want to say "yes, it's one of those" I actually think that's a pretty reasonable way to ask the question.

I heard a saying once, "Deadlines slip by the units they're measured in." If you say three weeks, it will slip by weeks, not days or months. If the estimate is months, etc.

Could you go more into detail how these story points would work. It seems like in the end a story point would always be associated with a number of days (or hours).

I measure effort, complexity, risk, and dependencies all with one number. If you don't

Things that affect story point values for me. Note that some are more about quantifying "risk" than "how long will it take?".

- how "big" is the change?

- how many parts will be changed?

- are the exit criteria vague or open to interpretation?

- is the change easy to test?

- do we have sample inputs and outputs?

- will we have to design for a tricky deployment?

- will we have to design for a tricky rollback?

- will it be hard to peer review?

- if this feature is impossible or more expensive than we thought, will we know early or late?

- is any of the code being changed extra finicky?

- do I need lots of help? code from other teams? approvals? new software installed? new hardware?

- can I iterate on this code? or does it really need to be perfect the first time?

- will we have developer 'concurrency' or 'parallelism' issues? can anyone chip in and help whenever? or is one distracted expert the only one that can do this?

...for me it's an intuitive guess at a number that flattens all that into something we can use to prioritize work and decide that work needs to be broken down more. What exactly is on that list will vary, certainly, but I would put on anything that could cause bugs, make you wait, or make you underestimate a task.

I'll often say something like "I don't know off the top of my head, but if you want I can get back to you with an estimate."

Once it's clear that I'm going to spend some non-trivial amount of time working on the estimate, the answer is often, "No, don't bother."

On the other hand, if person asking does want me to get back to them, I now have the time to do a good estimate—research the problem, break down the parts of the solution, think about the unknowns. Even a "good" estimate is still squishy, but it does tend to be based on explicit assumptions, and often flushes out hidden design or spec issues.

Spend time to fully estimate each task in each feature point in hours and double it of course. Now increase the unit of time by one: 3 hours = 6 days, 2 days = 4 weeks, 4 weeks = 8 months.

I have a rule. If I trust the PM, I always give my best estimation and a level of confidence on this estimation with the risks. Like:

- I think it will take a week, but this part looks a bit complex, so we may have delays.

- Or, I did something similar last month, so I am quite sure that will take 3 days.

A good PM will know how to deal with this information and what to expect.

If I don't trust the PM, I just add massive paddings.

As a PM, of course, I know this padding is happening and generally will add my own:

You know in your mind it will take you 3 days

You give me, your PM, an estimate of 2 weeks

I report up the chain that it will take a month

When it's all said and done, you end up getting it done in a month by the skin of your teeth :-)

But my point is that if there is a relation of trust between the PM and the developers, padding is unnecessary.

I had PMs to who I could give optimistic estimations and risks. That way, the PM could plan the different scenarios (like extra features in case we had spare time).

Other PMs, the ones who converted estimations into deadlines, got lots of padding. And the problem of adding padding is that it is time lost, because a developer who adds padding cannot tell that they finished earlier.

> How do you do this?

I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of...).

Often times managers demand an estimate from you, not because they need the job urgently done, but just so that they can hold you accountable to something. If you promise something, they can assume that you will give your best to keep that deadline.

One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly.

Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.

The idea behind estimates is to get you to think about the scope the work that is to be done. Quickly walk yourself through the process, give a SWAG, do your best to track your time spent on the task, then review what you got right and wrong in your estimate. It's less about giving the exact time required (in theory - some managers will never understand that) and more about estimating if you have time to complete X, Y and Z.

SWAG means what in your example?

Silly Wild Ass Guess

In most places "I don't know" doesn't have much effect. Just means the estimate comes from somewhere else. Another developer, or a PM.

People are just trying to make decisions about spending money, keeping clients informed, etc.

There are some research and moon shot type exceptions. But, for the most part, estimates are a necessary evil.

One thing I do way less in my 40s is over engineer a solution, or worry about all possible someday maybe use cases of a class many Java developers seem to like to design for.

can you justify the 3-5x difference in annual compensation that younger developer makes

can you justify the 2-3x difference between you and a guy who was been coding for 5-7 years ?

3-5X? What country is this? Typically in Silicon Valley there's a rapid rise in the first 5-7 years and then it gets pretty flat (say, 1.1X or 1.2X not 2-3X) unless you're actually taking on a bigger role (and thus getting paid for those responsibilities rather than "experience" per se).

When you look at it from a company cost perspective, the ratios get even smaller. The fixed costs (desk, power, healthcare, etc) are pretty much the same no matter the experience level of the engineer.

At Microsoft, annual compensation for entry level hire is around 130k (W2 box #2) where as for the principal engineer that figure is atleast 350k

So less than 3x compared to entry level, probably less than 2x compared to someone with 5-7 years.

Principal isn't a level most people reach, and has better salary.

Jesus. When I started in '06, my total comp was 82k. My last year, 2010, my total comp was $115k. I managed to be both too late and too early to that party.

Principal is not normal.

Exactly. I actually left software development after about 15 years. I think my salary progression was pretty typical:

First 5 years = ridiculous year over year growth, including getting raises without having to change jobs!

Next 5 years = slow growth, generally have to change jobs in order to get a raise.

Next 5 years = flatline, cost of living increases only, IF THAT.

I don't know any other professional field that plateaus this quickly.

Yes and yes.

If I compare myself against when I just started, I'm easily 10x more valuable now (in some cases 100x). And I would still choose my current self over 5 copies of myself at 5-7 years of experience.

Maybe if you have a simple problem, like a CRUD application or a simple website, it wouldn't matter much. But for harder problems there is no contest.

This. Most development is CRUD and is trivial. Write a DSS and/or automation system that is bulletproof and saves millions and it's significantly more difficult. The difference between using something like Biztalk and writing something like Biztalk is orders of magnitude more difficult.

If you are using someone else's framework for the majority of what your application does, that's not really software development. I know many people won't like hearing that.

Wait a minute, are those multipliers real?

46 - also still coding. I could not agree more! :)

Also, knowing why the points in your list are significant and advantageous.

> Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice

Could you please specify examples of proper software for this purpose (communicating product/feature requirements is meant here I suppose)? Do you mean reqs must go through the issue tracker or official original spec document?

I'm referring to using a ticket system like Jira/Assembla/Pivotal Tracker/Trello etc...

Lol for a second I thought you meant something like Rational RequisitePro...

On my 40's, a bit younger than you, I agree with every point.

I feel similarly as far as being on a whole other level now. I'm 40 and semi-retired. I spend far more time coding per day than I did at the peak of my career in the industry. And compared to myself back then... I don't even know how to make the comparison. The concepts and systems I play with every day now wouldn't have been anywhere in sight for me then.

Junior here. What does "map associations" mean in this context?

I was referring to the best way to model associations on client/server code and how that maps to the database schema. For some reason, I find that younger devs want to invent a new way to do relationships every time they have to implement a new one.

Nice. You should definitely write an article.