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.
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.
I feel like this falls into the bucket of “if people using a tool always end up doing bad practice X or running into problem Y, maybe they’re not holding it wrong, maybe the tool has issues”.
>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.
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.
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.
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.
It opens you up for abuse is what I was trying to say. You need competent leadership to implement something like this. If that's a given, it sounds like a great work environment!
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.
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.
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.
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.
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.
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.
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.
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”.
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.
As I said elsewhere, sure you can make an engaging backend demo, just like you can make an engaging hacking scene in a movie. It’s just a lot harder though than making an engaging chase sequence.
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.
> 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.
1. That completely ignores my first point, that engaging backend demos are inherently more difficult.
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.
> 1. That completely ignores my first point, that engaging backend demos are inherently more difficult.
: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.
Whilst I agree with you, there’s a definite frustration of demo-ing some complex backend work or bug fix and having PM’s eyes glaze over because your massive effort improving the infrastructure simply isn’t as shiny and easy as FE change. Got graphs? They don’t care, that’d mean they’d need to understand and that’s haaaaaard.
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.
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.
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.
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.
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.
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.
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 .
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.
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).
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.
"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.
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.
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.
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.
thank you. it is interesting to see the difference in mindset about this. a few weeks ago i was talking with some people at a developer meetup, and they all insisted that doing anything but hourly billing would be stupid because why would you take that risk.
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.
You definitely want the client to manage their own budget, but sometimes they are incapable. I would suggest to avoid those clients, even if they pay more.
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.