Background
I started programming at the age of twelve thanks to a close friend of the family who gave me a certificate for a Radio Shack computer course. I was lucky that the local store liked the idea of having a twelve-year-old programming their computers because it showed how truly easy computers were to use. Since that time, I have spent every day (except for a handful of vacation days when I was forbidden to bring a computer with me) programming or otherwise developing software at some level. I think this explains the warped view of the world I am so often credited with.
Now, more than twenty years and many hundreds of thousands of lines of code later, I get a chance to share a piece of what I find important. I have been amazingly lucky to learn from plenty of smart people, both colleagues on projects and students in various training courses I have taught. During this process I have learned lots of techniques and approaches—some of them helpful; some I had to unlearn. Certain key techniques, once internalized, changed my view on software development as a whole.
In 1994, I was working on an embedded pen-based system that was intended as a specialized notebook-size form entry device (much like a larger-size Palm Pilot). This was one of those many technical projects that met its objectives but never really achieved the market space it needed for commercial success. At that time I started to notice several idioms or common techniques that I had used and that had been used in other systems, both at my current company and at other companies I had worked for. We spent a while trying to come up with ways to document and refine the techniques.
It was at this point that a friend directed me to the patterns work being compiled, and I delved into this area, exploring the work done by Christopher Alexander and others. I discovered that not only did these patterns address the same type of things we were doing, but they opened my eyes to a whole new way of looking at problems and understanding system architecture as a whole. I also discovered many things I had done wrong in the past and finally understood why some of our previous efforts had failed. I resolved not to repeat those errors and to come up with ways to share this knowledge with others.
Let's jump right in. Let me show you one of the first patterns I wrote and one that forms one of the key tenets I try to use when designing any software system. I'll present it here quickly. Later, I'll explain the key sections of the pattern and show its application throughout the book. However, I think it is important to understand that whether you agree with it, a pattern forms a picture in your mind, conveying the key concepts and application in a readily accessible manner.
Pattern Name: High Road Development[1]Problem How do you handle existing requirements efficiently in the face of changing and future requirements? Context Developers build or extend a system. Forces
Solution Never write any unneeded code in the implementation; instead, transfer the effort to design. Ensure that the architecture can handle all potential scenarios (realistically, as many likely ones as possible). This is a rather lofty goal, but movement in this direction is essential. Rather than hardcode in code that is rigid, utilize design patterns and other mechanisms to allow the system to expand through additional variations rather than through change. In addition, avoid the use of any stub code or other placeholder where an additional level of indirection and application of a pattern can allow the solution to be more readily solved. Resulting Context What results is a system that meets existing requirements and is capable of addressing future requirements when necessary. The cost of adding these new capabilities is often less than if an up-front effort had been made. This is especially true when we don't know up front the exact requirements (otherwise we might have done it initially), so our up-front efforts are often wrong or result in development toward a less optimal design. One area to watch carefully when applying this pattern is the resulting potential increase in design complexity (although not always coding complexity). Rationale By shifting the focus from implementation to design, we can solve higher-level problems more effectively and often dismiss the problem entirely. Often the features that the system is supposed to handle are never implemented, and other features come into existence because of market forces. Normally these new features can be easily handled since the architecture has been made extensible. Aliases Build for Today, Design for Tomorrow Known Uses This pattern has been applied to several large frameworks that I developed. One example is Total Commissions Systems (TCS), an enterprise-level commission calculation system. In this specific system, the application of this pattern allowed us rapidly to redesign the core calculation portions between Versions 1 and 2 to decouple the hard coding to a plug-in architecture. This change took a matter of days and avoided significant ripple throughout the system. |
[1] Steve Berczuk suggested the great alternative name, High Road Development, pointing out that noun phrases for patterns are normally far superior than my earlier verb-phase name, Build for Today, Design for Tomorrow
SIDEBAR: Refactoring and Extreme ProgrammingRefactoring [Fow, 99] provides an alternative approach to using this pattern, and, if a sufficient testing framework exists, it can be utilized successfully. A fundamental idea in refactoring is to focus on simplifying design and to provide an environment for continual evolution (rather than extension) as new requirements emerge. When an approach that is based on refactoring is used, a development approach, such as Extreme Programming Explained: Embrace (XP) [Bec, 00], should be considered. From a very high level, XP is a team-based approach in which the division between the different cycles blurs because of an extremely reduced time frame for each phase. This approach is just beginning to gain some attention (although similar processes including RAD and Just In Time programming have been used successfully for many years). XP seems to work well for in-house projects in environments of high risk and change where standard processes may fail. I think it also works best with teams consisting of more junior programmers. This is a very controversial approach, and I'm still at the investigation stage of this process. I have found much with which I disagree, mainly because of environmental issues in the type of development I've observed, but I enjoy anything that makes me question what I thought I knew. I highly recommend learning about this approach. Beck's book [Bec, 00] is an extremely quick read and raises several questions about the process of developing software. Regardless of the process or specific approach used, the approaches discussed in this book should be fundamentally considered when building any software systems. |