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

21–30 of 64 posts

Re: Demo-driven development (2021)

#21

Post by cjhowarddev »

I think what's impactful about this approach is how it allows a team to share progress and get early feedback from key stakeholders. If you demo to the team that built the software you might get marginal value, but when your leaders are involved, or when key customers are involved, this can be powerful. Demoing a project early is a great way for those with skin in the game to help change course early, or ensure that the deliverables will meet the quality bar they expect before it's too late. It also helps set expectations for how long the average development cycle is, and with tangible progress highly visible, can help ease concerns on timelines and delivery.

This might not make sense at a small company that has few internal stakeholders or that can deliver a feature soup to nuts in a "sprint". In large companies, like Amazon where I work, this is great because the smallest unit of time to deliver any marginally complex new feature or application appears to be somewhere around 3-6 months of effort.

This is a great mechanism for routine check-ins during that time.

Re: Demo-driven development (2021)

#22

Post by alex_lav »

swsieber wrote: post #12
stefan_ wrote: post #3

Begging people to realize not everything that involves development is also web frontend or app development.

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 can create a demo around that work. If you've fixed a bug, you can create a demo around that work.

Suggesting that demos are somehow unrelated to non-web/non-FE units of technical work is just nonsense.

Re: Demo-driven development (2021)

#23

Post by p1necone »

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 above them (i.e. whoever decides their salary/career progress) that only revolve around these demos.

Otherwise at some point the software is "ready" from a "we have demoed all the features" perspective, but you still need to spend another 6 months building out all the invisible things that make it actually releasable.

Re: Demo-driven development (2021)

#24

Post by yen223 »

quelsolaar wrote: post #5

I'm not generally for formalized development process but i love this. I have for a long time argued that a great way to do anything is to think how you would give a talk about your work. If you plan on giving a lecture about your work, you will: - Come up with a narrative to explain your work. - Think about what makes it compelling. - Be sure to have clear reasons for your choices. - Avoid boring approaches. If publi…

The biggest benefit here is that it helps to filter out bad ideas.

If you're struggling to come up with a good narrative for why the work is useful or compelling, there's a high chance that it's because the benefits are not as great as you thought it was!

Re: Demo-driven development (2021)

#25

Post by FridgeSeal »

alex_lav wrote: post #16
stefan_ wrote: post #3

Begging people to realize not everything that involves development is also web frontend or app development.

Begging non web people to realize you can still demo non web work

Begging all the PM’s to not be visibly disappointed when my non-web demo isn’t as shiny and fun looking as “changed the colour and position of this button”.

Re: Demo-driven development (2021)

#26

Post by foobiekr »

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 and methodologies that exist to work around the fact that no one builds or bothers with expertise.

Re: Demo-driven development (2021)

#27

Post by sarchertech »

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…

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 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.

Re: Demo-driven development (2021)

#28

Post by pylua »

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.

Re: Demo-driven development (2021)

#29

Post by pylua »

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 .

Re: Demo-driven development (2021)

#30

Post by pylua »

cjhowarddev wrote: post #21

I think what's impactful about this approach is how it allows a team to share progress and get early feedback from key stakeholders. If you demo to the team that built the software you might get marginal value, but when your leaders are involved, or when key customers are involved, this can be powerful. Demoing a project early is a great way for those with skin in the game to help change course early, or ensure that…

It also introduces more entropy as more people may ask for more features or changes on a consistent basis which can impact timelines. Stakeholders seem to ignore the latter.
Post reply on HN