23 ms·

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deep

by ftio 6y ago

Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody wants to be left out of demo day multiple weeks in a row.

klenwell 6y ago
On my team, we call this the "Jobs Rule" (i.e. Steve Jobs). As opposed to the Elon rule: promise the moon (or Mars).
thayne 6y ago
Or intentionally show them the rough edges. "Oh, oops it can't handle that input yet, let me try with something that does work."
renewiltord 6y ago
I currently do the opposite and I think it's the right way. Do the part that can provide quick validation first. Usually that's the front-end. You can find out if you're making the right thing pretty fast that way. What are they going to do? Fire me? I can go anywhere. They can't find me anywhere.
webreac 6y ago
For me, the purpose of the "demo" is to get agreement on specifications and to remove ambiguities. This can also be used to reassure that the requirements of the client have been well understood.
rado 6y ago
One of the most important lessons. It must be presentable, however extra effort and time it would take.
nicbou 6y ago
That's excellent advice. I can see how demoralizing it could be to work on something you've already demoed.
Cthulhu_ 6y ago
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake. I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works. I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).
jrochkind1 6y ago
The problem with this is that to produce quality, you actually need iterative feedback from stakeholders and users/user representatives. If you don't show anyone anything until it's "done", you are doing work in a direction that would have been better informed by more feedback. (Cause another lesson is that people have a lot of trouble giving worthwhile feedback on a verbal/written description of something, they gotta see a thing in front of them).
- blablabla123 6y ago
  But I think that's still possible. For example when testing a new idea that just takes some months, it's pointless to show an alpha version where half of the buttons create error messages - even if it solves a much more valuable problem and these errors could be ignored. Instead one should make a presentation of a mockup or a screen recording how a single feature will work. That's much more digestible for everybody and gives far better results if the one watching has anyways only 3 minutes time.
naikrovek 6y ago
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I've learned the opposite. If I communicate clearly that what is being shown is little more than a mock-up, executives of all levels and technical skill, all the way down to managers just above myself, all understand that a very thin and scripted demo is not anything close to a finished product. Describing the demo as a "house of cards" that will collapse with a single misstep gets the point across nicely, while also giving the demo audience an eyeful of what can be accomplished if everything is handled appropriately. Demos are carefully scripted and rehearsed, values are hard-coded, and absolutely nothing exists that does not prop up the demo for the purposes of the script and the talking points. It is hard to describe to someone who hasn't written an application demo like this just how little actually exists behind the UI. Anyway, my point is that if you choose the correct words, anyone can understand that it's like a painting of an application, and not an actual application, just like a painting of your mother is not actually your mother.
caymanjim 6y ago
In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to be able to be more selective in where I work now, and have the experience to drive the choice.
- bonedangle 6y ago
  I've been with a few companies that waterfall in two-week cadences and call it Agile... They usually expect a fully working demo
  - jerzyt 6y ago
    There's no greener grass on the other side. I've been in the big consulting business, and sometimes you can't get a client to schedule a meeting for months, so you're flying blind, with absolutely no feedback. And then we go into the typical cycle of "Lessons Learned" etc, because what you've developed is irrelevant to the client.
- rawoke083600 6y ago
  Urg agile, scrum, some-other-magic-words I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exceptions), same with funny :) I feel it goes double for "agile-processes" if you have to walk around and tell everyone (management or interviewees how agile your process is, it's probably not)
  - Piskvorrr 6y ago
    That's...a great point, actually. The most humane (and incidentally, agile) workplaces I've met didn't mention agile much: "yeah, we do this and that, we just want to have a sane environment." The places that went "we do all the agile incantations in the book, because that's the only way," well, those actually had a scrum-o-fall culture.
csours 6y ago
I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.
- betenoire 6y ago
  It depends on the audience. A customer demo is different than an internal demo, and I assume you are referring to an internal demo. You must demo the product in a form that leaves the right impression of the current state. If you are painting a picture of a polished product, expect polished expectations. Instead, show the bugs and say "we are still working through this section" Show missing pages, show your work in progress. Show wrong colors. Show potential, wave your hands and tell them to imagine this part working. Don't fake it. If that feels wrong, then a demo isn't right. If you show it in a form that looks complete and polished, even if you say it is not, how can you expect any other conclusion from the viewer other than "it's practically ready!"?
  - Heyso 6y ago
    I can only agree with that. It is kinda just being honest. I don't know from where come this idea to showcase our work better than it actually is. Is it our own ego, showcasing unfinished/buggy work making us question our competency? Is it the fear of getting negative feedback because it is buggy and unfinished? Is it deeper issue, society making us believe, that what counts is superficial (apparence) way more than it should?
  - Piskvorrr 6y ago
    Great point with the visual appearance: show what you currently have, just include ugly.css. People are wired to understand Comic Sans and hot pink on green intuitively.
- irrational 6y ago
  If they could be educated, they wouldn’t be managers.
core-questions 6y ago
> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.
- lmm 6y ago
  > Not everything can be broken down into chunks of work that fit into a single sprint. In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.
  - hinkley 6y ago
    How much brownfield work have you done? People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
    - lmm 6y ago
      > How much brownfield work have you done? 4-11 years depending on exactly what you'd define as "brownfield" > People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable. True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.
  - mikro2nd 6y ago
    Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.
    - lmm 6y ago
      Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.
Jtsummers 6y ago
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though it wasn't ready, and both the customer and I found that there were issues in that last 20% I hadn't reached.
- kgermino 6y ago
  > Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page. It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.
  - bfdm 6y ago
    Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable. Sucks it has to be this way so often.
    - giancarlostoro 6y ago
      If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.
    - gibolt 6y ago
      I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback. The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.
ngngngng 6y ago
That's a funny comparison to demo days early in my career. The company I worked at had too much upper management that would hijack dev teams to make "cool" features constantly. We only had to make something good enough to appear like it worked in a demo though, because then that upper manager would get his bonus or look good to the CEO or CTO and we could move back to doing real work.
deleted 6y ago
[deleted]

by ftio 6y ago

klenwell 6y ago

On my team, we call this the "Jobs Rule" (i.e. Steve Jobs). As opposed to the Elon rule: promise the moon (or Mars).

thayne 6y ago

Or intentionally show them the rough edges. "Oh, oops it can't handle that input yet, let me try with something that does work."

renewiltord 6y ago

I currently do the opposite and I think it's the right way. Do the part that can provide quick validation first. Usually that's the front-end. You can find out if you're making the right thing pretty fast that way. What are they going to do? Fire me? I can go anywhere. They can't find me anywhere.

webreac 6y ago

For me, the purpose of the "demo" is to get agreement on specifications and to remove ambiguities. This can also be used to reassure that the requirements of the client have been well understood.

rado 6y ago

One of the most important lessons. It must be presentable, however extra effort and time it would take.

nicbou 6y ago

That's excellent advice. I can see how demoralizing it could be to work on something you've already demoed.

Cthulhu_ 6y ago

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I've learned this adage years ago (I think it was from Spolsky), but nowadays I'm in a project (re)building an UI from scratch as a sole developer aaaand I made the same mistake. I was doing some UI prototypes about activating a process, big green Activate button, opens up a confirmation dialog, spinners with some artificial / simulated delay because I didn't do the back-end, and it caused confusion with our tester because she was wondering if activation actually works. I've got three options; remove the button for now (I should do that), partially implement the activation (changing a status in the back-end), or fully implement the activation (which has a lot more prerequisites).

jrochkind1 6y ago

The problem with this is that to produce quality, you actually need iterative feedback from stakeholders and users/user representatives. If you don't show anyone anything until it's "done", you are doing work in a direction that would have been better informed by more feedback. (Cause another lesson is that people have a lot of trouble giving worthwhile feedback on a verbal/written description of something, they gotta see a thing in front of them).

blablabla123 6y ago
But I think that's still possible. For example when testing a new idea that just takes some months, it's pointless to show an alpha version where half of the buttons create error messages - even if it solves a much more valuable problem and these errors could be ignored. Instead one should make a presentation of a mockup or a screen recording how a single feature will work. That's much more digestible for everybody and gives far better results if the one watching has anyways only 3 minutes time.

naikrovek 6y ago

> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I've learned the opposite. If I communicate clearly that what is being shown is little more than a mock-up, executives of all levels and technical skill, all the way down to managers just above myself, all understand that a very thin and scripted demo is not anything close to a finished product. Describing the demo as a "house of cards" that will collapse with a single misstep gets the point across nicely, while also giving the demo audience an eyeful of what can be accomplished if everything is handled appropriately. Demos are carefully scripted and rehearsed, values are hard-coded, and absolutely nothing exists that does not prop up the demo for the purposes of the script and the talking points. It is hard to describe to someone who hasn't written an application demo like this just how little actually exists behind the UI. Anyway, my point is that if you choose the correct words, anyone can understand that it's like a painting of an application, and not an actual application, just like a painting of your mother is not actually your mother.

caymanjim 6y ago

In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to be able to be more selective in where I work now, and have the experience to drive the choice.

bonedangle 6y ago
I've been with a few companies that waterfall in two-week cadences and call it Agile... They usually expect a fully working demo
- jerzyt 6y ago
  There's no greener grass on the other side. I've been in the big consulting business, and sometimes you can't get a client to schedule a meeting for months, so you're flying blind, with absolutely no feedback. And then we go into the typical cycle of "Lessons Learned" etc, because what you've developed is irrelevant to the client.
rawoke083600 6y ago
Urg agile, scrum, some-other-magic-words I've come to realised this, "true" agile is more like being funny and smart(not that I am either). If you have to tell people you are smart or funny, you probably are not. Ever noticed how smart people(the really clever ones) are just absurdly smart without walking around telling everyone "hey I'm smart", usually the nicer they are the more intelligent they are(yea you get exceptions), same with funny :) I feel it goes double for "agile-processes" if you have to walk around and tell everyone (management or interviewees how agile your process is, it's probably not)
- Piskvorrr 6y ago
  That's...a great point, actually. The most humane (and incidentally, agile) workplaces I've met didn't mention agile much: "yeah, we do this and that, we just want to have a sane environment." The places that went "we do all the agile incantations in the book, because that's the only way," well, those actually had a scrum-o-fall culture.

csours 6y ago

I'm still conflicted about this. On the one hand I agree. On the other, I wish we could educate people enough for them to understand Proof of Concepts and Minimum Viable Products.

betenoire 6y ago
It depends on the audience. A customer demo is different than an internal demo, and I assume you are referring to an internal demo. You must demo the product in a form that leaves the right impression of the current state. If you are painting a picture of a polished product, expect polished expectations. Instead, show the bugs and say "we are still working through this section" Show missing pages, show your work in progress. Show wrong colors. Show potential, wave your hands and tell them to imagine this part working. Don't fake it. If that feels wrong, then a demo isn't right. If you show it in a form that looks complete and polished, even if you say it is not, how can you expect any other conclusion from the viewer other than "it's practically ready!"?
- Heyso 6y ago
  I can only agree with that. It is kinda just being honest. I don't know from where come this idea to showcase our work better than it actually is. Is it our own ego, showcasing unfinished/buggy work making us question our competency? Is it the fear of getting negative feedback because it is buggy and unfinished? Is it deeper issue, society making us believe, that what counts is superficial (apparence) way more than it should?
- Piskvorrr 6y ago
  Great point with the visual appearance: show what you currently have, just include ugly.css. People are wired to understand Comic Sans and hot pink on green intuitively.
irrational 6y ago
If they could be educated, they wouldn’t be managers.

core-questions 6y ago

> incentivizes teams to build things in small, shippable components. Isn't this a bit of a fallacy? Not everything can be broken down into chunks of work that fit into a single sprint. There's a reason I stopped bothering with Scrum a while ago, and this is high on the list.

lmm 6y ago
> Not everything can be broken down into chunks of work that fit into a single sprint. In my experience everything can be broken down if you spend five minutes actually trying to break it down. And the benefits are very much worthwhile.
- hinkley 6y ago
  How much brownfield work have you done? People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable.
  - lmm 6y ago
    > How much brownfield work have you done? 4-11 years depending on exactly what you'd define as "brownfield" > People can hide the fact that they have a big ball of mud fir a very long time, and they only want to talk about improvement after hunts have gotten miserable. True but beside the point. The same point stands: you can always find a way to make a worthwhile improvement in two weeks - something that's useful on its own, even if it's also the first step of a much bigger improvement plan.
- mikro2nd 6y ago
  Consider, then, that your experience might be limited in ways that you're unable to see due to that experience-bias.
  - lmm 6y ago
    Unlikely. I used to go looking for tasks that couldn't be broken down; I'd get excited when someone would claim that their task couldn't be broken down. But they always could, and it was never even hard.

Jtsummers 6y ago

Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though it wasn't ready, and both the customer and I found that there were issues in that last 20% I hadn't reached.

kgermino 6y ago
> Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. I take a different but similar approach when I run into situations where I want to get something small in front of a business user before it’s completely ready: I make sure it’s visibly broken in a way that doesn’t detract from my goal for the meeting. For example: I have a registration form that I want to talk through. The state drop down will only have 3 entries, one validation error will always display, and on final submit you get a “failed” alert instead of a dummy page. It lets me walk through the page and get whatever feedback I need, but it feels completely broken so non-technical users expect it to take more time to conplete.
- bfdm 6y ago
  Honestly, that feels like a huge waste of your own time to game a broken system. And I'm guessing it is, but that it's a defensive move because the darker timeline is miserable. Sucks it has to be this way so often.
  - giancarlostoro 6y ago
    If hes talking about JavaScript an alert dialog is a single line of code so I dont think its that bad. Also as long as frontend and backend have agreed on what certain objects structures will be hardcoding shouldnt be an issue.
  - gibolt 6y ago
    I've done this on quite a few occasions as well. It isn't necessarily time wasted, as you evoke a positive view from the client (progress towards the solution) and often get valuable feedback. The alternative is that they think you are done, adding more pressure, and requiring more wasted time later explaining the mis-aligned expectations.

ngngngng 6y ago

That's a funny comparison to demo days early in my career. The company I worked at had too much upper management that would hijack dev teams to make "cool" features constantly. We only had to make something good enough to appear like it worked in a demo though, because then that upper manager would get his bonus or look good to the CEO or CTO and we could move back to doing real work.

deleted 6y ago

[deleted]