5 ms·

> 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

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

void_mint 5y ago
> 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.
- KronisLV 5y ago
  > 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.

void_mint 5y ago

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

KronisLV 5y ago
> 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.