Better Software - December 2007 - (Page 36)

testers with overly detailed descriptions designed to “help” the programmer. Use cases are a stronger alternative than user stories. • Use systematic testing techniques to reduce redundancy among test cases. The second complaint is a bit more problematic. The user interface proves to be not as productive as the competition’s, in spite of the fact that in the last release, a good usability person worked with development to improve the interface. Upon further study, it’s shown that the productivity lapse comes from a long pause in operator input when faced with non-repetitive operations and that there is a lot of rework that is caused by user errors. What is going on is that the entities known to the interface are a bad match for the mental model—both conscious and unconscious—of the end-user. We approach the developers, and they insist that they have taken our advice from last time and that they have developed the system from tests that derive directly from user desires. We have a look at the architecture. We see the layered structure that came out of their bottom-up approach. True to the tests, the main organizing principle is around procedures. The business objects didn’t factor into the design, because design— true to TDD—is driven by tests. Combine this perspective with YAGNI (You Aren’t Going to Need It) and you have a perfect recipe for ignoring broad questions of structure: It’s all about functionality. The GUI objects, of course, reflect the business objects of the underlying design, in concert with Model-View-Controller principles. These principles go to the heart of object-orientation (see the StickyNotes for references), directly engaging the enduser with the code. That the classes came about from pieced-together functions, rather than from broad domain thinking, leaves the system structure (and the GUI) beyond the user’s comprehension. Unfortunately, the competition has a sound architecture of objects that capture the user-conceptual model of the business, 36 and those objects shine through in the screens, entities, and operations of the GUI. Faced with a new situation, the competition’s users are more likely to do the right thing than are our users. A design driven by tests is necessarily a design driven by procedural thinking. It encourages procedural layering, rather than creating conceptually cohesive objects. The best that even a masterful interface can do is to capture these objects that badly reflect the user’s mental model. To fix this: • Do a little up-front design, as described previously. • The architecture of a system is visible to the user in the way it works. Kent Beck once said that a good interface can’t hide a bad design, and Trygve Reenskaug has said that the architecture is key to a good human-computer interface. Now team members think they finally are in good shape. They are eager to go into their fourth release, which is supposed to support a wide range of new functionality. Again and again they find the same kind of crosscutting problems as they had observed in the very early problems with user stories interfering with each other. Everything seems to require coordination between a large number of objects, and the developers get the feeling that everything is becoming global. We have a look at the changes they are making: None of them are well encapsulated or localized, because their functional decomposition structure cuts across the functional decomposition structure inherent in the architecture. The architecture has not been partitioned according to basic business structures, which would support evolution gracefully. By this time, the competition has gained so much market share that it can afford to buy out our company—and it does. The competition talks to the consultants and decides that a major training effort is in order. Our team has many things to learn, the last of which is: www.StickyMinds.com Over time, the same TDD practices that drive a design away from supporting usability also drive it away from architectural soundness. And again, the solution is: • Don’t drive your architecture with testing. Drive it with lightweight domain analysis and enough upfront design that you can be confident about the structure of the GUI and the maintainability of the architecture. • Start with abstract base classes and flesh them out as use cases come along. So, now we’re working for the competition, and we gain some insight into what it’s doing right. It is following most of the suggestions above, which boil down to some simple principles: • Do lightweight, up-front architecture. • Use use cases, not user stories. • Drive tests from use cases rather than from developer intuition. Test developer code against independently developed tests as soon as both are available. They’re pretty simple principles. We find that our competitor has a lower bug density than we do. And, in fact, it has a strongly disciplined manner of class design. Once its classes are designed, using input from domain experts and usability folks, the competitor attaches pre- and post-conditions to the methods and asserts class invariants for each instance. This sharpens its thinking in a much more formal way than TDD ever was able to do. To this end, the team was using macros; in Eiffel or in Spec#, you find them directly supported in the language. The developers told the boss that this was a good idea. First, most tests only reach in and evaluate results for a specific, small set of values. Assertions can be set up to express entire sets of values or value ranges or arbitrarily complex business rule invariants that must always be true. System testing not only provides inputs and looks for correct outputs, but it BETTER SOFTWARE DECEMBER 2007 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2007

Better Software - December 2007 Contents Mark Your Calendar What's Happening @ StickyMinds.com Technically Speaking Code Craft Test Connection Management Chronicles Man and Machine Let Your Values be Your Guide A Story About User Stories and Test-driven Development Product Announcements The Last Word Ad Index

Better Software - December 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.