Demo-driven development (2021)

https://www.rubick.com/demo-driven-development/

by cpeterso • 3 years ago

99 62 3 years ago

rubick.com

tkiolp4• 3 years ago

So much ceremony. Suddenly programming feels like work.

cjhowarddev2• 3 years ago

Programming is work for most of us, so that makes sense.

DragonStrength• 3 years ago

As my father in law would say, they don’t call it work because it’s fun.

dools2• 3 years ago

Work is what we do for others, hobbies are what we do for ourselves.

In some cases, those 2 things align but that's a happy coincidence and is often not sustained.

If you focus instead on whether or not you're actually creating value for someone else, then work can be enjoyable even if it doesn't feel like a hobby.

bazoom422• 3 years ago

Is someone paying you to do it?

ranting-moth3• 3 years ago

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

stefan_2• 3 years ago

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

jadeforrest• 3 years ago

From the article:

Include all the work. One thing to be careful of is that the demos are inclusive of all the work required to build functional software. Prepare the team to demo all the parts of their work: the APIs, the infrastructure, the reliability work, and the testing. It’s important for you to cheerlead the work that isn’t customer facing.

stefan_2• 3 years ago

These things don't demo well precisely because a demo doesn't help anyone to understand the decisions made in developing them. You can not just say "prepare to demo them anyway", that doesn't do anything useful.

swsieber• 3 years ago

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

alex_lav5• 3 years ago

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.

alex_lav5• 3 years ago

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

FridgeSeal3• 3 years ago

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

sarchertech3• 3 years ago

You can do an engaging backend demo, but it’s 100x harder.

It’s the difference between demoing a new maintenance process that lets you reduce down time on your chicken nugget forming machine by 15% and letting people try a new chicken nugget recipe.

quelsolaar2• 3 years ago

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 public speaking isn't your thing, writing a blog post or paper will do the same thing. I find that the urge to make your presentation fun and engaging, makes you go the extra mile to make what your are working on delightful, and that in turn makes the work more fun and engaging. Since motivation is the most valuable asset a person can have I put a lot of stock in this approach.

awesomeMilou2• 3 years ago

This approach is consulting 101. It rewards embellishment of your own work. I know for a fact that, if I'm allowed, I can be very convincing with regards to what I'm doing being meaningful and productive, even if I am doing total bullshit. I have enough public speaking skills to sell myself like that.

quelsolaar2• 3 years ago

I don't do it to make people think I'm doing a good job, I'm doing it because it makes me do a better job. Some people actually want to do a good job, not just do the minimal effort they can get away with.

quickthrower2• 3 years ago

A bit like writing the landing page first before building a product.

29athrowaway2• 3 years ago

Demo-driven development is Fiction-driven development.

It's not real until you've built it for a real user.

yen223• 3 years ago

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!

a96• 3 years ago

Or, it might be that you have not really understood the problem or the solution you're offering (yet). Might be good rubber ducking step, even if you don't show the demo to anyone else.

knallfrosch• 3 years ago

That's just Scrum/Agile?

(I know, those are fuzzy terms.)

aero142• 3 years ago

It’s a good version of scrum. There many more bad scrums.

downrightmike2• 3 years ago

Its basically just sprint demos. I wouldn't do them every week, monthly is fine.

29athrowaway2• 3 years ago

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.

downrightmike2• 3 years ago

You'll need a new bucket for Software Version: Never

em-bee3• 3 years ago

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.

cjhowarddev2• 3 years ago

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.

pylua6• 3 years ago

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.

p1necone• 3 years ago

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.

pylua6• 3 years ago

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

edvinbesic• 3 years ago

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

Lutger3• 3 years 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• 3 years 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.

foobiekr2• 3 years ago

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.

pylua6• 3 years ago

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 .

foobiekr2• 3 years ago

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

pylua6• 3 years ago

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.

em-bee3• 3 years ago

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.

pylua6• 3 years ago

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 .

lph• 3 years ago

Such bad memories of the team where everything was oriented around the weekly demo: One day a week spent on throwaway work to make a demo run, and then getting yelled at for not being productive enough.

brutusborn2• 3 years ago

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?

Lutger3• 3 years ago

Office politics.

dools2• 3 years ago

This is pretty similar to how I approach building software:

0) Sketch on paper

1) Clickable, static prototype that looks as if it works but actually does nothing, but is genuinely running on all target platforms (installed app or real URLs) that is nothing more than grey boxes and black arial font on a white background (but for example with real client side interaction widgets)

2a) Give this to a designer and say "make it look better", from which you get a set of design assets

2b) Give this to a developer and say "make it function"

3) Give designs to developer and say "make your version look like this"

The main challenge is ensuring that the designs stay in a format accessible by designers, such that it can be applied by developers to the functional application without starting from scratch.

The specifics on how to solve that and other challenges will vary a bit depending on the platforms and relative costs of prevailing skillsets but it's very much focused on having a thing that works as an app on the target platforms as early as possible, and implementing the smallest possible set of features with each iteration.

NotGMan• 3 years ago

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.

ranting-moth3• 3 years ago

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

ranting-moth3• 3 years ago

I think this will make the devs dangerously focused on the more visible features.

simne• 3 years ago

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

XCSme• 3 years ago

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

Demo-driven development (2021)

Related Stories