undefined | Better HN

0 pointsTameAntelope4y ago0 comments

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe.

And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

0 comments

5 comments · 3 top-level

Trasmatta4y ago· 2 in thread

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever.

Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.

TameAntelopeOP4y ago

If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case.

And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al.

Customer collaboration over contract negotiation. [0]

Who should I listen to; you, or them?

[0] https://agilemanifesto.org/

Trasmatta4y ago

> If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me.

Solve the problem at hand in the way that suits that particular problem best. Don't be a slave to a rigid process. Don't burn out your developers with a dysfunctional system.

Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".

1 more reply

Dudeman1124y ago

>There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe

I took a week to refactor some nasty crap a few months ago. No customer noticed it.

I was rather happy to lower the estimated time for a bunch of other tasks from weeks to days/hours after doing it.

Now you can argue that was not "absolutely crucial", but then we'll just disagree on what that means.

Chris20484y ago

Just off the top of my head: what about legal requirements that a customer isn't liable for?

> I urge you to think about how that work could affect a customer's experience

Why is this the be-all and end-all?

j / k navigate · click thread line to collapse