Gather round, children. I’d like to tell you a story. A
story about a boy named Jimmy.
Meet Jimmy
Jimmy was a sweet young boy from a quiet Midwestern town.
Jimmy grew up loving sports, playing his guitar, and volunteering at the old
folks’ home. Jimmy met Sally, the love of his life, in high school. When he
dropped her off and kissed her good night after taking her to prom, he knew
they were Promised. They’d be together forever. He proposed, after graduation,
and they were wed. Sally was 6 months pregnant when Jimmy had to go.
You see, Jimmy loved his country. He believed in freedom,
duty, honor, and helping people. So Jimmy enlisted to serve his country and
protect those he loved. Mom and Dad were so proud of him. Sally was worried,
but proud of him too. 19 years old, but already he was such a good man.
Jimmy Goes to War
Jimmy joined the Air Force. He wanted to be a helicopter
pilot. To be called on to support the cavalry and save his injured brothers. He
worked really hard, suffered through boot camp and daily struggles with
humility and determination. He made pilot, and everyone was thrilled.
One day, Jimmy was flying routine reconnaissance over the
hills of Afghanistan when the unthinkable happened. A terrorist with an RPG
came out of the woodwork and fired at his chopper. His sensors didn’t pick it
up until the last minute. The rocket struck, and he went into a tail spin. In
shock and trying to recover, he managed to crash the chopper into the soft side
of a hill and escape only with a broken leg and some bruises. He dragged
himself out of the wreckage and found a nearby cave for shelter, praying for
his comrades to come find him.
Save Jimmy!
He didn’t think it would take long. Jimmy’s chopper and
combat suit were equipped with Next Generation Defense Technology. The
technology included location-aware services. In case of an emergency, his
technology should report issues to central command. They would come for him
soon. His life would be saved.
Unfortunately, what Jimmy didn’t know was that his
technology from the very beginning was marginal. The devices that took the
location readings were sometimes flaky, though good 90% of the time. This time,
a sensor failed. But it didn’t fail by just breaking…an electrical shortage
caused its readings to overflow. It kept collecting numbers, but the numbers
were just noise.
No Problem…right?
The programmers who had developed the location based
technology considered themselves pretty smart and capable people. They had a
job to do, and it was their job to get it done as quickly and efficiently as
possible. So when the developer who was working on the geolocation piece found
an article by IBM describing the characteristics of such a system, his task
seemed easy. http://www.ibm.com/developerworks/java/library/j-coordconvert/
All he had to do was just copy paste the code, write some
tests for the common scenarios, and he was done. After all, it was a blog post
on IBM teaching about the stuff. It had to be right. Right?
Not So Fast…
But people forget that tutorial code is often written as a proof
of concept. Most authors themselves adamantly state that they are showing an
idea, but the code is “not production worthy.” But how do you determine
“production worthy?” Besides, this is just some small utility feature in a much
larger system. So nobody thought twice about the LatZones class https://gist.github.com/3251291.
Copypasta, tests written for common workflows that pass, problem solved.
They system was used for a long time by a lot of people. The
Air Force trusted it with soldiers’ lives. During the acceptance testing phase
there’d been some political issues, but officers were able to negotiate an
adaptive solution and get it through, albeit quickly. The system was in place
for a while, and seemed to work. After a while, it became a given, and nobody
gave pieces like LatZones too much thought.
So when Jimmy’s sensor kept throwing negative infinity at
the sensor, and the automated rescue dispatcher that had been introduced into
the system sent soldiers to Zone A, nobody questioned it. They combed through
the area, but found nothing. Confused, nobody could figure out what happened.
The End of Jimmy
Jimmy, meanwhile, ran out of survival rations. Desperate,
hungry, and in pain, he tried to figure out where he was and make his way back
to civilization. When he finally despaired that they weren’t coming for him, he
tried to set off for civilization. Exposed and in the open, he was caught by
the terrorist cell that shot down his chopped. They tortured him, and
eventually killed him.
Who’s to Blame?
The tutorial author, for not writing code that someone else
could just copy and paste from a blog post? The programmer for trying to do a
good job under a tight deadline? The ones rushed the system through acceptance?
Was it just a bit of bad luck, something we can do nothing about?
No
Jimmy didn’t have to die. Jimmy didn’t have to spend his
excruciating last moments in the depths of interminable pain, thinking only of
Sally and crying out to God for release. Jimmy could’ve lived.
How It Might Have Been
A software engineer tasked with developing a geolocation
system may have used the IBM article as a reference point. An informative
source for thinking about the concerns such a system should be able to address.
He might’ve started by copy/pasting pieces, but he would’ve stopped to think
about the different possible control flows of execution. What the potential
values of parameters could be, and should be. He might’ve started writing unit
tests for these combinations, discovered the weirdness of this calculation, and
fixed it.
Alternately, he might’ve come up with an entirely different
design that met the same constraints, without messy double calculations in
tightly bounded ranges. When getLatZones()
got negative infinity, it might return an exception. The system might’ve
tracked such exceptions, and if it noticed they were thrown repeatedly within a
time interval it might’ve used a different strategy, perhaps triangulating
based on historical data.
A software engineer could’ve saved Jimmy’s life.
But It’s Gotta Get Done!
I’m the kind of person who’s OCD enough that I obsess over
this kind of stuff even for my rat fuck website that nobody gives two shits
about. But I know the trade-off between “has to get done so we can survive” and
“optimal”, so I too will cut corners to “get the job done.” That’s just being
human. “Pragmatic,” some might say.
You know what? That’s cool. It’s ok when it’s my rat fuck
little website if I miss two days’ worth of visitor traffic or write out an
incorrect temperature. Sure, I’m not too happy. I missed some revenue or I
looked like a fool. But in the end the stakes weren’t that high.
I’m sure that someone could write a sob story about how the
loss of revenue led to me going out of business; leading to a butterfly
flapping its wings in Japan and Global Warming. I’m sure someone else could
characterize this story as similar hyperbole. But the stakes are different in different
situations, and they matter. If some financial analyst will act like it’s the
end of the world because his report has commas where there should be periods,
and we’re willing to be meticulous to avoid such “disastrous gaffes”, it seems
reasonable to extend at least that level of care to Little Jimmy.
This story might seem extreme. When you Care About Your
Craft and try to THINK about programming, it’s easy to get passionate and
offended--morally offended-- when you see something like this. Being the ones
who build core components of large systems, it’s easy to forget how the system
is used in its periphery. But that is the most important and most delicate
place to be. There’s no place for copy-paste coding in framework development.
Bottom Line
Don’t blindly copypasta you don’t understand when the stakes
actually matter. Treat your craft with at least the same respect and care that
you demand from your short-order cook for your meals. If you’re working on a
task where people’s lives could be on the line, try to remember Little Jimmy.
