> Don't estimate. They don't matter and nobody cares about them anyway.

Except for when potential clients ask your company: "How much implementing a system to do X would cost?"

If your company attempts to calculate this based on how many people would be needed to cover the scope and what the technical complexity of the implementation would be like, then you need to give an answer as a developer, so that the sales department can do some ballpark calculations and give a response to the clients. Especially when numerous other companies within the industry are also attempting to answer that same question.

The processes and methods vary, of course, some use historical data from other projects, some use methodologies like COCOMO, others don't even ask their technical people and try to squeeze as much money from these potential clients as possible, but in the end, someone somewhere cares about the total time the project could take, ahead of time.

It doesn't matter that it's almost impossible to give accurate estimates due to the nature of development (e.g. an everchanging environment with bunches of different technologies that evolve and die, as opposed to a production line of widgets) and it doesn't matter that these requirements are probably inaccurate, that they will change, that there will be scope creep and numerous other difficulties (various development decisions that will impact the project long term, many restrictions and requirements that are dependent on the environments that the clients have).

In the end, i dislike estimation, clients probably don't care about any of the above and want them anyways, which leads to the development methodologies remaining "agile" in name only and estimates end up being expressed in days rather than an abstract number representation of complexity when compared to other similar tasks in that particular project.

> Except for when potential clients ask your company: "How much would implementing a system to do X cost?"

And what do estimates provide here, that sales just picking a number doesn't? Estimates are made up numbers. They're estimates.

Also this line that you omitted answers your question more directly:

> If you're a sales driven/feature factory company, the estimates won't matter anyway as you'll demand to meet your obligations regardless of estimates.

> And what do estimates provide here, that sales just picking a number doesn't?

Example #1:

  - a company in the industry asks your company to implement $FOO, they want to know how much it'd cost
  - the sales people talk to the engineers, who come up with a certain amount of time it could take
  - the sales people turn this into a monetary figure of $X
  - a contract is made, the project proceeds to be developed, probably with some delays and overruns, but works in the end and is profitable

Example #2:

  - a different company in the industry asks your company to implement $BAR, they want to know how much it'd cost
  - the sales people decide that $BAR is similar enough to $FOO and that there's no need to consult the engineers, they just give a similar estimate
  - turns out that the project MUST be made for JavaEE, since that's what the company is using
  - turns out that the project MUST work on Java 8, since that's what the company is using
  - turns out that the project MUST use Oracle DB, which then requires licensing and particular setup for the environments
  - turns out that the project MUST use GlassFish and instructions must be written for it, because deployments will be done by the clients' Ops person
  - turns out that the project MUST be deployed as a .war file, because of the above
  - turns out that the project MUST work in RHEL 7 because that's what the clients are using, same situation as with Oracle
  - turns out that the project MUST have both a test coverage of >80% and integration tests, which weren't a consideration in the previous project
  - turns out that the project MUST support IE because for some reason that's what the employees of the client company are using
  - as a consequence, the technical implementation takes about 200-300% longer than previously estimated
  - the project is no longer profitable and is a net loss for the company

Example #3:

  - there's yet another company that asks for $BAZ, they want to know how much it'd cost
  - the sales people had a really bad time with that last project, so this time they decide to increase the estimate
  - turns out that this new project does not have any of those constraints
  - because of this, the estimate is really large
  - the company looks at this and decides to go with your competitor instead
  - your company loses out on the opportunity of working on the project entirely

In the example #1, the ballpark figures were accurate enough for the project to be done in a profitable manner. In example #2, there were factors that weren't considered and would result in either contractual penalties, the clients deciding to break the contract because you can't deliver on time, or to take you to court. In example #3, past data was used in an inaccurate way due to not being applicable to the constraints at hand (or lack thereof).

Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.

Some sales people work out how much the client is willing to pay, and that's the price. The deliverables are squeezed in to that price at a later date, by cutting corners if necessary - I think it's quite an effective way for companies to make money.

Make money? Sure.

Deliver working software? Perhaps.

Deliver quality software? Almost certainly not.

Now, whether people actually want quality software, given that its development would take a lot of time, is debatable. Many times being the first to market is good enough, though saying that leaves a sour taste in my mouth as an engineer.

> Of course, the above happens when you're in a market that requires estimates as a part of BOMs, which is a lot like bidding on projects and is just a race to the bottom for the most part.

Yeah this, to me, totally invalidated the rest of your example. Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all. It is not clear to me that any "estimation" changed this calculus at all.

> Pick a low number to win the bid, blow the timeline/estimate, require more money to do anything at all.

Except that there are penalty mechanisms in place to prevent this from happening.

So your company was slow to deliver the product and needs more time? You better be prepared to work for your own resources, otherwise the escrow won't get released, as per the contract.

Or perhaps you cannot finish it at all? Get ready to either not receive a large portion of the money at all, or to be sued outright. For an example, see here: https://www.consulting.us/news/2197/accenture-sued-for-32-mi...

Disclaimer: i have nothing to do with Accenture or consulting in the US, though consulting, government contracts etc. all share certain similarities and bureaucratic processes in most countries that don't always align with the realities of actually developing software.

If you can, steer clear of all of that and instead work for a technology oriented company that develops a product that they also sell themselves. One, in which the developers are viewed as a profit center, instead of a cog in a ROI generation machine. Ideally, an engineering led company.

Example #4

  A CTO of an American company, to get a bonus of $7 million, lays off a ton-load of the company’s CRM people who knew how 20 years of architecture duct tape that ran the company was strung together.

  CTO then proceeds to hire a cheap, offshoring body shop to design the company’s new website, which talks to the CRM. However, there’s no more CRM people at the American company because they’ve all gotten laid off and the offshore web contractors also now have to become customized CRM experts, which is insane scope creep.

  The outsourcing company can’t deliver and litigation is sought, while the US company takes zero responsibility for the fact that all the CRM people were let go and there’s no chance in hell that web developers at the outsourcing can ever learn the highly customized domain-specific logic that fast that extensively. Meanwhile, CTO gets fired and a severance of $1 million for all the extreme damage he did to the company.

And that’s Hertz vs Accenture, or at least how I heard it to be.

> Don't estimate. They don't matter and nobody cares about them anyway.

This only works for some projects. For example if your MVP or go/no go prototype costs $5MM (which a hardware or life science product easily could) you really need to know if it will be 5 or 10.

I ran a company which always quoted 3X fixed price what we thought the project would really cost, even if things turned out to go wrong. Typically we made the (promised) schedule, and when not (luckily didn’t happen too often) the customer would be able to tell pretty much as soon as we could tell, and together we dealt with it.

But as for the cost: most projects were extremely profitable but sometimes we would lose hundreds of thousands on them. That’s why we charged such a premium: we absorbed the financial risk (not that we ever told the customers our internal cost estimate — none of their business!)

Hardware and life science projects usually have more time to research and prepare than the hour of weekly estimation provided by silly agile orgs.

Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter?

As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.

> As I said, if you have $5MM, you'll get what you get for $5MM. If you want to spend a boatload of time researching, your estimate might be closer, but that research isn't free.

Knowing how far you'll get might affect what you prioritize, no?

> Also, how frequently do hardware and life science projects go far over budget and under scope? Do their estimates matter?

Most of the time, in my experience. At a bigger company that may not matter so much but at a startup it can be fatal.

When prioritizing, it's not always obvious which items are big vs small. How do you provide that feedback to PM during prioritization?

Sometimes implementing what should be a simple feature requires a month of refactoring some old technical debt. And sometimes what seems like a very complex feature is actually just a matter of enabling a flag on some third party component you're already using.

All is us have likely experienced "why is x taking so long?? Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

I think that last paragraph has a clue as to the problem and solution. Those questions all are assuming someone other than the devs are responsible for deciding things. If the devs are making those calls, they won't wonder why things are taking so long or what could have been simple. PMs should help act as an intermediary with the customer and convey that domain information to the devs but shouldn't have any real say over the roadmap or features as they don't have the knowledge or experience to make those calls.

> When prioritizing, it's not always obvious which items are big vs small.

Why does the size of the work that needs to get done matter? If you need it you need it. If you don't, you don't. If you want a fast fix, note it. Speak in outcomes. "The lowest amount of work possible to get us ________"

> All is us have likely experienced "why is x taking so long??

I wouldn't work with a PM that disrespected me like that.

> Had we known, we wouldn't have done it now!" and/or "we didn't realize y was so simple, otherwise we would have done it months ago and probably won a few more deals!" How do you avoid that?

This isn't prioritization, it's a PM making ill-informed judgements on dev work. Don't have your PMs do that. Product people can define priority, scope, etc. If your PM isn't prioritizing something because they think it takes a long time, they do not understand their role.

> Why does the size of the work that needs to get done matter? If you need it you need it.

Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract, and you could only apply for the contract until a specific date. The value of this feature outside this scope was pretty much zero.

> Generally, I would agree, but I've seen cases where it mattered, because the value of a feature would become 0 after a set date. For instance, we needed a specific feature to fulfill the requirements for a (massive) contract

As I said, you put it at the top of the backlog and alert the team of a new deadline. You work on it until the deadline. If you make it, great, if not, you move on. Asking for an estimate wouldn't have made you make it, it might've only prevented you from trying.

But not trying something very unlikely to succeed sounds valuable to me. Why waste 2 months of engineering time if your engineering team is convinced it will take at least 6 months?

> If you want to get _more_, ask a team what's making them slow and then prioritize fixing the things they bring up

Exactly, the answers might surprise you