Best practices for agile design


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • A class should have one, and only one, reason to change
  • You should be able to extend a classes behavior, without modifying it "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. ”
  • Derived classes must be substitutable for their base classes.
  • Make fine grained interfaces that are client specific.
  • Depend on abstractions, not on concretions
  • Best practices for agile design

    1. 1. Agile design Best practices We believe that it is possible. Igor Moochnick Principal IgorShare Consulting [email_address] Blog:
    2. 2. A/agile? L/lean? <ul><li>It’s not about: </li></ul><ul><ul><li>Methodology </li></ul></ul><ul><ul><li>Tools </li></ul></ul><ul><ul><li>Games </li></ul></ul><ul><ul><li>Protocols </li></ul></ul><ul><ul><li>Rituals </li></ul></ul><ul><ul><li>Manifests </li></ul></ul><ul><ul><li>Etc… </li></ul></ul><ul><li>It’s about </li></ul><ul><ul><li>doing the “right” thing for your customers and your team </li></ul></ul><ul><ul><li>Transparency </li></ul></ul>
    3. 3. Am I agile? <ul><li>Agile means the ability to respond quickly to any change </li></ul><ul><ul><li>Follow new business opportunities </li></ul></ul><ul><ul><li>Reflect rapid market changes or challenges </li></ul></ul><ul><li>Lightweight </li></ul><ul><li>It has nothing to do with the software development, but it really helps to rapidly exploit business potential </li></ul><ul><li>You have to have Agile company to really succeed </li></ul><ul><ul><li>If your software team is agile and produces a ton of features but the sales and the marketing teams are not performing – it’ll not help you to grow your revenue as quickly as you’d like </li></ul></ul>
    4. 4. Assumptions <ul><li>Life is unpredictable </li></ul><ul><li>Doesn’t matter what you do the statement #1 still holds true </li></ul><ul><li>Customers are unpredictable – deduction from #1 </li></ul><ul><li>Our goal is to make it safely to the delivery while reacting to the consequences from statement #1 </li></ul>
    5. 5. Agile design is here to address … <ul><li>How to move forward without having all the requirements flushed out </li></ul><ul><li>How to isolate the “unknowns” and capitalize on “known” </li></ul><ul><li>How to create the boundaries between the “stable” and “unstable” </li></ul><ul><li>How to make your systems resilient to change </li></ul><ul><li>How to make your systems accommodate constant and continous changes </li></ul>
    6. 6. Agile design helps you to … <ul><li>Move forward without knowing the final destination – no design upfront </li></ul><ul><li>Accommodate “continuous design” </li></ul><ul><li>Capitalize on learning </li></ul><ul><li>Socialize and Distribute the design – important for distributed teams </li></ul><ul><li>Get early and continuous feedback </li></ul><ul><li>Achieve flexible delivery options </li></ul><ul><li>Provide sustainable development </li></ul>
    7. 7. Scenario <ul><li>There is a requirement to build a Baseball League Table Report web app </li></ul><ul><ul><li>Do we create a simple HTML page? </li></ul></ul><ul><ul><li>Do we need to create a n-tier Web Application? </li></ul></ul><ul><ul><li>Do we need to have a DB to store the data? </li></ul></ul><ul><ul><li>Can we keep the data in a file? </li></ul></ul>
    8. 8. Requirements <ul><li>Prioritized backlog </li></ul><ul><ul><li>Allows you to make decisions on what and when should be done </li></ul></ul><ul><li>Track progress (lifecycle of a requirement) </li></ul><ul><li>Ownership </li></ul>
    9. 9. Backlog management <ul><li>Order </li></ul><ul><li>Assignments </li></ul><ul><li>Estimates </li></ul>
    10. 10. Transparency - Feedback Not Started In Progress Testing Customer Review Done, Done, Done         Story #1         Story #2       Story #3       Story #4       Story #5           Story #6       Story #7         Story #8       Story #9         Story #10        
    11. 11. Design <ul><li>No large design upfront </li></ul><ul><ul><li>Not everything is known ahead of the time and will be discovered later </li></ul></ul><ul><ul><li>Design continuously – design hat is always on </li></ul></ul><ul><li>KISS/YAGNI/DRY </li></ul><ul><li>Delay commitment and complexity </li></ul><ul><li>Simplicity is hard </li></ul><ul><li>Avoid “Architect Hubris” </li></ul><ul><ul><li>If we just build the framework upfront, coding will be easy… </li></ul></ul><ul><li>Harvest Abstraction </li></ul><ul><ul><li>Make any abstraction earn its existence </li></ul></ul>
    12. 12. Scenario <ul><li>The Baseball League Tables web app serves a relatively small amount of data which expected to grow much larger </li></ul><ul><ul><li>Should we add more Web services with a lot of memory? </li></ul></ul><ul><ul><li>Should we scale the file system? </li></ul></ul><ul><ul><li>Should we scale the DB for read intensive operation? </li></ul></ul><ul><ul><li>Should we put a caching layer? </li></ul></ul><ul><ul><li>Should we scale to the cloud? </li></ul></ul>
    13. 13. The Last Responsible Moment <ul><li>“… delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. “ </li></ul><ul><li>– Mary Poppendieck </li></ul>
    14. 14. Decide when to Decide <ul><li>Make decisions at the right time </li></ul><ul><li>Utilize continuous learning </li></ul><ul><li>Think ahead, yes! Act ahead, no! </li></ul><ul><ul><li>Don’t act on speculative design </li></ul></ul><ul><ul><li>Keep a queue of design ideas and possible refactorings </li></ul></ul><ul><li>Don’t go past the Last Responsible Moment </li></ul><ul><ul><li>Be cognizant of outstanding design decisions </li></ul></ul><ul><ul><li>Some decisions have to be made earlier than others </li></ul></ul>
    15. 15. Reversibility <ul><li>“ If you can easily change your decisions, this means it's less important to get them right - which makes your life much simpler. ” </li></ul><ul><ul><li>- Martin Fowler </li></ul></ul>
    16. 16. Designing for Reversibility <ul><li>Orthogonal Code </li></ul><ul><ul><li>Separation of Concerns </li></ul></ul><ul><ul><li>Cohesion </li></ul></ul><ul><ul><li>Coupling </li></ul></ul><ul><li>The Single Responsibility Principle </li></ul><ul><ul><li>“ A class should have only one reason to change” </li></ul></ul><ul><li>Open Closed Principle </li></ul><ul><li>Don’t Repeat Yourself Principle (DRY) </li></ul><ul><li>Testability </li></ul>
    17. 17. Where Reversibility breaks <ul><li>Dependencies on external teams or external experts </li></ul><ul><li>Publicly published interfaces </li></ul><ul><li>It’s important to decide when to decide! </li></ul>
    18. 18. Design Feedback <ul><li>SMELL test </li></ul><ul><li>Mockups for customers </li></ul><ul><li>Any Design is theory until proven </li></ul><ul><li>“ Bubbles don’t crash” </li></ul><ul><li>Analysis/Paralysis </li></ul><ul><li>If you don’t know what to do next, Spike It! </li></ul><ul><li>Don’t keep bad design </li></ul><ul><li>Don’t be afraid of modeling but stop it as soon as you stop learning </li></ul>
    19. 19. Composite Application <ul><li>Loosely coupled but cohesive </li></ul><ul><li>Inversion of Control </li></ul><ul><ul><li>Don’t call me, I’ll call you </li></ul></ul><ul><ul><li>Seamlessly swap one implementation with another </li></ul></ul><ul><li>Dependency Injection </li></ul><ul><ul><li>“ new()” is a form of tight coupling with inherent knowledge </li></ul></ul><ul><ul><li>Constructor Injection </li></ul></ul><ul><ul><li>Properties Injections </li></ul></ul>
    20. 20. Maximizing Evolutionary Design <ul><li>If possible, only divide teams by feature </li></ul><ul><ul><li>Externally facing API’s are NOT reversible </li></ul></ul><ul><li>Be Cautious when building Frameworks </li></ul><ul><li>Persistence Ignorant Domain Models </li></ul><ul><li>Delay the Database Model </li></ul><ul><li>Presentation / Behavior Separation in the User Interface </li></ul>
    21. 21. Development <ul><li>Orthogonal Code </li></ul><ul><ul><li>Separation of Concerns </li></ul></ul><ul><ul><li>Cohesion </li></ul></ul><ul><ul><li>Coupling </li></ul></ul><ul><li>Don’t Repeat Yourself Principle (DRY) </li></ul><ul><li>Refactor Relentlessly </li></ul><ul><li>Testability </li></ul>
    22. 22. SOLID Development Principles (classes)
    23. 28. Package Cohesion Principles REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release. CCP The Common Closure Principle Classes that change together are packaged together. CRP The Common Reuse Principle Classes that are used together are packaged together.
    24. 29. Package Coupling Principles ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles. SDP The Stable Dependencies Principle Depend in the direction of stability. SAP The Stable Abstractions Principle Abstractness increases with stability.
    25. 30. Refactor Relentlessly <ul><li>Design reflectively </li></ul><ul><li>The quality of a design is largely the accumulative sum of many small decisions </li></ul><ul><li>Clean the dishes after cooking </li></ul><ul><ul><li>Bad names </li></ul></ul><ul><ul><li>Duplication </li></ul></ul><ul><ul><li>Big classes or long methods </li></ul></ul><ul><li>Software entropy is the enemy! </li></ul>
    26. 31. Development feedback? <ul><li>Continuous integration </li></ul><ul><li>Continuous deployment </li></ul><ul><li>Unit tests </li></ul><ul><li>Code coverage </li></ul><ul><li>Test automation </li></ul>
    27. 32. Testing <ul><li>When do we start testing? </li></ul><ul><li>Do we really need it? </li></ul><ul><li>Do we test the right thing? </li></ul><ul><li>What does the test testing? </li></ul><ul><li>Do we know what code is tested? Coverage? </li></ul><ul><li>If the test fails – what does this mean? </li></ul><ul><li>Do we know what failed? </li></ul>
    28. 33. Make your code easy to test <ul><li>“ 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.” </li></ul><ul><ul><li>Michael Feathers </li></ul></ul>
    29. 34. Tests are all about confidence
    30. 35. Improve the Testability of the code <ul><li>Easy to test the classes in the system except for the edge </li></ul><ul><li>Isolate the Ugly stuff (the hard to test things) </li></ul><ul><li>Some things are hard to test </li></ul><ul><li>User interface is hard to test – use MVP, MVC, MVVM, etc… </li></ul><ul><li>Data Storage is hard to test – use ORMs </li></ul><ul><li>Use Mock frameworks – nMock, Moq, etc… </li></ul><ul><li>Dependency Inversion Principle </li></ul><ul><ul><li>Code to the interface, not the implementation </li></ul></ul>
    31. 36. Distributed Design <ul><li>Socialize the design </li></ul><ul><li>Know the why </li></ul><ul><li>Collectively challenge the design every day </li></ul><ul><li>Talk about the design </li></ul><ul><li>Keep the team abreast of changing design strategies </li></ul><ul><li>The “This is the way we do it” moment </li></ul>
    32. 37. Distributed development <ul><li>Separation of concerns </li></ul><ul><li>Hide responsibility </li></ul><ul><li>Abstract external dependencies </li></ul><ul><li>Decoupling teams </li></ul><ul><li>Self-sustained and self-sufficient teams </li></ul><ul><li>If possible, only divide teams by feature </li></ul><ul><ul><li>Externally facing API’s are NOT reversible </li></ul></ul><ul><li>Transparency on interfaces and contracts – demos and unit tests </li></ul>
    33. 38. Work Vertically by Feature <ul><li>Design vertical slices of deliverable functionality </li></ul><ul><li>All design work should be traceable to immediate business need </li></ul><ul><ul><li>Includes architectural infrastructure </li></ul></ul><ul><ul><li>“ Pull” Design versus “Push” Design </li></ul></ul><ul><li>Minimize rework by integrating early </li></ul><ul><ul><li>Test early </li></ul></ul><ul><ul><li>User feedback early </li></ul></ul><ul><ul><li>Deployment feedback early </li></ul></ul><ul><ul><li>Shorten the time between doing and verifying </li></ul></ul>
    34. 39. Delivery <ul><li>Instant deployment </li></ul><ul><li>Constant deployment </li></ul>
    35. 40. About design of APIs <ul><li>Convention over Configuration </li></ul><ul><li>“ 5 minutes out-of-the-box experience” </li></ul><ul><li>&quot;design away&quot; common problems rather than documenting workarounds </li></ul><ul><li>Read more on Developer’s Experience ( http:// ) </li></ul><ul><li>Programmers are People too ( http:// ) </li></ul><ul><li>Affordances and Design ( http:// ) </li></ul>
    36. 41. Questions and Answers
    37. 42. Thanks for ideas <ul><li>Martin Fowler </li></ul><ul><li>Uncle Bob Martin </li></ul><ul><li>Jeremy D Miller </li></ul><ul><li>Others … </li></ul>