Hacker News new | ask | show | jobs
by jowdones 2796 days ago
>> break the build... disable failing tests (under pressure)

This is the norm in the software industry. As grunts or lower management getting tasked with the impossible, saying "yes" and doing "maybe" is really the only way. What they (upper management) gonna do, fix it themselves?

1 comments

How about not releasing a software update until catastrophic bugs are fixed?
Sadly, when one gets away from open source development and sees "enterprise" and/or "government" (a subset of "enterprise") development, what one finds is that everything is almost exclusively "deadline date" driven. The PM's and/or upper level managers pick dates for deliveries (seemingly often without regard to ability to achieve deliverable X by date Y) at the start of any dev. cycle. The end result is the low level managers get pressured to "meet the date" and so the developers get pressured to go faster to "meet the date" with the result that often the deliverable X "meets the date" but is very buggy, hacky, ugly, hard to further extend, etc.

And then, of course, for the PM's and upper management layers, the fact that their project "met the date" is what is measured and congratulated all around. The product could be a stinking pile of XXXX, but "it met the date", so they get their kudo's, their bonuses, and the devs. and users are left with "stinking pile of XXXX".

As a PM I remember the halcyon days when my management would actually request a formal estimate and I would then work with delivery teams to calculate an answer and then add the traditional 50 to 100 pc buffer because I knew they were full of crap/I kept a personal record of their history of estimate vs reality. Nowadays management are in to top down planning so they don't ask for estimates, they don't add realistic buffers so they over promise with one hand and underestimate with the other. Seems to be a trend where everyone thinks they know how to do a PM's job.
And a stinking pile of XXXX is exactly what we end up with. Telemetry stuffed, file deleting bug ridden pile of fucking shit.

About ten years ago I had the option of taking the red or the blue pill. I took the Windows pill by mistake.

Yeah but on the other side if you just let engineers do everything "the right way", we'll never deliver anything because there's always a "better" way to do it. I agree that "success-based planning" is ultra bad, but engineering needs to be held to some level of accountability.

Or maybe I just blame capitalism, haha. No deadlines! I do this because I like it!

So this what happened to Evernote.
I bet they never tested that case.

Yes, they should have. adding tests long after the fact is next to impossible because, when you spend a long time not adding them, your codebase tends to degenerate into an untestable mess. One of the key benefits of strict TDD is that you feel the pain of testing your code before you write it, so your code is testable from the start.