> 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.
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.
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.
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.
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.