Hacker News Reader

Comment by DerDangDerDang | Hacker News Reader

Set the expectation that everyone will demo their work sometime around half way through the sprint. That way everyone knows they’ll be showing something and so will have to think earlier about how ‘done’ they really are, what visible progress they’d like to be able to show, etc. But there’s no expectation anything will be more than half finished at demo time, reducing stress and giving early visibility.

View on HN

This is a very good idea and fits with what immediately came to my mind; things need to be "proven" or "working" way before the end of the sprint so there is time to refactor, refine, and improve quality.

To the OP, think spikes: https://en.wikipedia.org/wiki/Spike_(software_development). Very important with a lot of unknowns. Doubly important for new engineers because.. Well, sounds like they are dealing with a lot of unknowns.

Works only if the work is frontend though. With backend work, there’s usually not a lot to show unless you specifically optimize for making a demonstratable prototype a specific deliverable, which to me seems like just a distraction and missing the overall goal.

Absolutely!

Why? If you're backend, show that things are working in the backend, not much different than frontend work. Or show your design work. Or video editing progress, or anything. If there is _no_ progress but in your head, at least what you can do is write it down. Then you end up with a document. Demo your document.

And yeah, if it's missing the overall goal, then it's clear halfway through that we're missing the goal, so you can correct earlier.

I see this argument a lot from folks who never worked in the frontend. Having worked in both it's much clearer there are always ways you can demo changes in a backend. You can show new docs made available or before/after performance numbers of simply just describe what would now be possible for clients.

No matter what you work on there _has_ to be a way to show the impact you had unless you had no impact.

Lots of ways to demo a backend. Are you doing REST? Postman to show the API functioning. Have tests, show the test suite. The person writing the backend needs some way to drive it to test their own work this should be demonstrable to a technical audience.

I agree with the siblings that this isn't true. I've recently finished a big refactor of something entirely back-end with almost no user-visible changes at all (except ahem for a bug I wrote), and I could still present progress. The work was the migration of six or so different components: they used to conform to one API, and I moved them to a different API. I found a way to order the changes so that they could be done sequentially rather than big-bang. Bam: a clear progress marker.

This kind of progress is pretty common, in my experience. I've already written about defunctionalising an algebra before (https://www.gresearch.co.uk/article/defunctionalisation/), and that is another example of a task where the work can often divide itself into discrete chunks. You can show your progress to your team, all without the end-user being able to see anything.

Reply on news.ycombinator.com