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.
Demo-driven development (2021)
41–50 of 64 posts
Re: Demo-driven development (2021)
#42Such 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.
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?
Re: Demo-driven development (2021)
#43This 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.
Re: Demo-driven development (2021)
#44So much ceremony. Suddenly programming feels like work.
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.
Re: Demo-driven development (2021)
#45This 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.
Re: Demo-driven development (2021)
#46In 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…
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.
Re: Demo-driven development (2021)
#47Such 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.
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?
[deleted]
Re: Demo-driven development (2021)
#48Such 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.
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.
Re: Demo-driven development (2021)
#49Earlier quoted context omitted.
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…
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 budget and likes what you're doing, you are good. Once it ends, it doesn't matter if your code falls apart because you are not there to pick up the pieces.
So you have to drive your consultation business on reputation and honor only, not on the value of what you create, at least not directly. It is possible but not ideal.
My preferred way is to have skin in the game. Perhaps not so much that a single project's failure will kill your company, but enough to get rewarded for success in the mid- to long term.
Re: Demo-driven development (2021)
#50I'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!
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.