To be sure, Gilligan’s situation seems oddly familiar. Stranded on a desert island with
only the most meager of modern technological comforts, Gilligan and his cohorts must
resort to scratching out a living using the resources naturally available. In episode after
episode, we observe the Professor developing exquisitely intricate tools for doing the
business of life on their remote island, only to be foiled in the implementation phase
by the ever-bungling Gilligan.
But clearly it was never poor Gilligan’s fault. How could one possibly be expected to
implement designs for such sophisticated applications as home appliances and tele-
communications devices, given the rudimentary technologies available in such an en-
vironment? He simply lacked the proper tools. For all we know, Gilligan may have had
the capacity for engineering on the grandest level. But you can’t get there with bananas
and coconuts.
And pathologically, time after time, Gilligan wound up inadvertently sabotaging the
best of the Professor’s plans: misusing, abusing, and eventually destroying his inven-
tions. If he could just pedal his makeshift stationary bicycle faster and faster (he was
led to believe), all would be well. But in the end, inevitably, the coconuts were sent
hurling into the air, the palm branches came crashing down around his head, and poor
Gilligan was blamed once again for the failure of the technology.
Dramatic though this image may be, some observers would consider it a striking met-
aphor for the software industry. Like Gilligan, we software engineers are often asked
to perform tasks with arguably inappropriate tools. Like Gilligan, our intentions are
sound, but technology can hold us back. And like poor Gilligan, we inevitably must
bear the brunt of management’s wrath when our systems are delivered behind schedule.
You can’t get there with bananas and coconuts...
Doing the Right Thing
Of course, the Gilligan factor is an exaggeration, added for comic effect. But few would
argue that the bottleneck between ideas and working systems has disappeared com-
pletely. Even today, the cost of developing software far exceeds the cost of computer
hardware. And when software is finally delivered, it often comes with failure rates that
would be laughable in other engineering domains. Why must programming be so
complex?
Let’s consider the situation carefully. By and large, the root of the complexity in de-
veloping software isn’t related to the role it’s supposed to perform—usually this is a
well-defined, real-world process. Rather, it stems from the mapping of real-world tasks
onto computer-executable models. And this mapping is performed in the context of
programming languages and tools.
The path toward easing the software bottleneck must therefore lie, at least partially, in
optimizing the act of programming itself by deploying the right tools. Given this realistic
Doing the Right Thing| 1545