12 ms·

Demo-driven development (2021)

• tkiolp4 3y ago
  So much ceremony. Suddenly programming feels like work.
  • cjhowarddev 3y ago
    Programming is work for most of us, so that makes sense.
  • DragonStrength 3y ago
    As my father in law would say, they don’t call it work because it’s fun.
  • dools 3y ago
    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.
  • bazoom42 3y ago
    Is someone paying you to do it?
    • ranting-moth 3y ago
      "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.
      • bazoom42 3y ago
        My point is - if you are not getting paid, you can just decide not to do things you dont feel like. But if you are an employer getting paid, only an insuffereable primadonna would object to a reasonable task because it “feels like work”.
• stefan_ 3y ago
  Begging people to realize not everything that involves development is also web frontend or app development.
  • jadeforrest 3y ago
    From the article: 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.
    • stefan_ 3y ago
      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.
  • swsieber 3y ago
    I'd love examples for things I can wrap my head around.
    • alex_lav 3y ago
      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.
      • sarchertech 3y ago
        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.
• quelsolaar 3y ago
  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.
  • awesomeMilou 3y ago
    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.
    • quelsolaar 3y ago
      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.
      • awesomeMilou 3y ago
        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.
• knallfrosch 3y ago
  That's just Scrum/Agile? (I know, those are fuzzy terms.)
  • aero142 3y ago
    It’s a good version of scrum. There many more bad scrums.
  • downrightmike 3y ago
    Its basically just sprint demos. I wouldn't do them every week, monthly is fine.
• 29athrowaway 3y ago
  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.
  • downrightmike 3y ago
    You'll need a new bucket for Software Version: Never
  • em-bee 3y ago
    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.
• cjhowarddev 3y ago
  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.
  • pylua 3y ago
    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.
• p1necone 3y ago
  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.
  • pylua 3y ago
    Right , not to mention that often times non technical stakeholders may be confused about the amount of progress that has been made.
    • edvinbesic 3y ago
      That seems like more of a communications issue rather than a technical one.
      • FridgeSeal 3y ago
        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”.
  • Lutger 3y ago
    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.
  • sillyfluke 3y ago
• foobiekr 3y ago
  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.
  • pylua 3y ago
    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 .
    • foobiekr 3y ago
      Yes, I think this is also true but very sector dependent. In embedded it's mostly not true.
• pylua 3y ago
  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.
  • em-bee 3y ago
    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.
    • pylua 3y ago
      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 .
      • Lutger 3y ago
        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.
• lph 3y ago
  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.
  • brutusborn 3y ago
    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 3y ago
      [deleted]
    • Lutger 3y ago
      Office politics.
      • brutusborn 3y ago
        Like a manager forcing you to make the sexy bits first so the demos look nice?
• dools 3y ago
  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.
• NotGMan 3y ago
  This 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.
  • ranting-moth 3y ago
    I like this, but it's much more like a user/usability testing instead of a demo (with demo as a side effect).
• ranting-moth 3y ago
  I think this will make the devs dangerously focused on the more visible features.
• simne 3y ago
  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).
• XCSme 3y ago
  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. [0]: https://uxwizz.com/blog/docs-driven-development https://uxwizz.com/blog/docs-driven-development