Live data from Hacker News

Demo-driven development (2021)

rubick.com

61–64 of 64 posts

Re: Demo-driven development (2021)

#61

Earlier quoted context omitted.

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 place…

> 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.

Re: Demo-driven development (2021)

#62

Earlier quoted context omitted.

> 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 d…

> 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.

Re: Demo-driven development (2021)

#63

Earlier quoted context omitted.

Is someone paying you to do it?

"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.

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”.

Re: Demo-driven development (2021)

#64

Earlier quoted context omitted.

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.

Post reply on HN