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.
Comments
This is an anti-pattern.
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.