Hacker News new | ask | show | jobs
by preinheimer 940 days ago
I used to live in Montreal. Cabs there need to get a safety inspection like every 6 months.

Talking to some cab drivers there, many of them remarked that the people doing the safety exam -had- to find something. Your car could have been fresh from the mechanic, they’d find something to complain about.

So, starting about 6 weeks out from their next safety, if something went wrong but the car was still drivable, they wouldn’t fix it. So the safety guys had something to find, and they were going to pay to fix it anyways.

6 comments

One of my earliest bosses was the main web developer for a telco's marketing department. He would get everything working and ready the way that it needed to be, then prior to showing it to marketing would change something to be clearly wrong. In my example, he just put a red line down the middle of one section that looked out of place.

Marketing would review it and say, "Everything looks good, let's just change that red line there. Thanks!"

I asked him why he did that and he said that if he didn't give them something obvious to change, they would find something that was working that didn't need to be changed.

At one point, we (lead dev (me) and lead designer) colluded to submit a terrible homepage design to a nit-picky CMO to buy an extra 2wks of development time.

She'd given us 6wks to completely rebuild a small corporate website, and we knew we needed at least 8 (it was still a nearly impossible rush). She exhibited a classic micromanager habit of the inexperienced: she needed/expected everything, including copy layout, to be pixel perfect in Adobe before any coding could start.

So the developers had the real design we knew she'd approve already in development while the design team showed her the version filled with ducks. She performed exactly as we anticipated and work continued as though she was never consulted. It was a risk, but she was extraordinarily predictable in her duck removal...

It's not something I'd do to someone with an opinion I respect. Thankfully she left right after that. Probably with a story of how she single-handedly saved the redesign herself, but whatever. ;)

I have a friend who works in games who would secretly add a malloc to the initialisation code that would just hold onto a large chunk of memory. Come the point just before release, where everyone was desperately trying to fit the final assets into memory, and about to throw stuff out, he would do an 'optimisation' pass and free up the memory so they could ship without delay.
Oh, "the balloon". A quite common technique.
And Scott Adams also previously worked at a Telco.
That's funny and a good summary
"The problem was that the women who were making the cakes didn't feel emotionally invested enough just adding water, he said. Eggs would make it feel more like baking. In later years, many would portray this as a pivotal moment in the history of cake mixes, the inflection point of a dramatic upward curve."

https://www.bbc.com/future/article/20171027-the-magic-cakes-...

"We love the red line concept! Can you please work that into the rest of the design?"
My boat is for sale. Most prospective buyers will get a marine survey which will identify that among other minor things it needs a new bilge pump.

If they don't pay for the survey I'll sort them out with a new bilge pump anyway.

(This isn't an argument against surveyors though. Mine sorted me out with a new gearbox and had half the boat rewired at the vendor's expense)

This is how it is in some motorsports series as well. I had a teacher who was a mechanic for a racing team. They'd leave something 'big' broken for tech so that the people would find it, have them fix it. He said they'd miss a bunch of smaller stuff, but would feel accomplished for finding the 'big' error.
It's bad but I consider doing this for code review sometimes.
This reminds me...many graphic designers knows to have a bad version of a design. What they do not expect is the customer picking that one. It explains some campaigns though
It's not just graphic design. It's customary in military planning to give the commander multiple possible courses of action or COAs to choose from or blend together. But it's a known danger when you're crunched for time that if you plan a "throwaway COA" that's subpar or silly because the boss wants X COAs and you can only come up with X-1, beware. Because there's a chance the boss is going to moth off on the throwaway COA.
I tend to do this in code review. But what I consider critical is that it comes without a "I want this changed" mentality, and instead a "let's find something we can improve on for next time" mentality. The current PR can go in as-is, but we should aim for always getting better at the craft.
I have this same problem with a lot of review culture at many companies. Turns out, if you send people into a meeting with the idea that they will be criticizing something, they will find criticisms. The hard part is distinguishing things that need changing, versus musings that are as much evidence that the team was looking.
Another example of "what you measure is what you get".
And because they keep finding those obviously wrong things, the program justifies itself!