>> "This approach works because you’re thinking backwards from the needs of customers..."
And it can fail when all you want to do is give a great demo. I've seen many showcases which couldn't be further away from real projects. Use cases are constructed which are taylored to your features, a little deviation and it won't work anymore.
But still, it's a good exercise to see your project a bit more in the eyes of your user.
Exactly. The biggest mistake engineers make is thinking non-technical people think the way they do. They don’t.
Everyone else is thinking about getting new customers, and mostly with new features.
They only love to get into the details when product market fit is not working and they need to buy some time and get the investors off their back by justifying some large technical rewrite.
You bring up a good point -- maybe something I should emphasize more in this blog post.
Demos should be inclusive of all he work it takes to build a real, functioning piece of software. That should include the reliability work, the scaling, the testing, and the refactoring necessary to do real software engineering. And it should include APIs and containerization. So I guess I'm intending this as a fairly technical demo, but talked about from a customer and business perspective.
I personally think it's important for your stakeholders to understand the necessity of this work, and this gives the team the chance to talk about it.
Thanks for bringing up the failure mode of this -- I'll consider adding that to the blog post.
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. If you're in an environment where there is less trust, or the leadership doesn't understand how software should be built, you may need to use the demos to educate and give context on the team's work. It's also important for you to cheerlead the work that isn't customer facing.
My team has adopted a pretty bastardized version of this, and I think it’s a cautionary tale. We give demos after pretty much every sprint, which is absurd. Is anyone really interested in seeing me flail around for a way to demo optimizations I’ve worked on for two weeks to improve request times by fractions of a second or resolve tech debt?
I've never worked in a setting where demos were a durable feature of sprint planning, but in the transient attempts we've been generous with "demo" - walking through what changed in a refactor is very much in bounds (and probably should be - who is the customer of a refactor if not the other coders?).
I would be interested in that if I was leading your part of the org. Here's the value I would get out of it:
- I could see what portion of the team's time is spent on tech debt issues, which gives me a sense of how well we're dealing with tech debt, the state of testing, and how good our technical decision making are.
- It also gives me an idea of how well the team is dealing with the real maintenance necessary for a production product. Are we improving response times for customers, how hard is it to make improvements.
- It helps me understand team dynamics. How collaborative is the team's work. Who is working with whom? How much support do team members give each other. How much knowledge silos do we have. How does the team treat each other? Do they cheer on this type of work? How do they feel about maintenance.
That's just a few things that come to mind. I have found these demos to be some of the most information rich activities I engage in, and I find it helps me support my teams.
But I get the sense it doesn't feel great to you. What sucks about it for you?
But it’s definitely one of those things that sounds good until you try it across a variety of teams and different projects.
Developers love showing off their work. But regular demos create expectations. Software always becomes primarily about expectation management.
Early on progress is rapid and there is lots to show and people like showing it.
Then things slow down and you refactor, fix bugs, and you’re left demoing tiny things or with nothing visible to demo.
But you’ve created expectations of consistent delivery of visible features, and non-technical people don’t get it. And the chain of EM and PM don’t want to tarnish their reputation so they will get teams to hack things for a demo. Code quality suffers, and you are piling on tech debt.
Better: let teams demo things when they are ready to demo. Don’t have a blocked out time for it either. Then it always becomes: “so who is ready to demo?”…and if you’re not you are failing and then it’s a competition with other teams.
Constant iteration and demos are good to make sure you are doing the right thing, but not on a public scheduled interval.
It’s scary how many management concepts that come naturally to new engineers are actually terrible ideas in team/political settings. I think we are too used to dealing unemotional machines…
I agree, I have worked at 3 different places that implemented demo-driven development. It always looks good the first couple of weeks or even months, but then it goes down hill, just as you describe.
So much important work is not really possible to demo in a way that most people understand or see the gain it gives either.
I think, from previous experience, that demo-driven development sort of works if you are a company or project in the start up phase, because there are a lot of stuff to demo and the development goup(s) can get quite a boost from the excitement it generates.
11 comments
[ 72.2 ms ] story [ 106 ms ] threadAnd it can fail when all you want to do is give a great demo. I've seen many showcases which couldn't be further away from real projects. Use cases are constructed which are taylored to your features, a little deviation and it won't work anymore.
But still, it's a good exercise to see your project a bit more in the eyes of your user.
And any time spent on the non-visible portions of the project (at least 50% of the value) are seen as "waster" because there's nothing to demo.
Everyone else is thinking about getting new customers, and mostly with new features.
They only love to get into the details when product market fit is not working and they need to buy some time and get the investors off their back by justifying some large technical rewrite.
Demos should be inclusive of all he work it takes to build a real, functioning piece of software. That should include the reliability work, the scaling, the testing, and the refactoring necessary to do real software engineering. And it should include APIs and containerization. So I guess I'm intending this as a fairly technical demo, but talked about from a customer and business perspective.
I personally think it's important for your stakeholders to understand the necessity of this work, and this gives the team the chance to talk about it.
Thanks for bringing up the failure mode of this -- I'll consider adding that to the blog post.
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. If you're in an environment where there is less trust, or the leadership doesn't understand how software should be built, you may need to use the demos to educate and give context on the team's work. It's also important for you to cheerlead the work that isn't customer facing.
And added davidkunz to the Thank you section.
- I could see what portion of the team's time is spent on tech debt issues, which gives me a sense of how well we're dealing with tech debt, the state of testing, and how good our technical decision making are.
- It also gives me an idea of how well the team is dealing with the real maintenance necessary for a production product. Are we improving response times for customers, how hard is it to make improvements.
- It helps me understand team dynamics. How collaborative is the team's work. Who is working with whom? How much support do team members give each other. How much knowledge silos do we have. How does the team treat each other? Do they cheer on this type of work? How do they feel about maintenance.
That's just a few things that come to mind. I have found these demos to be some of the most information rich activities I engage in, and I find it helps me support my teams.
But I get the sense it doesn't feel great to you. What sucks about it for you?
But it’s definitely one of those things that sounds good until you try it across a variety of teams and different projects.
Developers love showing off their work. But regular demos create expectations. Software always becomes primarily about expectation management.
Early on progress is rapid and there is lots to show and people like showing it.
Then things slow down and you refactor, fix bugs, and you’re left demoing tiny things or with nothing visible to demo.
But you’ve created expectations of consistent delivery of visible features, and non-technical people don’t get it. And the chain of EM and PM don’t want to tarnish their reputation so they will get teams to hack things for a demo. Code quality suffers, and you are piling on tech debt.
Better: let teams demo things when they are ready to demo. Don’t have a blocked out time for it either. Then it always becomes: “so who is ready to demo?”…and if you’re not you are failing and then it’s a competition with other teams.
Constant iteration and demos are good to make sure you are doing the right thing, but not on a public scheduled interval.
It’s scary how many management concepts that come naturally to new engineers are actually terrible ideas in team/political settings. I think we are too used to dealing unemotional machines…
So much important work is not really possible to demo in a way that most people understand or see the gain it gives either.
I think, from previous experience, that demo-driven development sort of works if you are a company or project in the start up phase, because there are a lot of stuff to demo and the development goup(s) can get quite a boost from the excitement it generates.