Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have used the term demo driven development before but in a different context.

It is when clients can’t articulate the business requirements without seeing and using the software. New and different requirements arise after using the software or seeing a demo.

There is not even a clean way to handle this legally in a contractual sense of what is to be delivered.

It becomes an infinite cycle with no way to honor constraints.



if the client can't tell you what they want, and there is no process to get to an answer, how could this be done any better?

as for the contract, if the client can't settle on a goal i would fall back to hourly billing with an open ended contract. not every contract has to start with a specific deliverable.

but really, the better approach in this case would be to start with roadmapping or similar. let's spend X hours/days to analyze your business needs and come up with a proposal.


The problem with open ended is the client becomes their own worst enemy in terms of managing their budget versus feature trade off. After all , no client has an endless pool of money.

Certain stakeholders may also be disconnected from the budget so you may get conflicting feedback.

I’m not suggesting it can be done any better. I can only think of staying away from those clients .


I don't understand how that is a problem, you want the person managing feature trade offs to be mindful of the budget. If the business itself is sound, delivering the most valuable features will increase the budget. So those two must be aligned.

I think the problem with an open ended contract is that you, the developer, don't have any significant incentive to create value for the client: as long as the client has budget and likes what you're doing, you are good. Once it ends, it doesn't matter if your code falls apart because you are not there to pick up the pieces.

So you have to drive your consultation business on reputation and honor only, not on the value of what you create, at least not directly. It is possible but not ideal.

My preferred way is to have skin in the game. Perhaps not so much that a single project's failure will kill your company, but enough to get rewarded for success in the mid- to long term.


thank you. it is interesting to see the difference in mindset about this. a few weeks ago i was talking with some people at a developer meetup, and they all insisted that doing anything but hourly billing would be stupid because why would you take that risk.

i didn't know what to say. i didn't think about reputation and honor. but next time i'll ask how they would establish trust with a new client that doesn't know them yet.


You definitely want the client to manage their own budget, but sometimes they are incapable. I would suggest to avoid those clients, even if they pay more.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: