Live data from Hacker News

Frog Driven Development by spif

24waystostart.com

1–7 of 7 posts

Re: Frog Driven Development by spif

#4
post #2

Note that the story of the frog and the boiling pot is an urban legend. Apart from that, I like the analogy.

I thought about mentioning that it's debatable whether or not it's an urban legend but decided the analogy would hold in anycase.

If you can stomach frog torture then here's some more background: http://en.wikipedia.org/wiki/Boiling_frog

Re: Frog Driven Development by spif

#5
post #4
post #2

Note that the story of the frog and the boiling pot is an urban legend. Apart from that, I like the analogy.

I thought about mentioning that it's debatable whether or not it's an urban legend but decided the analogy would hold in anycase. If you can stomach frog torture then here's some more background: http://en.wikipedia.org/wiki/Boiling_frog

Time ago, I worked in a project where the customer's boss had a colorful version of the frog boiling story. He said that if you wake up, look yourself in the mirror and see four balls, you're not Superman, but someone is f*ing you.

I believe the basic error is not recognizing the project as an integration task. There are many systems that fit nicely into some existing mature framework. There are others that require an additional effort to make two pieces of software work together, two pieces of software that weren't meant to play together in the first place.

A programmer that's able to do this kind of work needs a very wide knowledge, specific experience and being very stubborn. Outsourcing this work is, now you know, risky. But it's not just that. If you're working now with people in-house, I assume you're seeing that little quirks take more time than functionality development.

Re: Frog Driven Development by spif

#6
post #5
post #4

Earlier quoted context omitted.

I thought about mentioning that it's debatable whether or not it's an urban legend but decided the analogy would hold in anycase. If you can stomach frog torture then here's some more background: http://en.wikipedia.org/wiki/Boiling_frog

Time ago, I worked in a project where the customer's boss had a colorful version of the frog boiling story. He said that if you wake up, look yourself in the mirror and see four balls, you're not Superman, but someone is f *ing you. I believe the basic error is not recognizing the project as an integration task. There are many systems that fit nicely into some existing mature framework. There are others that require…

Having done a fair bit of integration work, I refer to the US Healthcare bills as an IT industry stimulus (integrating hundreds of HMOs / you gotta be kidding)

Re: Frog Driven Development by spif

#7
"We switched the project from an hourly rate to a fixed fee after seeing that the costs would be more than we budgeted. This would move some of the risk to Kev and be the right incentive to have him deliver both a working release and the source code."

I don't have a lot of experience contracting or being a contractor, but if it's clear that a project is going over budget, what contractor in their right mind would agree to a fixed fee contract? It sounds like that would be a situation with no upside for the contractor. Am I wrong about this?