IEEE SOFTWARE Published by the IEEE Computer Society - PDF document

IEEE SOFTWARE ThoughtWorks brought a new style of design into view.a programÕs design. Initially a skeptic, IÕve beenyears, and itÕs changed the way I program.Continuous design is also knownas tionary or emergent design.I prefer the termtageof design flaw, you fix it. When a newfeature doesnÕt fit, you update thedesign. (For an introduction, seeMartin FowlerÕsat www.martinfowler.com.)with up-front design, but the XPstead of the latter. When I startedexperimenting with XP in 2000, Iwas very skeptical of the idea. IÕd been in-into a corner with bad design, and I was con-vinced that up-front design was necessary toavoid that problem. When I tried XP, I hedgedpersistence model up-front.The persistence model was a disaster: it re-quired a huge amount of code to do simplethings. Continuous design, however, was a roar-ing success. The application, developed over 16months by six people, had the best design IÕdseen. Bit by bit, continuous design fixed the per-sistence model too, eventually giving us an ele-gant solution that was simple and flexible.inspired me to continue experimenting. Myup-front designs became simpler and simpler...then disappeared entirely. Today, when I start(ThatÕs harder than it sounds!) I implement thefirst feature, see where it takes me, implementthe second one, and refactor. As someone whoused to strongly advocate up-front design, IÕmItÕs easy to take a statement like ÒI activelyavoid deciding on a designÓ to mean that I donÕtdesign at all. ThatÕs not what I mean. Continu-of the designÑafter code has been written andthereÕs a design to review. The difference is thatthereÕs no speculative design. You optimize thesecurity, transactions, and internationalizationthat require up-front design.Or do they? The line isnÕt as clear as peoplecontinuous design. The better the applicationan existing system. By transaction security, Imean that every client action in this client-security was a critical requirement, but a for- January/February 2004IEEE SOFTWARE attend feature prioritization meetings,document, complete with screen shots.)After the first version was released, mymissing security.This wasnÕt an XP project: we hadhadnÕt anticipated transaction secu-rity, though, and the design didnÕt in-though it was tedious. We added secu-every server-side entry point. Therewere quite a few, and updating theA year or so later, I retrofitted busi-ness transactions into a Web-based ap-actions, in this case, meant the abilitybe grouped into atomic transactions, toretrofit, which was more significantless time because the code was better. Ittook one pair about a day, maybe two.A notable aspect of this change wasthe centralized database handler. Mostmanagement sprinkled throughout thecode. Even when thereÕs a dedicated per-sistence layer, thereÕs often repeated con-nection-open, connection-close, and ex-ception logic. In the beginning, we hadduplicated connection logic, too. Thatdesign, and we refactored it into a com-layer, which would give it a block ofThis design, made to eliminate du-so easy. We changedthat executed them.Java, the language we used. We stay upto date with the latest design patternsavoid needing them. This time, we didAbout six months later, we retrofit-ted the same application with interna-tionalized input and output. The codehad been developed with continuous de-outstanding. After researching interna-tionalization, it took one pair aboutfour hours to code it. The code had amethod, which required a five-linechange. The centralized output handlerIt might seem like weÕd planned up-front for these changes, but we didnÕt.cated in three or four places. Improve-ments to our unit tests required it to becentralized, so we refactored. Monthslater, when we had dozens of pages, wecame back and reused that method toOutput was a similar story. We orig-brary called WebMacro (www.web-that caused a lot of duplication. WedidnÕt like this, so we moved to an ap-proach that isolated WebMacro in awork harder to understand Web-Macro, but it made our design muchcleaner.The end result of this change was aplate to WebMacro and returned theresulting stream. Later, when we inter-nationalized, we were able to easilymodify that class to choose betweenIf weÕd kept WebMacroÕs frame-tion of a C# ASP.NET application.ASP.NET is a framework for .NETeb applications. Its use of multiple DRY (DonÕt Repeat Yourself):ThereÕs little duplication.Specific approaches are preferred over generic ones. Design pat-terns support features, not extensibility.Related code and concepts are grouped together.Unrelated code and concepts can be changed independently.Third-party code is isolated behind a single interface.The design doesnÕt try to predict future features.Interfaces, factory methods, events, and other extensibility ÒhooksÓ common functionality. Combined withour inexperience with ASP.NET, thisled to a lot of duplication in the pre-sentation layer.not input, but it still took one pairoutput, we had to find all places thatAs with the security retrofit, this wastedious, but not particularly hard.specific design qualities. The most ob-similar code over and over, the changewas tedious and took a lot longer.was important. With simpler designs,we were less likely to encounter exist-Adding code that doesnÕt exist is easy;fixing someoneÕs preconceptions abouta feature first is more costly. The side-Before you tryMy experiments with continuous de-mend that you try it on your projects.at your current process. Softwaresign might not be friendly to continuousdesign. At a minimum, youÕll need auto-ship), and commitment to continuouslythe face of schedule pressure.ou might wish to experiment withular, up-front designs often includen my projects, continuous designÕstime, rather than less. After experi-long, IÕm convinced that itÕs harder topaint yourself into a corner than it iswith up-front design. Try it for your-Jim Shoreis the founder of Titanium I.T., a Portland, Ore- installation. But any task that a developerhas to perform more than three times is avelopment environment. Or, you mightwould use). It might require an entireprogram itself, written in Ruby orJava. However itÕs implemented, makesure that the automation code is keptavailable for the entire teamÕs use.tency, reliability, and repeatabilityronments. New developers can get ontype a command, even if theyÕre build-ing on a different platform than theyÕreProducts to coordinate compilationas Ant (ant.apache.org) or Make (www.gnu.org/software/make). Systems suchas AntHill (www.cs.unibo.it/projects/or Dartboard (http://public.kitware.have a firm base from which tobook series. Contact them via www.PragmaticProgrammer.com. Continued from p. 19 SOFTWARE CONSTRUCTION Senior T echnical Advisor for Safety-Critical Electronic Systems The FRA promotes and enforces safetythroughout the U. S. rail system. This posi-tion provides technical leadership/advice forthe development of effective standards for€Minimum of three years of experienceproviding extensive knowledge of safety-critical systems in areas such as railroads,avionics, or space flight systems. Mustverification, and validation of safety-critical€Ph.D. or M.S. in electronic/ computerinformation in writing and at meetings to€Professional stature at the internationalPosition is in Washington, DC. U. S. citi-zenship is required. Applications accepteduntil February 9, 2004. Salary range is$115,184 - $142,600. Visit http://www.fra. gov FRA is an equal opportunity employer. Federal Railroad Of Transportation