5 ms·

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

black_13 3y ago
[dead]
drittich 3y ago
Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.
- dagss 3y ago
  Did you look at sp_describe_first_result_set? https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-describe-first-result-set-transact-sql?view=sql-server-ver16 https://learn.microsoft.com/en-us/sql/relational-databases/s...
- tempodox 3y ago
  > Really, the first build IS the process of estimating. You hit the nail on the head.
- awinter-py 3y ago
  yes this difficult to scope some projects without starting the build
okaram 3y ago
I have found a sure way to get estimates... Do the work, and say how long it took me.
- joombaga 3y ago
  You should probably still add a week to the estimate.
eschneider 3y ago
It's realism, not cynicism. I've absolutely been in situations like that where the sensible estimate is 5X what management is angling for and I know it's the case because we've done that exact thing (In this case, new hardware bring up) many times and with the inevitable problems, it always takes the high number. :/
- john_the_writer 3y ago
  I worked at a place where everything had to be gold plated. Some devs had an idea for a json driven form. It was super simple. Less than a week of dev time. Management got it and an architect got involved. The project was taken from the original devs. The new team spent 2 months building a DSL, that didn't support mobile (so didn't meet the requirements). In the end it was canned. The original 3 man dev team (Rails/JS/IOS) did a bit of skunk works, and built the original idea in 2 days. We had a good head of tech at the time so we deployed it and just kept quiet when we estimated new forms.
moffkalast 3y ago
It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.
- rabuse 3y ago
  How so? Genuinely curious.
  - moffkalast 3y ago
    Just an intuition developed over time with experience I suppose, as long as you have a fixed team you've worked with for a while on similar projects, with requirements that don't depend on many external factors.
  - HeyLaughingBoy 3y ago
    The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y. The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to something they did before. Estimation is itself a time-consuming task.
    - ozim 3y ago
      Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.
      - HeyLaughingBoy 3y ago
        Doesn't take anywhere near that long, but if you want accuracy, then you have to put in the work.
  - clhodapp 3y ago
darrylb42 3y ago
I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.
- QuercusMax 3y ago
  Was the intention to force people to break tasks down into smaller chunks? There's no way you're spending months on something that can't be broken down at all.
  - Shaanie 3y ago
    Breaking projects down into <2 day chunks isn't a bad idea (although max 2 days is a bit aggressive), but those chunks are likely going to be useless to stakeholders and shouldn't be communicated outside of the team.
babyshake 3y ago
If you are fully in charge of a project you can often create complete specs. When working with PMs, designers, other stakeholders, you can often not have complete specs because the requirements are constantly shifting. Because you're "lean" and "agile".
- ozim 3y ago
  I don’t see this working out. Mostly people want something working right away and writing out specs would eat out all dev budget - you could create complete specs if you pay with your own money, maybe?

black_13 3y ago

[dead]

drittich 3y ago

Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.

dagss 3y ago
Did you look at sp_describe_first_result_set? https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-describe-first-result-set-transact-sql?view=sql-server-ver16 https://learn.microsoft.com/en-us/sql/relational-databases/s...
tempodox 3y ago
> Really, the first build IS the process of estimating. You hit the nail on the head.
awinter-py 3y ago
yes this difficult to scope some projects without starting the build

okaram 3y ago

I have found a sure way to get estimates... Do the work, and say how long it took me.

joombaga 3y ago
You should probably still add a week to the estimate.

eschneider 3y ago

It's realism, not cynicism. I've absolutely been in situations like that where the sensible estimate is 5X what management is angling for and I know it's the case because we've done that exact thing (In this case, new hardware bring up) many times and with the inevitable problems, it always takes the high number. :/

john_the_writer 3y ago
I worked at a place where everything had to be gold plated. Some devs had an idea for a json driven form. It was super simple. Less than a week of dev time. Management got it and an architect got involved. The project was taken from the original devs. The new team spent 2 months building a DSL, that didn't support mobile (so didn't meet the requirements). In the end it was canned. The original 3 man dev team (Rails/JS/IOS) did a bit of skunk works, and built the original idea in 2 days. We had a good head of tech at the time so we deployed it and just kept quiet when we estimated new forms.

moffkalast 3y ago

It is possible to give shockingly correct estimates, but management doesn't like to hear how long it'll actually take, they just want to hear the number they already imagined.

rabuse 3y ago
How so? Genuinely curious.
- moffkalast 3y ago
  Just an intuition developed over time with experience I suppose, as long as you have a fixed team you've worked with for a while on similar projects, with requirements that don't depend on many external factors.
- HeyLaughingBoy 3y ago
  The only consistently accurate estimates are based on previous work for which you have data. As a general rule, if you did X and it took Y days, the next time you do something similar to X, it will take an amount of time very similar to Y. The problem is that (a) most organizations don't track and record the time to do anything and (b) people don't want to take the time to break down tasks to units similar to something they did before. Estimation is itself a time-consuming task.
  - ozim 3y ago
    Agree, splitting up tasks and writing all out to a T and then estimating it, could take basically all time or budget available for project.
    - HeyLaughingBoy 3y ago
      Doesn't take anywhere near that long, but if you want accuracy, then you have to put in the work.
- clhodapp 3y ago

darrylb42 3y ago

I worked at one place where if the estimate for any task was over 2 days it would not get approved. Some really required two days tasks could take months. If we didn't want to do it, high estimate. If the business really wanted it they asked different devs until it was two days. Such a strange place to work.

QuercusMax 3y ago
Was the intention to force people to break tasks down into smaller chunks? There's no way you're spending months on something that can't be broken down at all.
- Shaanie 3y ago
  Breaking projects down into <2 day chunks isn't a bad idea (although max 2 days is a bit aggressive), but those chunks are likely going to be useless to stakeholders and shouldn't be communicated outside of the team.

babyshake 3y ago

If you are fully in charge of a project you can often create complete specs. When working with PMs, designers, other stakeholders, you can often not have complete specs because the requirements are constantly shifting. Because you're "lean" and "agile".

ozim 3y ago
I don’t see this working out. Mostly people want something working right away and writing out specs would eat out all dev budget - you could create complete specs if you pay with your own money, maybe?