Hacker News Reader

Comment by Tade0 | Hacker News Reader

Sounds eerily familiar, especially "People choose what to work on.".

You can't have that for the whole team in the real world. There are tasks which are universally unpleasant. Usually this devolves into one guy (the one who "ships" the most so is favoured by management) picking the best, most "shippable" tasks and the rest getting what's left.

That's because what this philosophy does is it turns what was supposed to be teamwork into some kind of weird competition over who shipped the most.

And contrary to popular belief when people compete instead of working together the outcome is usually worse.

I know one company that implements very similar rules and while they do make good money, they ship unmaintainable crap. Fortunately for them there's a niche for that as well.

View on HN

I've heard that Facebook's culture has these same incentives. Ship more, even if it's crap-quality code, and you'll be favored.

I understand what this is like, and it sucks. Everyone else is left picking up the broken pieces of what the "superhero" built.

To be devils advocate, I've seen many "anit-superheros" of maintainability do months of work and not end up with an objectively "better" body of code. Often it's just different, and sometimes slower hard harder to extend due to premature abstraction.

There isn't an easy answer here, but incentivizing speed of iteration (aka shipping) has several benefits, both to getting value to customers as well as to architecture and maintainability of the code.

I think that most of those people are not familiar enough with the system that they are complaining about to understand why its so complex.

I have been involved in paying off many kinds of tech debt, and I see a lot of people scream maintainability and then realize the problem that the horrible thing solves is itself a horrible problem.

If you can fix it, fix it, if you think its going to take months to years of work to fix it to be maintainable the truth is likely you never will.

Any product that is static long enough for you to do this is probably not making enough money to justify the cost of doing that kind of refactor except as a hobby project (or was really well designed in the first place, or is a literal hellscape you should let die.)

I totally agree with that, but I'm not sure I agree it's playing devils advocate. By which I mean, I don't think we're disagreeing here. They're both real things that happen:

1. People rushing out crap code and not taking responsibility for cleaning their mess.

2. People trying to clean up code, but doing a poor job for various reasons. (Incompetence, lacking sufficient domain-knowledge at the start, bogged down by organizational problems, etc.)

The problem in each case is people either lacking the capability or desire to do excellent work. "Ship fast or write decent quality code" is a false dichotomy.

"who shipped the most"

And how do you measure that - LoC, tickets, elapsed time, amount of time talking about it, executive weighting....

Perception by management

You’re both right

The granularity of choosing what to work on also has to be the granularity of ownership.

If individuals choose what to work on, then individuals have to be responsible for owning the things they've built. Doing support, doing maintenance, being accountable for problems. If you let people cherry-pick the fun bits and then leave the crap to someone else, then you're doomed, as you say.

I work on a team like this. It's pretty weird, having come from classical XP teams where the team as a whole makes decisions and owns the code collectively. I don't think it's better. But it does work.

Yeah, there are some perverse incentives in both of these approaches.

We had a classic "glasses salesman" story going on here.

The story goes like this: there was a store that sold prescription glasses which had a few salespeople.

One was consistently better than all the others, so management took note and wanted him to teach the others.

Turns out that what he did was to observe people coming to the store and only approach those who looked rich, going as far as distracting the other salespeople so that they wouldn't get a chance.

These rules aren't for regular people, they are for rich coders. "Lean In" wasn't for everyday housewives, it was for rich executives.

That's the pattern.

"making good money" is the goal of a company.

Humans locally minimize entropy, sometimes in exchange for fulfilling an objective function or following some optimization gradient (profit).

It's nice when it works out and we leave things behind in better conditions than we found them, but that's not what the universe is playing at. Nor is it necessarily a/the goal.

It's weird how this all works, and how short a time we have to affect it. It would be nice if everything we made was good and worthwhile, but it's hard to know where things are even going to wind up, and if our investments in making certain things better will pay off. You have to consider opportunity cost when making improvements.

(This pandemic is really screwing up my sleep schedule.)

Of course it is, but you can go about this the smart way or the less smart one.

I for one voted with my feet, because I judged this particular approach to be shortsighted.

At the top level, yes. The incentives at various points in the organization are significantly more complicated though.

The relationship between what engineers want and making money is less strong than most would care to admit, for example.

Reply on news.ycombinator.com