Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Demo-driven development (2021)

rubick.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Demo-driven development (2021)

#31

Post by em-bee »

pylua wrote: post #28

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 const…

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.

Re: Demo-driven development (2021)

#32

Post by pylua »

em-bee wrote: post #31
pylua wrote: post #28

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 const…

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…

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 .

Re: Demo-driven development (2021)

#33

Post by em-bee »

29athrowaway wrote: post #15

If your product is something that will be used strictly in demos, do this. If your product is something an customer will use, demo-driven development will poison your processes by creating an endless backlog of neglected post-demo stuff.

one of the most enjoyable projects i was working on was where a customer came to us with a complete and functional demo and our job was to make it work with an actual backend. and as it happened i already had a complete and functional backend, so all we ended up having to do was to add APIs on both sides to tie them together.

Re: Demo-driven development (2021)

#34

Post by pylua »

p1necone wrote: post #23

In my experience this just encourages the team to build an application that's a glorified power point presentation, because the set of things that's useful for demoing stuff is a pretty small subset of what's actually needed for usable software. This approach only works if your team has the discipline to not output bullshit that just improves the demo, and if the team does not have incentives/pressure from those abov…

Right , not to mention that often times non technical stakeholders may be confused about the amount of progress that has been made.

Re: Demo-driven development (2021)

#35

Post by edvinbesic »

pylua wrote: post #34
p1necone wrote: post #23

In my experience this just encourages the team to build an application that's a glorified power point presentation, because the set of things that's useful for demoing stuff is a pretty small subset of what's actually needed for usable software. This approach only works if your team has the discipline to not output bullshit that just improves the demo, and if the team does not have incentives/pressure from those abov…

Right , not to mention that often times non technical stakeholders may be confused about the amount of progress that has been made.

That seems like more of a communications issue rather than a technical one.

Re: Demo-driven development (2021)

#36

Post by alex_lav »

sarchertech wrote: post #27
alex_lav wrote: post #22

Earlier quoted context omitted.

You can create an engaging demo for technical units of work that do not feature visual/user-understandable concepts. It's not rocket science (unless it is). A demo is nothing more than explaining a problem and then displaying the evidence that that problem has been positively impacted. Graphs are understandable by just about everyone. Before and after charts tell a story. If you measured and improved something, you c…

As I said elsewhere, sure you can make an engaging backend demo, just like you can make an engaging hacking scene in a movie. It’s just a lot harder though than making an engaging chase sequence. If you added a cool animation to a button, the work is the demo. You don’t need to do any extra work, make any extra graphs, or explain very much of anything. Literally everyone will get it. Also I’ve been at countless place…

> Also I’ve been at countless places that insist graphs and charts aren’t demos, but still insist backend teams do demos. This usually ends up with hitting an API with curl while everyone’s eyes glaze over.

Then your gripe is not with demos, or frontend. Your gripe is with bad orgs. Which has nothing to do with demos or development practice.

Re: Demo-driven development (2021)

#37

Post by foobiekr »

pylua wrote: post #29
foobiekr wrote: post #26

With senior people, demo-driven development is fine, because they will generally do the right thing on the path. Software has gotten so tedious. I genuinely think that the habit of switching to languages/tools/architectures where everyone is a novice has left the software industry without the usual pipeline of young people working with people who know what they're doing, and as a response there's just endless ritual…

It feels like companies are pushing for fungibility with developers , which is not possible given the current situation with many different methodologies and toolsets. It also feels like business schools do not teach people how to manage teams where the contributors are non fungible .

Yes, I think this is also true but very sector dependent. In embedded it's mostly not true.

Re: Demo-driven development (2021)

#38

Post by FridgeSeal »

alex_lav wrote: post #22
swsieber wrote: post #12

Earlier quoted context omitted.

I'd love examples for things I can wrap my head around.

You can create an engaging demo for technical units of work that do not feature visual/user-understandable concepts. It's not rocket science (unless it is). A demo is nothing more than explaining a problem and then displaying the evidence that that problem has been positively impacted. Graphs are understandable by just about everyone. Before and after charts tell a story. If you measured and improved something, you c…

Whilst I agree with you, there’s a definite frustration of demo-ing some complex backend work or bug fix and having PM’s eyes glaze over because your massive effort improving the infrastructure simply isn’t as shiny and easy as FE change. Got graphs? They don’t care, that’d mean they’d need to understand and that’s haaaaaard.

Re: Demo-driven development (2021)

#39

Post by alex_lav »

FridgeSeal wrote: post #38
alex_lav wrote: post #22

Earlier quoted context omitted.

You can create an engaging demo for technical units of work that do not feature visual/user-understandable concepts. It's not rocket science (unless it is). A demo is nothing more than explaining a problem and then displaying the evidence that that problem has been positively impacted. Graphs are understandable by just about everyone. Before and after charts tell a story. If you measured and improved something, you c…

Whilst I agree with you, there’s a definite frustration of demo-ing some complex backend work or bug fix and having PM’s eyes glaze over because your massive effort improving the infrastructure simply isn’t as shiny and easy as FE change. Got graphs? They don’t care, that’d mean they’d need to understand and that’s haaaaaard.

As I said elsewhere, your complaint is with shitty orgs, not demos. Don’t work for shitty orgs.

Re: Demo-driven development (2021)

#40

Post by FridgeSeal »

edvinbesic wrote: post #35
pylua wrote: post #34

Earlier quoted context omitted.

Right , not to mention that often times non technical stakeholders may be confused about the amount of progress that has been made.

That seems like more of a communications issue rather than a technical one.

I feel like this falls into the bucket of “if people using a tool always end up doing bad practice X or running into problem Y, maybe they’re not holding it wrong, maybe the tool has issues”.
Post reply on HN