16

Not really a programming story... but a story about how programmers problem solve in real life.

Mods, sort me out if I'm out of line. Anyway, here goes.

So, my wife and I are arguing about whether or not the garage has insulated walls.

"It doesn't have insulated walls", I say, "I've been up in the rafters and their's no insulation there, so there's probably none in the walls."

"Well, why can't you just check", my better half responds, "You could just punch a hole in the wall to see."

Me, taking about 300ms to process this statement. Looks over, and punches a hole in the wall.

"See, no insulation!!!" I say triumphantly.

"What. The. Fuck. Did you just punch a hole in the wall for???"

deerinheadlights.gif

"Um, because you told me to?"

"Well I didn't mean to use your hand, I meant to get a small drill so the hole wouldn't be enormous."

"Well you didn't say "get a small drill", you said "punch"!

And as a laid down to sleep, on the couch, that night I still insist she told me to do it. And while I patched that hole, I still thought it was her fault. And to this day I still think it's her fault.

You cannot give a programmer these vague instructions and expect appropriate results.

Comments
  • 7
    Assumptions don't always help

    If in doubt, don't look intelligent. Just ask
  • 12
    Ah, rule 1 of programming. Never act on requirements, request finer details!

    This is a classic case of requirements not conveying expectations. This happens a lot.
  • 7
    It's not a wall if you can punch through it
  • 0
    What the f do you have for walls? Cardboards? If i were to try that with a german wall i wouldn‘t break the wall but my hand.
  • 1
    @C0D4 in this case he already tried reason. When the client is beyond reason eventually you have to just give what it wants and let the client deal with the fallout.
Add Comment