Re:The Art of Failure (2000)
by tom_rath on Saturday August 01, 2009 @01:06PM
(#736417)
From what I've seen (and felt!) one might be facing a really nasty bug which has caused a sudden crash in a production environment which is holding up many hundreds of very angry customers. Some yelling may have occurred.
You know you should sit back and reason out what the problem might be (it worked before -- what's gone wrong?) but the rookie reflex is to start coding right away and to slap something -- ANYTHING! -- in that might make things right. That should make the yelling stop!
When that doesn't work, another patch is put in. Then another, and another, corrupting data and making things even worse!
...and so the cascade of 'Hail Mary' programming fixes is put in place until someone finally pulls the plug and yanks the poor, choking programmer aside for a breather.
It's rare for programmers to have a 'do or die' moment and few are prepared for or recognize it when it comes. If you ever feel the urge to rush: Don't.
Re:The Art of Failure (2000)
by jacquesm on Saturday August 01, 2009 @06:09PM
(#736741)
> If you ever feel the urge to rush: Don't.
That ought to be printed out in 122 point font and pasted on every wall behind every monitor. Take your time to do it right, that way you don't have to do it 'n' times but only once. A quick fix usually only leads to more trouble down the road.
Re:The Art of Failure (2000)
by fuzzythinker on Saturday August 01, 2009 @10:12PM
(#736969)
It's not that simple. It usually depends on the criticality and severeness of the bug. You have to weight the quick fix (if any) against the consequence of not acting on it NOW and any guesstimates of side effects.
Re:The Art of Failure (2000)
by neilk on Saturday August 01, 2009 @02:26PM
(#736497)
I'm not sure this quite applies to programming as done by programmers. Gladwell is talking about conscious processes interfering with unconscious processes. For us, pretty much the whole thing is conscious.
You could think of the entire organization as the athlete though. Especially in programming, the organization is unaware of exactly how things really get done, it just has certain reflexes. Under crisis it may feel the need to switch modes.
Panic: OMG the project is late! Hire more programmers! Buy someone else's thing and try to make it work!
Choke: What we're doing isn't working -- we need to hire a lot of consultants, we need more metrics before making a decision, we need to carefully plan out our scaling strategy before we make a prototype...
Re:The Art of Failure (2000)
by jsn on Saturday August 01, 2009 @12:52PM
(#736409)
The most epic of my chokes probably was on icfp contest of 2007. Plenty of pressure, tight deadlines (icfp contests take 72 hours). There was a hard to reproduce bug in my fast dna vm implementation, and it took me like 18 hours to find that one wrong line. I think "stuck in debugging" usually means choke.
As for panic, that's more of a sysadmin thing, imo. When a RAID fails to come back after a power failure on the production server, it does take some guts to not start making random stupid moves.
Re:The Art of Failure (2000)
by neilk on Saturday August 01, 2009 @02:28PM
(#736499)
Stuck in debugging means get someone else to help. However, if that is part of your normal pattern and you didn't do that in the ICFP, maybe that was a sort of choke.
Re:The Art of Failure (2000)
by DTrejo on Saturday August 01, 2009 @07:22PM
(#736825)
Tennis has very strange scoring.
It's complicated to explain, but here goes:
The first person to get 6 games wins the set.*
The first person to win 4 rallies in a game wins that game.*
During a game, if you have one point your score is "15," two points is "30" and three points is "40." When you get four points or win by two, then you win the game.
You know you should sit back and reason out what the problem might be (it worked before -- what's gone wrong?) but the rookie reflex is to start coding right away and to slap something -- ANYTHING! -- in that might make things right. That should make the yelling stop!
When that doesn't work, another patch is put in. Then another, and another, corrupting data and making things even worse!
...and so the cascade of 'Hail Mary' programming fixes is put in place until someone finally pulls the plug and yanks the poor, choking programmer aside for a breather.
It's rare for programmers to have a 'do or die' moment and few are prepared for or recognize it when it comes. If you ever feel the urge to rush: Don't.
That ought to be printed out in 122 point font and pasted on every wall behind every monitor. Take your time to do it right, that way you don't have to do it 'n' times but only once. A quick fix usually only leads to more trouble down the road.
You could think of the entire organization as the athlete though. Especially in programming, the organization is unaware of exactly how things really get done, it just has certain reflexes. Under crisis it may feel the need to switch modes.
Panic: OMG the project is late! Hire more programmers! Buy someone else's thing and try to make it work!
Choke: What we're doing isn't working -- we need to hire a lot of consultants, we need more metrics before making a decision, we need to carefully plan out our scaling strategy before we make a prototype...
As for panic, that's more of a sysadmin thing, imo. When a RAID fails to come back after a power failure on the production server, it does take some guts to not start making random stupid moves.
Eh, what?
The first person to get 6 games wins the set.*
The first person to win 4 rallies in a game wins that game.*
During a game, if you have one point your score is "15," two points is "30" and three points is "40." When you get four points or win by two, then you win the game.
*One must win by two.