5 ms·

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

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.

pylua 3y ago
Right , not to mention that often times non technical stakeholders may be confused about the amount of progress that has been made.
- edvinbesic 3y ago
  That seems like more of a communications issue rather than a technical one.
  - FridgeSeal 3y ago
    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”.
Lutger 3y ago
Every practice can be abused. If you are thinking like this, is there any process at all which doesn't have negative unintended consequences? Or in which the benefits outweigh those consequences? Anecdotally, we started doing mini-demo's in the daily standup, sometimes we even show some code. This works really well for us, but it requires some maturity to keep it short and useful.
sillyfluke 3y ago
>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.

pylua 3y ago

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

edvinbesic 3y ago
That seems like more of a communications issue rather than a technical one.
- FridgeSeal 3y ago
  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”.

Lutger 3y ago

Every practice can be abused. If you are thinking like this, is there any process at all which doesn't have negative unintended consequences? Or in which the benefits outweigh those consequences? Anecdotally, we started doing mini-demo's in the daily standup, sometimes we even show some code. This works really well for us, but it requires some maturity to keep it short and useful.

sillyfluke 3y ago

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