Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

web.mit.edu

Post reply on HN
Print view View original

431–440 of 446 posts

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#431

Post by knightofmars »

fer wrote: post #320
euroderf wrote: post #249

Earlier quoted context omitted.

It might be better to keep it low-profile. Go to a superior with the story of "told ya so".

Actually any organisation worthy of the label "engineer" should do a thorough, no-blame, and collaborative post-mortem of such events so they don't happen again, and that would include warnings given. Feature on time + risk, feature late + no risk (and anything in between), it's in the end an engineering and business decision and either choice might be the right one depending on the circumstances.

Absolutely, this is a often ignored or missed aspect of building systems. Quantifying risk in a fashion that all parties have the same understanding of said risk can be very difficult. There has to be a common language and agreed upon thresholds of risk. After developing shared understanding of risk, it's much easier to highlight and change the behaviors of individuals and the teams.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#433

Post by BobbyTables2 »

Asooka wrote: post #113
syndicatedjelly wrote: post #31

Earlier quoted context omitted.

Would you feel good about being that kind of engineer, if the external validation was great enough?

We review each other's code before it goes in. If the team says they're happy to work with it, then I've fulfilled my obligation. I am literally not paid to write the best code in the world. In fact, the company gives bonuses for fixing things, so they are in fact paying me to sneak bugs in. What you do though is, you leave a very obscure edge case unhandled, make note of it, then just don't tell anyone. Invariably s…

I can see how many would object to what you’re suggesting.

However, I’ve also had managers who pushed back against nice-to-have cleanups as the product matured (especially close to a release). They had cause as the product became overly complex, where issues were tedious to root cause and fix.

I tended to queue up a lot of improvements and then unleash them at the beginning of a release cycle.

Later QA would find a problem in the previous release but couldn’t reproduce in the later one… because I had already fixed it.

I didn’t introduce bugs intentionally, and the fixes were visible as we had to backport them for point releases, etc.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#434

Post by x86x87 »

paxys wrote: post #144

Went through this exact scenario at my job recently. As the tech lead/architect of an org I reviewed a bunch of recently released projects and identified areas that needed critical improvements because they had major reliability/performance issues. One team had multiple releases at the top of the list, and their PM and eng manager (and really everyone else up the chain) simply ignored all concerns because they had to…

I can this the "tragedy of software development": the pyromaniacs are the firefighters.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#435

Post by andrewwwalkerr »

I'm curious about views from the crowd here on how to apply the recommendations from this article in the context of a startup

I've worked in both heavy industry (mining /metals production) as well as my own startup for the last 7 years

I definitely empathize with the view that diligently investing in people, and taking time to build sustainable processes that focus on the mid to long term is the ideal way to go... But when your runway is weeks, not months, and it's ship or die, seems hard to justify such a Rosy ideal

Let the debate begin!

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#436

Post by BeFlatXIII »

arp242 wrote: post #21
thfuran wrote: post #9

Earlier quoted context omitted.

There's a ton of reactionary legislation on the books that exists pretty much entirely because politicians wanted to be seen doing something. It's mostly crap.

This is probably a bit too cynical; it's not just "politicians who want to be seen doing something"; the public often wants something done as well. And "we didn't do anything after that incident from ten years ago and now it happened again" is not a good look. Complex stories about trade-offs and the cure being worse than the disease often don't "play well" in the media, especially not with the opposition demanding t…

> the public often wants something done as well

Like many other problems in politics, the root of the problem is the other voters.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#437

Post by Nevermark »

Diagram 5 can be improved.

[Time Spent on Improvement] is shown having a negative impact on [Time Spent Working].

But [Time Spent Working] should also have a negative impact going back to [Time Spent on Improvement].

This simple mutually negative feedback loop, i.e. a competitive relationship, better explains the bistable situation where either [Time Spent Working] reinforces itself, while holding [Time Spent on Improvement] down, or vice versa.

Feedback loops reinforce themselves, but there is only so much time, so there will be a strong tendency for one feedback loops to dominate the time. (And since the Time Spent Working -> Reduce Performance Gap loop operates much faster, cheaper in the short run, and is much easier to reason about and manage, it usually wins.)

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#438

Post by Nevermark »

bryanrasmussen wrote: post #303
zilti wrote: post #274

Earlier quoted context omitted.

> Being reasonable is part of being intelligent Not in the slightest, those two are quite separate.

Well the parent made sort of a case for why being reasonable is part of being intelligent, and your response was to claim there was no correlation without an argument. I happen to believe that reasonableness is part of being intelligent, by the following criteria: 1. when you are reasonable you do not make unreasonable demands that will just be troublesome and cause workflow issues because in the end they are unachie…

Having worked closely with some dramatically different intelligent people, I really think intelligence and reasonableness are very different.

Being reasonable, is being someone with a strong genuine value for collaboration. They actively advocate for and work with others to optimize situations taking everyone's needs into account. Encourage give and take, constructive debates, and appreciate feedback. Etc.

An intelligent person can be all those things. Or none of them - but manifest them enough that, with some spin, they seem reasonable, while actually optimizing the environment primarily for their own long term benefit.

Very intelligent unreasonable people are disasters to work with.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#439

Post by guappa »

vasco wrote: post #337
guappa wrote: post #334

Earlier quoted context omitted.

I've seen management let bad engineers re-do projects from scratch 2 or 3 times. Because they blame bad requirements, poor choice of programming language, and whatever on all the issues that the project has. They eventually acquire enough experience to be able to produce something that sort-of works around the 3rd attempt. But thanks to how good they are at communicating, are considered by management to be good engin…

I mean at some point we just get generic enough that we have to agree on the ultimate fact that at least somewhere in the management chain someone has to actually know enough engineering to recognize good work from just running around in circles. I agree what you say happens but if good work isn't consistently recognized and you think you've worked on your comms, there's not much else to do really.

Incompetent CTO can promote incompetent developers to be leads, so now all of the projects from that team will be done terribly. But the CTO can't go back on his decision because he'd rather waste years before getting a result that works acceptably rather than show that he made a mistake.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#440

Post by crestfallen »

strgcmc wrote: post #208
crestfallen wrote: post #64

My memory is a bit hazy but it's a good story. At one place, there was some important order processing taking place. As is fairly typical, couldn't rely on getting all the required info. Or critically, getting all the required info correctly . Some extra data, slightly missing pieces but enough to work, etc. etc. Some could be pretty gross. We built validation to massage some inputs, modify processing, what have you…

There is a simple but undeniable element of genius to the idea of, instrumenting the number of validations triggered. I would hazard a guess that 90+% of teams would focus on an "order success rate" type of metric and call it a day, instead of a "# of times bad data was handled" metric, which is exactly how you escape this trap of good work going unnoticed. Thanks for sharing! Shamelessly stealing and applying this c…

That's exactly where we started. It worked or it didn't, right? The team was super curious to know, in fact, how many of the edge cases happened. That piece right there had some unexpected value as well. And it grew out from there.

I hope it helps!

Post reply on HN