My standby is “From what you’ve described, it would take about $X days” where X is an estimate that assumes that they want everything associated with what they’ve said. (So, if they asked for messaging, I assume they want user icons, some kind of friends list or department groupings, and probably file transfer too.) There is a genuine use case for this! If your business guys are non-techies, they might know that adding some feature will probably earn Y dollars, but don’t know how much it would cost to add. In those cases, they’re really looking to estimate if it’s worth it; if they’re doing things right, the next step if it looks good is to actually sit down and write up a solid spec.
Of course, lots of places aren’t like that. At my job, my estimate is continued with “but I could be pretty far off in either direction. Can you tell me more specifically...” and then from there try and guide them into giving me actual requirements. I write down the main points of what they’re asking for, say it back to them when they’re finished and make any revisions, and then email them that. If they agree that’s what they meant, then I start working on it.
This still doesn’t quite work. I’ve had my spec change radically two or three times a sprint (two week block) or been informed they assumed certain things were just obvious parts of what they asked for. (Like the messaging = file transfer thing. That was uh, non-intuitive, though I should have seen that coming since most major messaging systems have it.) In the end, the most important thing is to make sure you get paid for it. If I’m getting money to sit at a keyboard and think, I’ll get over throwing out half the code I write.
If you want more advice on constructively dealing with it, I’m sure there are people here with more experience than I have. If you’re looking for commiseration, you have mine.
if they asked for messaging, I assume they want user icons, some kind of friends list or department groupings, and probably file transfer too.
If they want to edit something in a web application, I assume they will also want the ability to edit the data on a smartphone without internet connection.. and then upload the changes later when they get online, and of course have all the edit conflicts magically resolved correctly without any user intervention. Did I mention it is supposed to work on all kinds of smartphones and notebooks?
(Ok, I am lying, I actually didn’t assume this… and it actually happened.)
My advice is always of the utmost sincerity, my dear Walterwood. The safest road to awful software is the gradual one- the gentle slope, soft underfoot, without sudden turnings, without milestones, without signposts. The duty of planning tomorrow’s work is today’s duty; though its material is borrowed from the future, the duty, like all duties, is in the Present. The truth is that wherever a developer has a meeting with a manager, there, whether they like it or not, a transcendental relation is set up between them which must be eternally enjoyed or eternally endured.
Put simply; to decide what the best use case is, you must ask what use the Management wants to make of it and then do the opposite. We know that is ultimately what they will decide. Only by our incessant efforts is the demand for infinite, or unrhythmical, change kept up.
Should you continue to find reason to distrust me, perhaps at some meetup or another I might take the opportunity to have you for dinner. >:)
My standby is “From what you’ve described, it would take about $X days” where X is an estimate that assumes that they want everything associated with what they’ve said. (So, if they asked for messaging, I assume they want user icons, some kind of friends list or department groupings, and probably file transfer too.) There is a genuine use case for this! If your business guys are non-techies, they might know that adding some feature will probably earn Y dollars, but don’t know how much it would cost to add. In those cases, they’re really looking to estimate if it’s worth it; if they’re doing things right, the next step if it looks good is to actually sit down and write up a solid spec.
Of course, lots of places aren’t like that. At my job, my estimate is continued with “but I could be pretty far off in either direction. Can you tell me more specifically...” and then from there try and guide them into giving me actual requirements. I write down the main points of what they’re asking for, say it back to them when they’re finished and make any revisions, and then email them that. If they agree that’s what they meant, then I start working on it.
This still doesn’t quite work. I’ve had my spec change radically two or three times a sprint (two week block) or been informed they assumed certain things were just obvious parts of what they asked for. (Like the messaging = file transfer thing. That was uh, non-intuitive, though I should have seen that coming since most major messaging systems have it.) In the end, the most important thing is to make sure you get paid for it. If I’m getting money to sit at a keyboard and think, I’ll get over throwing out half the code I write.
If you want more advice on constructively dealing with it, I’m sure there are people here with more experience than I have. If you’re looking for commiseration, you have mine.
If they want to edit something in a web application, I assume they will also want the ability to edit the data on a smartphone without internet connection.. and then upload the changes later when they get online, and of course have all the edit conflicts magically resolved correctly without any user intervention. Did I mention it is supposed to work on all kinds of smartphones and notebooks?
(Ok, I am lying, I actually didn’t assume this… and it actually happened.)
Thanks for the advice, but your username makes me reluctant to take it :).
My advice is always of the utmost sincerity, my dear Walterwood. The safest road to awful software is the gradual one- the gentle slope, soft underfoot, without sudden turnings, without milestones, without signposts. The duty of planning tomorrow’s work is today’s duty; though its material is borrowed from the future, the duty, like all duties, is in the Present. The truth is that wherever a developer has a meeting with a manager, there, whether they like it or not, a transcendental relation is set up between them which must be eternally enjoyed or eternally endured.
Put simply; to decide what the best use case is, you must ask what use the Management wants to make of it and then do the opposite. We know that is ultimately what they will decide. Only by our incessant efforts is the demand for infinite, or unrhythmical, change kept up.
Should you continue to find reason to distrust me, perhaps at some meetup or another I might take the opportunity to have you for dinner. >:)
A delicious ambiguity :-)
And one that calls back to the original source.
LessWrong: kind of an odd place to find references to Christian ethical literature.
You’d think that, but rationalist spaces are pretty much the only places where people recognize what I’m referencing.