Hacker News Reader

Comment by grecy | Hacker News Reader

Not only designers and coders, but managers too.

Managers are rewarded and promoted based on everything they & their team "do", not on what they "undo" or "don't do"

So manager x adds 10 things to the website, gets rewarded and moves on, then their replacement adds 10 more things, gets rewarded and moves on etc.

It's in the interests of those managers future careers they don't allow anyone to remove the things that were added during their reign, otherwise the list of things they "did" won't be very impressive.

View on HN

That reminds me of the story which I believe was posted on here (might've been somewhere else) a year or two back about LG TVs and their interface everybody loves - it was a total accident. LG had (might still have, dunno) a program in place where managers got a bonus for every feature they spearheaded which shipped in a product... this resulted in managers from many different teams shoehorning in whatever they could into the 'Smart TV' interface. There were 2 separate 'app stores', multiple inconsistent interfaces, it was slow as molasses, etc. LG acquired the WebOS team and they adapted WebOS to the LG sets just as an experiment... but someone took one of the TVs they had it running on to a trade show... and everybody absolutely loved it because it was simple, direct, uncluttered, and fast. It caused LG a huge problem because it clashed with their corporate policy that encouraged the other bloated interface.

I honestly think that a lot of companies should seriously re-evaluate how they function. Once a product is perfected, the developers should probably be switched over to being paid "on retainer", so that they continue to get paid but do not have to go into work constantly and maintain a 40 hour work week. Let them work from home, and just require them to be reachable. When maintenance is needed, ping them to do it.

I think hardware companies are especially bad at this. When I was young my parents had a colour TV that was 25 years old before they replaced it. Even then it still worked perfectly fine, they just wanted to get a flat screen that took up less room. Now it seems you are expected to replace TVs every couple of years...

Designed failure is clearly a central part of how capitalism presently works for the capitalists - virtually everything I've repaired [domestically] of late has had a tiny part that seemed engineered to fail and take down the whole device.

Case in point - my dad's kettle, the push button to open the lid broke. The tiny plastic lever in the internals that was the ultimate problem had been moulded with material from the pivot removed. There's no way it wasn't designed to fail within a short time period. Add back that plastic or otherwise reinforce that pivot and it would likely work for several more years.

Another example, microwaves: I bought two new, [admittedly] relatively bottom end, microwaves consecutively. Both appeared to fail due to the cyclotron, neither part was available to buy. So instead I got my parent's old microwave from the 1980s. It really pained me to get rid of those new shiny stainless steel boxes, made so attractive to the eye, in favour of the beige-and-brown monstrosity with the working internals.

if you want gear that can last and stand up to heavy use, buy professional kitchen equipment from restaurant stores. plastic consumer stuff is always cheaply built because they compete on price.

this is how we treat homebuilders. and everybody seems ok with it.

I hadn't heard of the LG/webOS story, but it's a good read: https://gigaom.com/2014/08/28/a-failed-experiment-how-lg-scr...

Yap. It reflects not just directly on the product but on the team dynamics.

I have seen this happen at least twice in the past: start with a great team, smart people, self-sufficient. New manager comes in. What does the manager do? Stay by and watch the team do what they do best. Nope, start to set up meetings to improve communication, to streamline, to optimize, adds new rules , new Kanbans, some agile thing maybe, intensify devops a bit. "But why? it doesn't make sensse". Developers are wondering, watching their motivation and productivity get sucked out.

But it does make sense. The manager has a manager. When the end of the year comes, they'll have to report "I did X, implemented Y, facilitated Z etc". They are paid more than the average developer, their know it, the expectations are high. They have to do those things, so that behavior starts to make more sense.

Clearly we work on the same team, at both this job and my previous. Are you me?

Add to this people leave, new people come in and day what the old people did they could do better. A couple years later new people discover why the old people created what they did.

New people either look for new jobs or get into the same cycle as the ones before them.

The odd thing is that when you stay around you can start to see patterns in misconception. People come into a long-lived codebase and naturally fall into the same thought traps, wanting to rewrite the same parts for the same misguided reasons. There is a principle here to follow on a new codebase, that of 'senseless inaction', meaning that as long as something doesn't make any sense to you yet, you should refrain from making deep changes to it. Only once insight is formed on why the seemingly completely pointless and bizarre feature exists and what purpose it is serving, then can a deep change to it be safely considered. Tragically, the natural instinct is to lay off the parts that make sense and to rewrite the parts that don't. That's a guaranteed way to make a product unsuitable for the business it is in, because the weirder a feature is, the more adapted it is to the real world (most of the time).

In general, this 'senseless inaction' idea is known as Chesterton's Fence, and it's a very wise principle.

http://www.chesterton.org/taking-a-fence-down/

Last two jobs I have been at the coder(s) were the ones wanting to refactor, and management just wanted new features, completely ignoring technical debt.

Be careful - you are generalizing which will lead to issues for your interactions with your superiors.

Good managers remove things when they serve no purpose (prevent extraneous development), when they aren't being used (reduce technical burden / debt) because they look at the data, and the changes they make are tied directly to the success of the business.

This assumes a bit of a functional work environment, but if you aren't inside of one, the problem you are dealing with isn't bloated webpages, its bad management.

Reply on news.ycombinator.com