September 18, 2005 Uncategorized

Continuous Design: Were did design go?

I think there is a parallel between what FiT is doing for requirements and what unit tests can do for Continuous Design.  Specifically FiT provides executable requirements and unit tests provide executable design artifacts.  Grant-it you must write your unit tests to be communicative.  Those migrating from BDUF often feel insecure without design artifacts.  There are many other things that make those migrating from BDUF feel insecure but I think this one can be solved by overloading the purpose of unit tests.  Viewing unit tests as design artifacts can be a specially helpful at a shop where pair programming is not practiced.  Design reviews are the counter to pair programming in the non-agile world, and unit tests could be used to review the proposed design.  Having the design expressed as executable tests instills much more confidence in me than design artifacts like documents and diagrams.  I can have greater assurance that the design I am reviewing will actually come to be.  As well I am assured that the design artifact will stay in sync with the product.  So there is an extra step between red and green when not practicing pair programming, design review by examination of the unit tests.  Something to be careful of in these design reviews: reviewers are likely to think ahead to the future.  The reviewers need to adhere to “Do the Simplest Thing that Could Possibly Work” and “You Aren’t Going to Need It”.  Where interaction between entities larger than classes need to be reviewed FiT tests and fixtures can be included in the review.  They should probably be included in the review anyway.  If a shop can make this practice work it should save time.  Instead of producing both tests (unit and FiT) and design docs they need only create the tests.  The quality of the altered process should be the same if not better.  The previous process being: create design artifacts, design review, red, green.  Notice the lack of refactor?  That is because there was a design specified up front, and the goal is to implement that design.  The goal of the design was to adhere to “Do the Simplest Thing that Could Possibly Work” and “You Aren’t Going to Need It” while expressing the new feature.  Refactoring is done in the design phase.

9,806 Total Views

Leave a comment