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

51–60 of 64 posts

Re: Demo-driven development (2021)

#51

Post by sillyfluke »

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…

>you still need to spend another 6 months building out all the invisible things that make it actually releasable.

That's why it's always advisable to have an actual release of the features at demo day, or in the case of exceptions, the next demo day. And if you don't have internal or external customers, at least released to a QA team that's user testing or building prototypes with it (if it's dev oriented).

There should always be something early on demonstrating evidence that it's ok in production.

Re: Demo-driven development (2021)

#54

Post by ranting-moth »

NotGMan wrote: post #45

This is similar-ish to how Valve develops there games. Each week they playtest the game with real people: so basicaly a small "demo" is used each week to see if the new features are actually good. This is how they actually see asap if what they're doing is good or not. Obviously the big picture has to be taken into account and this obviously won't work for all software.

I like this, but it's much more like a user/usability testing instead of a demo (with demo as a side effect).

Re: Demo-driven development (2021)

#55

Post by ranting-moth »

bazoom42 wrote: post #52
tkiolp4 wrote: post #2

So much ceremony. Suddenly programming feels like work.

Is someone paying you to do it?

"Feels like work" and "Getting paid for it" are not always related.

Some people happily program and get paid for it but it doesn't feel like work to them. They can be incredibly productive because they're exactly where they want to be in life.

Now take that person that might hate the spotlight and ask him to do a weekly demo. That's just going to be misery for everyone involved.

Re: Demo-driven development (2021)

#56

Post by simne »

I like agile approach, because classics waterfall with yearly plan is just somewhere other planet.

But weekly demo is too fast, this is near impossible to implement something really techie.

I think, really adequate timing, should be "tick-tock" style, mean period of making feature, then period to lower tech debt. To be strict, I think good enough 2 weeks to make demo, then 2-4 weeks to eliminate debt (may be prolonged).

Re: Demo-driven development (2021)

#57

Post by brutusborn »

Lutger wrote: post #48
brutusborn wrote: post #42

Earlier quoted context omitted.

I’m probably being a bit naive here but isn’t the idea that you are just demo-ing the work your team is already meant to be doing? In that case turning the work into a demo should be as simple as running a bunch of tests on a big screen. Tests that you would be writing anyway. What am I missing?

Office politics.

Like a manager forcing you to make the sexy bits first so the demos look nice?

Re: Demo-driven development (2021)

#58

Post by em-bee »

Lutger wrote: post #49
pylua wrote: post #32

Earlier quoted context omitted.

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

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.

Re: Demo-driven development (2021)

#59

Post by XCSme »

On the same note, maintaining a product for 13 years, I keep thinking about, what I call, "docs-driven development"[0].

The idea is to have a minimal set of core features that allow you to achieve complex tasks (might be tedious at the start to do so), but document those ways to achieve the tasks using the current set of features. If a certain workflow is being used enough (e.g. Photoshop: remove background from an image using the Lasso Tool), replace the tutorial in the docs with an actual new feature that simplifies this workflow (e.g. include an algorithm/AI to automatically remove the background from an image in one click).

The advantage of this is that customers are still able to achieve what they need (using your guidance/tutorial), but in the long-term you improve the product and make your customer's life easier if you start providing one-click automations/better UIs for the most common use-cases.

[0]: https://uxwizz.com/blog/docs-driven-development

Re: Demo-driven development (2021)

#60

Post by pylua »

Lutger wrote: post #49
pylua wrote: post #32

Earlier quoted context omitted.

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

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.
Post reply on HN