4 ms·

How do you estimate how much time a task will take, especially when it's a novel idea, at least for your developers?

LargeWu 8y ago
You don't. That's the thing. Yet decision makers commit to deadlines anyway, and that's the problem.
mirceal 8y ago
You break it down (effectively doing the work) as part of planning and after that you pretend that you have a working system. Make sure not to go into details and/or “take it offline” until the developer is tired/annoyed enough to just agree with you pipe-dream estimates /s
- bazooka_penguin 8y ago
  I see, so you simply hire superhumans who finish the project before UX mockups are even available. Simple stuff. I think I'm ready to start my own consulting business
  - mirceal 8y ago
    You got it. Make sure every task can be done in half a day or less. That is key /s
commandlinefan 8y ago
> How do you estimate how much time a task will take when it's a novel idea In my experience, they just pretend it doesn't exist and remove it from the "plan". Where I see this the most is in figuring out how things work. For some reason, non-programmers have it in their head that once you've finished college, you ought to know (even though they don't) how everything that goes on a computer works instantaneously. We're going to use Apache Kafka! Ok, need to spend some time figuring out how that works. Um, ok, that should take like an hour, right? Because there's no time in the budget to learn anything. If you push back, they say, "ok, never use anything new that you have to learn. Only use the things you already know". That doesn't work either, because the things that we have to integrate with don't work with the old things. Or, "you don't need to know how that works, Bob knows how that works, just ask him. But don't let it take any time, because there's no time in the plan for that" And Bob is sick of all your questions that you'd know the answer to if you'd just spent a two or three days reading the online documentation and installing a test system and testing it out.
- markkanof 8y ago
  You hit on one of my favorite gems, "Bob has done something like that before, just ask him how to do it." The manager is envisioning that the team already possesses the knowledge necessary to get the task done, so there should be zero learning time involved. What this is missing though is that Bob isn't going to be solving the problem for the current task AND/OR Bob didn't even solve a similar problem, he just used the same tool or library that is now being used for the current task. If we had a Matrix like ability to instantanously transfer knowledge then this approach might work, but we aren't there yet.
crdoconnor 8y ago
Invest time in determining the right approach and planning it out. Most of that will be doing spikes: http://agiledictionary.com/209/spike/ http://agiledictionary.com/209/spike/ It's one the most underappreciated agile concepts. I wish people would shut up about standups once in a while and give more thought to doing spikes.
- fjsolwmv 8y ago
  It wouldn't be easier if we didn't have to keep learning silly new words for everything. I used to do prototypes and proofs of concept, now I have to do spikes.
  - crdoconnor 8y ago
    Spikes are not necessarily proofs of concept or prototypes. A spike is simply a task aimed at gathering information. Spending 30 minutes researching four different libraries to see which one to would be a spike, for instance, but it doesn't necessarily involve building a proof of concept.

You don't. That's the thing. Yet decision makers commit to deadlines anyway, and that's the problem.

You break it down (effectively doing the work) as part of planning and after that you pretend that you have a working system. Make sure not to go into details and/or “take it offline” until the developer is tired/annoyed enough to just agree with you pipe-dream estimates /s

bazooka_penguin 8y ago
I see, so you simply hire superhumans who finish the project before UX mockups are even available. Simple stuff. I think I'm ready to start my own consulting business
- mirceal 8y ago
  You got it. Make sure every task can be done in half a day or less. That is key /s

commandlinefan 8y ago

> How do you estimate how much time a task will take when it's a novel idea In my experience, they just pretend it doesn't exist and remove it from the "plan". Where I see this the most is in figuring out how things work. For some reason, non-programmers have it in their head that once you've finished college, you ought to know (even though they don't) how everything that goes on a computer works instantaneously. We're going to use Apache Kafka! Ok, need to spend some time figuring out how that works. Um, ok, that should take like an hour, right? Because there's no time in the budget to learn anything. If you push back, they say, "ok, never use anything new that you have to learn. Only use the things you already know". That doesn't work either, because the things that we have to integrate with don't work with the old things. Or, "you don't need to know how that works, Bob knows how that works, just ask him. But don't let it take any time, because there's no time in the plan for that" And Bob is sick of all your questions that you'd know the answer to if you'd just spent a two or three days reading the online documentation and installing a test system and testing it out.

markkanof 8y ago
You hit on one of my favorite gems, "Bob has done something like that before, just ask him how to do it." The manager is envisioning that the team already possesses the knowledge necessary to get the task done, so there should be zero learning time involved. What this is missing though is that Bob isn't going to be solving the problem for the current task AND/OR Bob didn't even solve a similar problem, he just used the same tool or library that is now being used for the current task. If we had a Matrix like ability to instantanously transfer knowledge then this approach might work, but we aren't there yet.

crdoconnor 8y ago

Invest time in determining the right approach and planning it out. Most of that will be doing spikes: http://agiledictionary.com/209/spike/ http://agiledictionary.com/209/spike/ It's one the most underappreciated agile concepts. I wish people would shut up about standups once in a while and give more thought to doing spikes.

fjsolwmv 8y ago
It wouldn't be easier if we didn't have to keep learning silly new words for everything. I used to do prototypes and proofs of concept, now I have to do spikes.
- crdoconnor 8y ago
  Spikes are not necessarily proofs of concept or prototypes. A spike is simply a task aimed at gathering information. Spending 30 minutes researching four different libraries to see which one to would be a spike, for instance, but it doesn't necessarily involve building a proof of concept.