6 ms·

Oy, this again. OP might as well ask, "Why doesn't my buggywhip make my Camry go faster?" Who cares whether or not anyone can estimate? These days, if you're e

by edw519 13y ago

Oy, this again. OP might as well ask, "Why doesn't my buggywhip make my Camry go faster?" Who cares whether or not anyone can estimate? These days, if you're estimating, you've already lost. Your competitors have already built and deployed something while you're in the endless analysis phase. Estimating presupposes that you have an accurate spec which presupposes that you're going through some kind of development cycle. And after 40 years, we know that rarely works. We know that what works better is combining analysis and development: prototyping quick cycles and stepwise improvement. It rarely matter how good it is; it only matters that is exists on time and that it's good enough. I propose an alternative: what we need to do is teach to junior devs the meaning of done. I propose an alternative to OP's alternative: what we need to do is define "done" as "whatever you've got at the deadline". When you don't know what you want (who does?), it's better to have something on time that you can improve upon than nothing late that wasn't right anyway. You don't need to estimate to do that; you just need to keep building and sharing.

slantyyz 13y ago
>> These days, if you're estimating, you've already lost. Well, if you're in services and are pitching to win a project, not estimating will virtually guarantee that you've lost the pitch to someone else. If a potential client tells you they've got ${insert amount here} to spend and asks you what you think you can deliver to them for that price, "whatever you've got at the deadline" is usually a non-starter.
- quanticle 13y ago
  >If a potential client tells you they've got ${insert amount here} to spend and asks you what you think you can deliver to them for that price, "whatever you've got at the deadline" is usually a non-starter. But isn't that the core of the agile software development philosophy? You, the client, turn your requirements into (somewhat independent) stories and prioritize them. We, the developers, take those stories and implement them in priority/dependency order. We ensure that the software is working at the end of every sprint (via extensive automated unit and integration tests). This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project.
  - slantyyz 13y ago
    >> This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project. Telling them $n sprints can be meaningless -- in practice, things just get pulled out of a sprint and pushed into the backlog, never to get done within $n sprints. I worked on one project where the client specifically asked for "agile". Meanwhile, their behaviour during the execution phase was that they wanted to see waterfall style results. It wasn't until the PM finally switched back to a waterfall that the project started seeing meaningful results-- i.e., the "let's move it to the backlog" tactic used by the technical team could no longer take place. Of note is that this is the classic story of a company that adopts "agile" despite the fact that the culture of its employees did not suit the methodology.
  - porker 13y ago
    Yes, but you need a special client for that. I'm starting to get one to accept sprints, but it's taken 2 years. The rest think sprints are a great excuse for me not to deliver and need another $X000 to finish the work (fair enough, I wouldn't trust a car mechanic/builder/plumber working on this system) Besides, clients always underestimate the time something takes. Expectation management is an oft-forgotten sibling to estimating. And when you're pitching for work, if others are promising to deliver everything for $Y and I offer a sprint-based system... as someone else commented, I've lost the project by then. I asked for advice on this a couple of days ago: https://news.ycombinator.com/item?id=5643259 https://news.ycombinator.com/item?id=5643259. Your input very welcome!
Fishkins 13y ago
This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics.
- edw519 13y ago
  This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics. Don't kid yourself; this is exactly what works for medical software or avionics. I never said we didn't test; I just said this is how we get stuff done: We use stepwise refinement instead of waterfall, so estimating is suddenly much less important. (For the record, I'm 100% enterprise and 0% consumer web/mobile apps. As we speak, in my other session, I'm building an aerospace prototype I intend to deploy within 48 hours.)
- dgregd 13y ago
  It doesn't work well for management with MBA background. These guys want to have all excel spreadsheet cells filled in upfront. And more important, there must be someone to blame for bad estimates in case of any problems. In corporate environment it is more important to have your ass well protected, than to speed shareholders many reasonably.

by edw519 13y ago

slantyyz 13y ago

>> These days, if you're estimating, you've already lost. Well, if you're in services and are pitching to win a project, not estimating will virtually guarantee that you've lost the pitch to someone else. If a potential client tells you they've got ${insert amount here} to spend and asks you what you think you can deliver to them for that price, "whatever you've got at the deadline" is usually a non-starter.

quanticle 13y ago
>If a potential client tells you they've got ${insert amount here} to spend and asks you what you think you can deliver to them for that price, "whatever you've got at the deadline" is usually a non-starter. But isn't that the core of the agile software development philosophy? You, the client, turn your requirements into (somewhat independent) stories and prioritize them. We, the developers, take those stories and implement them in priority/dependency order. We ensure that the software is working at the end of every sprint (via extensive automated unit and integration tests). This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project.
- slantyyz 13y ago
  >> This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project. Telling them $n sprints can be meaningless -- in practice, things just get pulled out of a sprint and pushed into the backlog, never to get done within $n sprints. I worked on one project where the client specifically asked for "agile". Meanwhile, their behaviour during the execution phase was that they wanted to see waterfall style results. It wasn't until the PM finally switched back to a waterfall that the project started seeing meaningful results-- i.e., the "let's move it to the backlog" tactic used by the technical team could no longer take place. Of note is that this is the classic story of a company that adopts "agile" despite the fact that the culture of its employees did not suit the methodology.
- porker 13y ago
  Yes, but you need a special client for that. I'm starting to get one to accept sprints, but it's taken 2 years. The rest think sprints are a great excuse for me not to deliver and need another $X000 to finish the work (fair enough, I wouldn't trust a car mechanic/builder/plumber working on this system) Besides, clients always underestimate the time something takes. Expectation management is an oft-forgotten sibling to estimating. And when you're pitching for work, if others are promising to deliver everything for $Y and I offer a sprint-based system... as someone else commented, I've lost the project by then. I asked for advice on this a couple of days ago: https://news.ycombinator.com/item?id=5643259 https://news.ycombinator.com/item?id=5643259. Your input very welcome!

Fishkins 13y ago

This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics.

edw519 13y ago
This is great for consumer web/mobile apps, but it doesn't work so well for medical software or avionics. Don't kid yourself; this is exactly what works for medical software or avionics. I never said we didn't test; I just said this is how we get stuff done: We use stepwise refinement instead of waterfall, so estimating is suddenly much less important. (For the record, I'm 100% enterprise and 0% consumer web/mobile apps. As we speak, in my other session, I'm building an aerospace prototype I intend to deploy within 48 hours.)
dgregd 13y ago
It doesn't work well for management with MBA background. These guys want to have all excel spreadsheet cells filled in upfront. And more important, there must be someone to blame for bad estimates in case of any problems. In corporate environment it is more important to have your ass well protected, than to speed shareholders many reasonably.