“That’s the End of the Book, Now Here’s the Meaning of Life”
Well, the meaning of Python, anyway. In the Preface of this book, I promised that we’d
return to the issue of Python’s roles after seeing how it is used in practice. So in closing,
here are some subjective comments on the broader implications of the language. Most
of this conclusion remains unchanged since the first edition of this book was penned
in 1995, but so are the factors that pushed Python into the development spotlight.
As I mentioned in the Preface sidebar, Python’s focus is on concepts such as quality,
productivity, portability, and integration. I hope that this book has demonstrated some
of the benefits of that focus in action. Along the way, we’ve seen Python applied to
systems programming, GUI development, Internet scripting, database and text pro-
cessing, and more. And we’ve witnessed firsthand the application of the language and
its libraries to realistically scaled software development tasks, which go above and be-
yond what many classify as “scripting.” I hope you’ve also had some fun; that, too, is
part of the Python story.
In this conclusion, I wish now to return to the forest after our long walk among the
trees—to revisit Python’s roles in more concrete terms. In particular, Python’s role as
a prototyping tool can profoundly affect the development cycle.
“Something’s Wrong with the Way We Program Computers”
This has to be one of the most overused lines in the business. Still, given time to ponder
the big picture, most of us would probably agree that we’re not quite there yet. Over
the last few decades, the computer software industry has made significant progress on
streamlining the development task (anyone remember dropping punch cards?). But at
the same time, the cost of developing potentially useful computer applications is often
still high enough to make them impractical.
Moreover, systems built using modern tools and paradigms are often delivered far be-
hind schedule. Software engineering remains largely defiant of the sort of quantitative
measurements employed in other engineering fields. In the software world, it’s not
uncommon to take one’s best time estimate for a new project and multiply by a factor
of two or three to account for unforeseen overheads in the development task. This
situation is clearly unsatisfactory for software managers, developers, and end users.
The “Gilligan Factor”
It has been suggested, tongue in cheek, that if there were a patron saint of software
engineers, the honor would fall on none other than Gilligan, the character in the per-
vasively popular American television show of the 1960s, Gilligan’s Island. Gilligan is
the enigmatic, sneaker-clad first mate, widely held to be responsible for the shipwreck
that stranded the now-residents of the island.
1544 | Chapter 21: Conclusion: Python and the Development Cycle