Hacker News Reader

Comment by hinkley | Hacker News Reader

Every delivered feature is a liability not an asset.

If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.

So if I deliver a feature all by myself quickly and move on to something else, I’m digging a bigger hole and faster than the wisdom arrives to change directions.

But most importantly, none of the rest of you fuckers know what I built or why, except what you gleaned from standup or whatever docs I wrote in place of collaboration. And docs written without collaboration are usually hot garbage.

So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.

View on HN

> Every delivered feature is a liability not an asset.

> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain? The one with less shit. Because the rest is just more liability.

You're mixing up the feature and the moving parts.

A feature is an asset. Moving parts (or code) are the liability. They are not the same.

Sometimes you can even improve the product by removing code, or refactoring things so you have less or clearer code while at the same time improving the product. Maybe you unify some UI, so more functionality is available in more places, while also cleaning up the code, maybe reducing line count.

> So what do you all do when I’m hiking in the woods and the cluster is on fire? Sure would be nice if I collaborated on that functionality wouldn’t it? Then you’d have two other people to ask.

It's a fair point, but depends on the scale I would say. Some smaller things can be easily understood (but maybe that's not the stuff that causes the cluster to be on fire). Also, IMO at least one person should have reviewed the stuff, and therefore be at least a little bit knowledgeable about what's going on.

> You're mixing up the feature and the moving parts.

No, you are, and this is why so many of us are shit at UX.

The ability to accomplish a task with software is an asset. Not every application takes the same number of interactions to finish a task, and each interaction is a feature.

Features in neither waterfall, scrum, nor Kanban directly correlate with the ability of the user to accomplish something meaningful. They are units of measure of the developer accomplishing something meaningful, but the meaning is assumed, not real.

> Every delivered feature is a liability not an asset.

> If you don’t believe me, consider two products that make customers equally happy and one has half as many moving parts. Which one is more profitable to maintain?

Wrong analogy, use the word feature in both emphasized terms. Consider two products and one has half as many features, which is more profitable to maintain? Well, it depends whether people are paying for the other half of the feature set or not, as oftentimes people will pay for more features than fewer.

It’s a perfectly fine analogy if you can get over your own ego enough to realize your customers don’t want to hear about how very clever you are, they just want to get shit done and move on to four other tasks.

They don’t care about us. They don’t. They just want to do what their boss asked them to do or kill the bad guy to get the treasure, and we are often enough as much in the way as we are facilitating that.

This sounds like a non sequitur to me, when did I ever say I disagreed with the fact that "they just want to get shit done?" I am not sure what your comment has to do with the part about misconstruing features for moving parts, for those are two independent things, and still more generally, like I said, people do pay for software that has more features than fewer.

Reply on news.ycombinator.com