Demo-driven development (2021)
rubick.com
rubick.com
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.
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.
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.
- 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.
In my personal experience though, with mediocre leadership this would lead to a situation where a demo is expected for every iteration and if you can't deliver something flashy every time, you'd get under fire. I feel like this would also lead to management skipping steps in the software development lifecyle, i.e. no testing because "good enough", since it worked in the demo.
It's not real until you've built it for a real user.
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!
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.
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.
Suggesting that demos are somehow unrelated to non-web/non-FE units of technical work is just nonsense.
If you added a cool animation to a button, the work is the demo. You don’t need to do any extra work, make any extra graphs, or explain very much of anything. Literally everyone will get it.
Also I’ve been at countless places that insist graphs and charts aren’t demos, but still insist backend teams do demos. This usually ends up with hitting an API with curl while everyone’s eyes glaze over.
Then your gripe is not with demos, or frontend. Your gripe is with bad orgs. Which has nothing to do with demos or development practice.
2. In nearly 20 years of doing this, I've never seen an org that got backend demos right, which to me says more about demos than it does about the organizations.
The word "demo" implies that you're going to see some live use of the thing, so while I disagree with it, I can understand what leads managers to say they don't want to see a slide presentation of graphs and charts.
No one wants to do "Power Point Presentation Driven Development", but for a lot of backend teams that's the only practical option for regular demos.
:shrug: I guess? I don't really agree but don't really see the validity in debating perceived difficulty.
> 2. In nearly 20 years of doing this, I've never seen an org that got backend demos right, which to me says more about demos than it does about the organizations.
Again, :shrug:, I have not experienced the difficulty you're describing across a wide range of companies and teams.
> The word "demo" implies that you're going to see some live use of the thing,
Maybe herein lies the problem? Because I don't agree with this statement at all, nor have my teams and companies.
> No one wants to do "Power Point Presentation Driven Development"
I do. I have. I will continue to, as I would call these "demos", and they continue to do well. Although I will add that I prefer jupyter notebooks to powerpoint for some types of demos.
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.
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.
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.
What am I missing?
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.
It also feels like business schools do not teach people how to manage teams where the contributors are non fungible .
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.
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).
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.
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.
But if you are an employer getting paid, only an insuffereable primadonna would object to a reasonable task because it “feels like work”.
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.
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.
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 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.
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.
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 know, those are fuzzy terms.)