3.13 Glancing Backward, Looking Upward

Now that was a journey through the valleys and peaks of modularization! I started with a simple solution to what seemed to be a very simple request. I ended up with a very generic, well-structured function that handles the simple request and many others as well.

Along the way, I applied many best practices of recommendations for module construction (some of which are covered in Chapter 2, Best Practices for Packages , some of which are discussed in Oracle PL/SQL Programming ). With each successive change to twice (and then repeated ), I took another turn up along the spiral that represents the rise in quality of my PL/SQL coding techniques. At the end, I had a polished function with proven performance and wide applicability. Take a look at the final version of my repeater function (the dup package). Could you have ever predicted that endpoint from the first version of the twice function? I certainly could not have. In fact, when I started this chapter, the repeated function looked quite different from the way it does now. I found many improvements to make from my first progression of twice (a thorough improvisation performed "live" during a class in Tulsa, Oklahoma) as I "rationalized" the code into an chapter.

And so we come face to face with one of the most extraordinary characteristics of the programming spiral. It's not like a Slinky. That toy has the right shape, but it also has a beginning and an end. The spiral for developers has a beginning (though you would probably have to make an arbitrary choice to locate it), but it certainly has no end. You can always find ways to improve your code, your coding philosophy, and your quality of programming life.

So the next time you sit down to write a program, don't settle for "getting the job done." Instead, push yourself up that spiral towards excellence.