Best practices for agile design

Agile design Best practices We believe that it is possible. Igor Moochnick Principal IgorShare Consulting [email_address] Blog: www.igorshare.com/blog

A/agile? L/lean? It’s not about: Methodology Tools Games Protocols Rituals Manifests Etc… It’s about doing the “right” thing for your customers and your team Transparency

Am I agile? Agile means the ability to respond quickly to any change Follow new business opportunities Reflect rapid market changes or challenges Lightweight It has nothing to do with the software development, but it really helps to rapidly exploit business potential You have to have Agile company to really succeed 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

Assumptions Life is unpredictable Doesn’t matter what you do the statement #1 still holds true Customers are unpredictable – deduction from #1 Our goal is to make it safely to the delivery while reacting to the consequences from statement #1

Agile design is here to address … How to move forward without having all the requirements flushed out How to isolate the “unknowns” and capitalize on “known” How to create the boundaries between the “stable” and “unstable” How to make your systems resilient to change How to make your systems accommodate constant and continous changes

Agile design helps you to … Move forward without knowing the final destination – no design upfront Accommodate “continuous design” Capitalize on learning Socialize and Distribute the design – important for distributed teams Get early and continuous feedback Achieve flexible delivery options Provide sustainable development

Scenario There is a requirement to build a Baseball League Table Report web app Do we create a simple HTML page? Do we need to create a n-tier Web Application? Do we need to have a DB to store the data? Can we keep the data in a file?

Requirements Prioritized backlog Allows you to make decisions on what and when should be done Track progress (lifecycle of a requirement) Ownership

Backlog management Order Assignments Estimates

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

Design No large design upfront Not everything is known ahead of the time and will be discovered later Design continuously – design hat is always on KISS/YAGNI/DRY Delay commitment and complexity Simplicity is hard Avoid “Architect Hubris” If we just build the framework upfront, coding will be easy… Harvest Abstraction Make any abstraction earn its existence

Scenario The Baseball League Tables web app serves a relatively small amount of data which expected to grow much larger Should we add more Web services with a lot of memory? Should we scale the file system? Should we scale the DB for read intensive operation? Should we put a caching layer? Should we scale to the cloud?

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

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

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

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

Where Reversibility breaks Dependencies on external teams or external experts Publicly published interfaces It’s important to decide when to decide!

Design Feedback SMELL test Mockups for customers Any Design is theory until proven “ Bubbles don’t crash” Analysis/Paralysis If you don’t know what to do next, Spike It! Don’t keep bad design Don’t be afraid of modeling but stop it as soon as you stop learning

Composite Application Loosely coupled but cohesive Inversion of Control Don’t call me, I’ll call you Seamlessly swap one implementation with another Dependency Injection “ new()” is a form of tight coupling with inherent knowledge Constructor Injection Properties Injections

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

Development Orthogonal Code Separation of Concerns Cohesion Coupling Don’t Repeat Yourself Principle (DRY) Refactor Relentlessly Testability

SOLID Development Principles (classes)

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.

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.

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!

Development feedback? Continuous integration Continuous deployment Unit tests Code coverage Test automation

Testing When do we start testing? Do we really need it? Do we test the right thing? What does the test testing? Do we know what code is tested? Coverage? If the test fails – what does this mean? Do we know what failed?

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

Tests are all about confidence

Improve the Testability of the code Easy to test the classes in the system except for the edge Isolate the Ugly stuff (the hard to test things) Some things are hard to test User interface is hard to test – use MVP, MVC, MVVM, etc… Data Storage is hard to test – use ORMs Use Mock frameworks – nMock, Moq, etc… Dependency Inversion Principle Code to the interface, not the implementation

Distributed Design 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

Distributed development Separation of concerns Hide responsibility Abstract external dependencies Decoupling teams Self-sustained and self-sufficient teams If possible, only divide teams by feature Externally facing API’s are NOT reversible Transparency on interfaces and contracts – demos and unit tests

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

Delivery Instant deployment Constant deployment

About design of APIs Convention over Configuration “ 5 minutes out-of-the-box experience” "design away" common problems rather than documenting workarounds Read more on Developer’s Experience ( http:// blog.oshineye.com/2011/05/what-is-devexp.html ) Programmers are People too ( http:// www.natpryce.com/articles/000732.html ) Affordances and Design ( http:// www.jnd.org/dn.mss/affordances_and_design.html )

Thanks for ideas Martin Fowler Uncle Bob Martin Jeremy D Miller Others …

Best practices for agile design

More Related Content

What's hot

Viewers also liked

Similar to Best practices for agile design

More from Igor Moochnick

Recently uploaded

Best practices for agile design

Editor's Notes