Presentation is loading. Please wait.

Presentation is loading. Please wait.

How does Design get done on an Agile Project? Jeremy D. Miller Nov 27, 2007.

Similar presentations

Presentation on theme: "How does Design get done on an Agile Project? Jeremy D. Miller Nov 27, 2007."— Presentation transcript:

1 How does Design get done on an Agile Project? Jeremy D. Miller Nov 27, 2007

2 Agile and Software Design No Big Design Upfront! Is Design Dead? You’re coding without knowing where you’re going? How is this “Agile” stuff responsible? What does it mean to “design continuously?” How does Agile impact the makeup of the team? How do we make this work? When do we have to design upfront?

3 Scenario 1 A Software team is building a new ASP.NET application with substantial business logic and processing. Do you: 1.Create a web service for the business logic and make the web application call this web service 2.Build and deploy the business logic in process with the web application

4 Value Proposition of Agile (or Lean) Return on Investment Early and continuous feedback Capitalize on learning Flexible delivery options Sustainable development

5 Work Vertically by Feature Design vertical slices of deliverable functionality All design work should be traceable to immediate business need  Includes architectural infrastructure  “Pull” Design versus “Push” Design Minimize rework by integrating early  Test early  User feedback early  Deployment feedback early  Shorten the time between doing and verifying

6 Keep It Simple The Simplest Thing that could Possibly Work  What does “work” mean?  What does “simple” mean? YAGNI – “You aren’t gonna need it”  Build only what you need right now  The simple solution may be enough  Easy to add complexity, hard to remove it

7 Scenario 2 The new software system requires access to a set of reference data. This data is fairly static and small to begin with, but will grow much larger in 9 months. Do you: 1.Build in caching right now 2.Make the access directly to the database 3.Just store this data in a file

8 The Last Responsible Moment “…delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. “ – Mary Poppendieck

9 Decide when to Decide Make decisions at the right time Utilize continuous learning Think ahead, yes! Act ahead, no!  Don’t act on speculative design  Keep a queue of design ideas and possible refactorings Don’t go past the Last Responsible Moment  Be cognizant of outstanding design decisions  Some decisions have to be made earlier than others

10 Delay commitment and complexity Simplicity is hard Possible effects of abstractions  Reuse of code and easier development  Unnecessary complexity  Changes are more difficult Avoid “Architect Hubris”  If we just build the framework upfront, coding will be easy… Harvest Abstraction  Make any abstraction earn its existence

11 Reversibility “If you can easily change your decisions, this means it's less important to get them right - which makes your life much simpler. ” - Martin Fowler

12 The Limits of Reversibility Dependencies on external teams or external experts Publicly published interfaces Again, decide when to decide!

13 Designing for Reversibility Orthogonal Code  Separation of Concerns  Cohesion  Coupling The Single Responsibility Principle  “A class should have only one reason to change” Open Closed Principle Don’t Repeat Yourself Principle (DRY) Testability

14 Maximizing Evolutionary Design If possible, only divide teams by feature  Externally facing API’s are NOT reversible Be Cautious when building Frameworks Persistence Ignorant Domain Models Delay the Database Model Presentation / Behavior Separation in the User Interface

15 Design Together Socialize the design Know the why Collectively challenge the design every day Talk about the design Keep the team abreast of changing design strategies The “This is the way we do it” moment

16 What do I use for Design? Design Principles Design Patterns Test/Behavior Driven Development Responsibility Driven Design (CRC cards) Code Smells Refactoring Pair Programming Whiteboard UML Design Notebook

17 Say yes to modeling, but… Travel light Don’t create any incentive to keep a bad design Do it together Expand your intellectual toolbox  UML  CRC cards  ERD  ??? Use precise terminology Stop modeling the second you stop learning

18 Feedback Any Design is theory until proven “Bubbles don’t crash” Analysis/Paralysis If you don’t know what to do next, Spike It!

19 Refactor Relentlessly Design reflectively The quality of a design is largely the accumulative sum of many small decisions Clean the dishes after cooking  Bad names  Duplication  Big classes or long methods Software entropy is the enemy!

20 Think and Do Code’n Go == Chaos The Design Hat never comes off The Will to Design Design and coding are conjoined twins Use solid design principles as you code Put design strength at the point of attack Sustainable efforts require good designs

21 Questions and Discussion The Shade Tree Developer –

22 Do One Thing at a Time The Single Responsibility Principle  “A class should have only one reason to change”  One class, one responsibility  An expression of cohesion  Example: The Blob Class  Example: SingleResponsibilityPrinciple

23 Open Closed Principle "Software entities should be open for extension, but closed for modification.“ - Robert C. Martin “…the essence of the Open/Closed Principle is being able to add new functionality to an existing codebase by writing completely new code with minimal modification of existing code. ”

24 Don’t Repeat Yourself “…every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation.”  The Pragmatic Programmers Eliminate duplication Improve cohesion I only want to tell you this once! Example: DRY out Session

25 Test Driven Development “[Test Driven Development] gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.” - Martin Fowler on TDD

26 Make your code easy to test “I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes, it’s not as good as you think it is, and whether you know it or not, you're paying a price for it.”  Michael Feathers

27 Isolate the Ugly Stuff Some things are hard to test Ugly Stuff == Inconvenient while unit testing  The Database  Active Directory  Web Services  Messaging Model View Presenter as an example  The actual user interface is hard to test  Use Model View Presenter to decouple code from the user interface machinery Dependency Inversion Principle  Code to the interface, not the implementation

28 Expand the Creamy Center Graphic from Jay Flowers

29 Push, Don’t Pull Example: When is now? Inversion of Control  Don’t call me, I’ll call you  Example: The Translator  Database Mapper Dependency Injection  “new()” is a form of tight coupling  Example: Constructor Injection

30 Test Small Before Testing Big Code from the bottom up Oh no! How do all these pieces fit together?  Don’t care (for now)  What do you know how to do? Short term value proposition of TDD:  Save more time in debugging than you spend in unit testing

31 Example: Supply Chain Routing Determine the best way to route requests from the factory lines for parts Correlate data from three different sources of information into “shelves” Apply a complex series of business rules against the data to select the best part channel (part, inventory source, and factory line destination)

32 Keep a Short Tail Can you get there from here? Aerosmith and Roadies Test by Measuring What You are Trying to Test!  Example: InvoiceScreenCreator Isolate the Churn Whenever you can, keep the database on the sidelines

33 Establish a Maintainable Software Ecosystem Change enablers Feedback loops Test automation Continuous Integration

Download ppt "How does Design get done on an Agile Project? Jeremy D. Miller Nov 27, 2007."

Similar presentations

Ads by Google