Mind Map Articles |
|
Index Index Articles Download Registration Sub vocalization Wide your span eye Words games
|
Changing The Hand You`re Dealt: Better Designs Through Problem Redefinitionby Payson Hall For many of us, design is the most enjoyable part of software development. Oh sure, debugging can be fun and it is wonderful when everything comes together at the end, but if you`re like me, you prefer to spend a little more time "up front" during design to minimize the complexity of debugging and maximize the likelihood that it will all come together. Design is the all-too-brief period during an application`s evolution when we consider what we want to create and speculate about how we want to do it but are not yet fully committed to any particular approach to the problem. A shortcoming of some of the best programmers I know is the tendency to minimize this "pre-coding" thinking time and begin implementing the first viable solution that occurs to them. The trouble is that there are several ways to solve most problems, each exhibiting various levels of efficiency, ease of implementation, maintainability, and portability. If a designer stops with the first design that "works," there may be a needless sacrifice of quality. In this rush it is easy to confuse a functional design with a quality design. The distinction can be subtle, particularly if both are implemented professionally, because both will get the job done. The difference in development and maintenance costs, however, can be remarkable. "Wait!" I imagine you thinking as you read this. "The `Best` is the enemy of the `Good.` If we worked until we had the perfect design, we would never accomplish anything!" Wise words, but frequently applied prematurely to software design. As a profession, software development seems to be in little danger of overemphasizing design or seeking perfection. This article focuses on an aspect of the problem definition portion of the design process using two examples--a parable and a program fragment--that illustrate how seemingly small changes to the problem definition or representation can have a simplifying effect on the solution. Redefining the Problem From the perspective of the system developer, complexity is the enemy of the development process. There is a limit to the amount of complexity that any of us can deal with effectively, and when our capacity is exceeded, system quality is a frequent casualty. One goal of the skilled designer is to minimize solution complexity in order to maximize the quality of the resulting system (by "quality" I mean a system that can be developed efficiently; meets its requirements; and is reliable, portable, and maintainable). Good designers use a number of techniques to seek simplicity. One method that may seem counterintuitive is redefining the problem to be solved--sometimes even adding complexity to the original problem definition--in order to reduce the complexity of the solution. A Puzzling Parable I was first exposed to the problem redefinition strategy in a math puzzle. A shepherd died and was survived by three sons and twenty-three sheep. In his will, the shepherd left half of the sheep to the eldest child, one-third to the middle child, and one-eighth to the youngest child. Since the sheep were to be used for their wool, the sons weren`t thrilled with the notion of cutting up sheep to account for fractions. As they stood by the road arguing about how the division should occur, a wise woman came along, leading a sheep of her own to market. When the problem was explained to her, she considered it for a moment, and then praised the boys for not being too quick to butcher the sheep, which she said was not really necessary. They looked at her curiously, and she said, "Let me lend you this lamb as a tribute to my friendship with your father." She then led her lamb into the herd. "Now the division should be simpler." The eldest child smiled as he took away half (twelve) of the sheep to begin his herd. The middle child breathed a sigh of relief as he took one-third (eight) of the sheep from the pen and led them home to his farm. The youngest child watched as the old woman led her lamb from the pen and continued down the road toward the market, leaving him with one-eighth (three) of the herd. Too often during the design process we find ourselves worrying about the complex implementation of messy details (like dividing live sheep), without first seeking ways to minimize complexity by redefining the problem. Subtle changes to the problem being solved can have surprising benefits in terms of simplification. A "Solitary" Programming Example Solitaire is the name given to a family of card games that are played by a single player. I enjoy solitaire, and I have always wondered which strategies of play are the most effective. I once designed and built a simulation program to play a solitaire game called "Klondike," probably the most widely played variant of solitaire (see the sidebar for game rules and visit the StickyNotes to see the simulation program). I wanted to observe the effects of different strategies over a large number of games. During my initial thinking about the design, I was dismayed by the number of special cases that seemed to exist when I tried to describe in algorithmic terms how to play the game. The initial placement of aces is a special case, as is some of the logic required to handle depleting one of the seven face-up piles on the board: The possibility that the table might be left bare requires yet another special case in the card playing logic (the second special case below): I didn`t like it. It was too messy, and it violated one of the great truths of system design: "Nature abhors the special case." Changing the Problem to Eliminate the Special Cases I set out to see if I could factor out the special cases to simplify my task. I realized that kings and aces were special cases because they were boundary conditions. It is common to have special cases at the boundaries of a problem; the question is "Can the boundary be moved or removed?" The special case of the aces was the first to be simplified. I asked myself, "Is there a way to avoid the special test for aces?" (step 1 in the algorithm previously described). I observed that the reason aces were a special case is that they comprised the foundation of the suit row and, unlike all other cards in the deck, had no ordinal predecessors. This meant that they could not be placed according to step 2. Until the aces were placed, no deuces would pass the test in step 2 either. "If only there were a zero of hearts," I thought. "Then aces would no longer be a special case." Eureka! I imagined placing zeros of hearts, diamonds, clubs, and spades on the table as placeholders for the suit row at the start of each game. Now step 1 was no longer necessary, and aces could be placed according to the rules already defined in step 2. The problem definition was changed slightly (solitaire is not normally played with a fifty-six card deck that includes zeros of hearts, diamonds, clubs, and spades), but the underlying problem (i.e., accurately simulate a game of Klondike) was not changed, and the solution was simpler. All I had to do was add four cards to my fifty-two card deck, which would be "nailed to the table" during initialization and not affect play in any substantive way. Once the special case of the aces was solved, the kings were just a step away. The king boundary problem also arose because kings do not have predecessors (actually ordinal successors; remember that you count down from high to low when playing cards on the board). Kings could only be moved to the board when the face-up and face-down piles were exhausted, exposing the bare table below. Having already overcome the conceptual hurdle of inventing cards and adding them to the deck, I imagined a card larger than a king (an emperor?) that I could place on the table to attract kings when the face-up and face-down piles had been exhausted (currently handled by step 3.1). This would allow me to eliminate step 3.1 altogether, since, if kings were playable, they would be played during step 3.2 or 3.3. The trouble was that steps 3.2 and 3.3 required that the emperors be both black and red if any king were to go on any bare table space. I realized that I was being too literal about representing the deck of cards--assuming that it could only contain two colors, red and black. If I allowed a third colo r (green), then I could make my emperors that color and combine steps 3.2 and 3.3 into a single step: All I needed to do was add a green emperor face down at the bottom of each face-down stack during initialization, and the rules became simpler still. I assigned all of the emperors a suit of "circles." Emperors were now the boundary condition, but they could never be moved (there was no card bigger that would cause them to relocate on the board, and there was no "king of circles" to attract them to the suit row). This meant that the test in step X.1 was no longer necessary; if the face-up pile was exhausted, then there had to be a face-down card until you turned up the emperor, and once you turned up the emperor it could not be moved to exhaust the stack. This also eliminated the special case for king processing described in step X.2, because once the emperor in a face-down pile was exposed it would attract kings according to the modified rule 3 described previously. All that remained was an administrative detail: It was necessary to create a zero of circles to avoid adding complexity into step 2 when testing whether cards in face-up piles were playable. The end result of adding these twelve additional cards (five zeroes and seven emperors) to the deck was a minor change to the dealing initialization) routine and a tremendous reduction in the complexity of play, without altering the "real" game in any way. The simplified rules of play were: By changing aspects of the problem I reduced the complexity of the solution without sacrificing functionality or changing the underlying system behavior. Eliminating the special cases increased both the simplicity and quality of the solution. Identifying and avoiding needless complexity is part of building quality systems. Changing the definition or internal representation of a problem may significantly reduce solution complexity, but the analysis consumes time and resources. Is the investment worthwhile? A designer or project manager with limited resources and an aggressive schedule might reasonably question the benefit of searching beyond the first "good enough" solution identified, but finding a simpler solution can be extremely valuable. Simpler solutions are usually less expensive and time consuming to build, less error prone, easier to test, easier to maintain, and easier to modify. When design simplification results in efficient, simpler, and smaller programs, real productivity is improved. {end} Payson Hall (payson@catalysisgroup.com) is a consulting systems engineer and project manager from Catalysis Group, Inc. in Sacramento, CA. Formally trained as a software engineer, Payson has performed and consulted on a variety of hardware and software systems integration projects in both the public and private sectors throughout North America and Europe during his twenty-six-year professional career. He is a regular columnist on StickyMinds.com.
Managed Source Control Offshore/Remote Developers? Hosted source control is the best solution. No contracts. No quotas. Get your free trial today. Market-leading defect tracking from TechExcel DevTrack is a powerful, affordable and easy to use solution for project and defect tracking. It comprehensively tracks and manages all product defects, change requests, and other development issues Census: Web-based Bug Tracking and Defect Tracking Track software bugs, defects, enhancements, support calls, and more. Issue tracking software that is scaleable, fully customizable and integrated with VSS. Includes e-mail notifications, role-based workflow, change history, and Crystal reporting. Use AI and metrics to evaluate source code! Analyze and predict where errors will occur in your Java, C# and C++ source code. Download beta here. BugMonitor.com - We make your software better! BugMonitor.com is a hosted, bug tracking service for software developers. It provides quality assurance personnel, developers, and their clients global defect management throughout the software development life cycle. HOSTED. Try a FREE 45-day trial. |