Comment by l0b0 | Hacker News Reader

Comment by l0b0 | Hacker News Reader

Parent Full thread

I'm sure Dijkstra could get away with saying that, but how would you phrase something equivalent to someone above you in the food chain without getting nuked from orbit in response? I can just see how the conversation would go:

PHB: You've only added two lines - why did that take two days!

Dev: Because it took that long to understand the requirements, understand the code, find the root cause, write a test to verify the root cause, and then 2 minutes to write the code to fix it. The resulting code verifiably fixes the root problem for at least reasonable inputs, with minimal code and thus minimal chance of a bug.

PHB: Why not add 50 lines of code and be done in an hour?

Dev: Because that would be enormously more likely to be buggy.

PHB: But it would fix the symptom, right? Don't let perfect be the enemy of the good!

Dev: 50 lines would not to be "good", it would be crap. And we would have to revisit that code in a week or a month.

PHB: But in the meantime we will have delivered, dammit! We're on a deadline, with three managers and five customer representatives breathing down my neck, and you're telling me you want to spend two days on something you admit could be fixed in an hour?

Dev: I never said I could, only that 50 lines would be a crap solution.

PHB: Are you calling me a liar? Or just an idiot?

[Continue until the developer is fired or gives in, loses hope in humanity, and starts planning their exit.]

Thankfully I have never worked with someone like that, but if the starting point is as bad as the first sentence above then it's only going to go downhill from there.

Yea, but then you see two idiots spend countless weeks “perfecting” things that don’t matter. Shipping matters. Customers don’t care about the fires behind the scenes, they care about bouncy pixels. The PHB meme has to die.

> Don't let perfect be the enemy of the good!

Exact quote from my manger, several times. They just don’t get it. And then a trivial feature takes a month to more or less implement because it’s all built on a toppling tower of crap.

"In our case, we're letting good enough be the enemy of barely tolerable."

PHB: Are you calling me a liar? Or just an idiot?

If situation is that far degraded, the answer is "IDK, does the distinction matter?" And it doesn't: either the PHB is putting words in your mouth on purpose, or couldn't hold 30 seconds of context.

> Thankfully I have never worked with someone like that

Please tell me how to find a place like this?

Not just spent, but every loc written adds a small amount of maintenance cost to the TCO. I find non technical people like when engineers use their vocabulary.

> Don't let perfect be the enemy of the good!

We're going 'fairly functional' versus 'broken'.

I did work in a place like that, and it turns out that hastily writing lots of code to do something yesterday whilst under stress just resulted in a constant turnover of staff, with nobody knowing how any of the millions (literal millions) of lines of code worked, plus duplicate objects and structures and functionality littered throughout the codebase, with the main "technical manager" (a coder himself) just far too busy fire-fighting and frantically hammering into his keyboard to ever inform anyone else in the known Universe how anything he'd ever written actually worked, and berating other developers for bugs resulting from them not knowing how it worked, leading to an introduction of thousands of policies regarding coding and check-in, build and style, all of which were out of date and irrelevant and maintained on an unnavigable website that you were expected to somehow just "know", and then "disciplined" when you fell foul of these many policies. No documented design, specs or anything. Just tonnes of code.

I think the company is going through a slow-motion death spiral as they try to combat this ("let's do design! DOCUMENT! That's the key!") but it just results in deadlock in the stages prior to coding since the "designers" don't know how any of it works, so push garbage onto the coders to "implement", which just gets pushed back as it's nonsense, and nothing gets written. And permanent complaints over how long everything is taking to write and document. So just bullying of the developers with shouting and swearing - that'll get things written, right??

You were also expected to estimate how long things would take to write (eg expand an existing structure) without an understanding of how anything worked, and then held to it. I was literally asked by a "manager" once: "Why do you need to know how it works? Can't you just write it if you've been told what to do?". That sealed the "let's get the hell out of here" at that point.

Meanwhile "management" couldn't work out what was "wrong with the developers". "And why are they all leaving? Why do they not know what these millions of lines of code do without any explanation or time to look at it? They must be RUBBISH developers. We need better developers. Employ more GOOD DEVELOPERS. What? Isn't any of this documented????! It needs documenting right away! Do documentation! Who knows how to document this? Ahhh the developers. Developers - DOCUMENT THINGS.", then "Why is there no code being written? What? Why are you documenting??? It's taking too long! Write code! And document! At the same time even though it's impossible! WE NEED MORE DEVELOPERS! Where are the GOOD DEVELOPERS???! We need to write a new policy that the developers should adhere to."

Always the developers' fault apparently. Absolute stupidity.

Reply on news.ycombinator.com