Apidays New York 2024 - The value of a flexible API Management solution for O...
Arch factory - Agile Design: Best Practices
1. Track: Architecture Leadership
Agile Design
Best practices
We know that it is possible.
Igor Moochnick
Principal
IgorShare Consulting
igor@igorshare.com
Blog: www.igorshare.com/blog
1
2. Wireless Access
1. Connect to the “Cambridge” network
2. Open a Browser
3. In Logon page use the code:
af609
2
3. 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
4. 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
5. Assumptions
1. Life is unpredictable
2. Doesn’t matter what you do, the statement #1 still
holds true
3. Customers are unpredictable – deduction from #1
4. Our goal is to make it safely to the delivery while
reacting to the consequences from statement #1
6. 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
continuous changes
7. 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
8. Requirements
Prioritized backlog
• Allows you to make decisions on what and when should be done
Track progress (lifecycle of a requirement)
Ownership
9. Redesign – self-fulfilling prophecy
Increased complexity of the code reduces productivity which leads to a “ahh…
screw it and let’s redesign everything” mentality
Reduced productivity leads to adding developers which increase the
complexity faster
“Clean Code” NDC 2010
– “Uncle” Bob Martin
10. Backlog management
Priority/Order “Initial estimates are off by factor of 4.”
– from 1980 popularized by Steve
Assignments McConnell
Estimates
“Software Engineering Economics”
– Barry Bohem (1981)
11. Transparency - Feedback
Customer Done, Done,
Not Started In Progress Testing Review Done
Story #1
Story #2
Story #3
Story #4
Story #5
Story #6
Story #7
Story #8
Story #9
Story #10
13. 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
14. Basic Agile Mindset
• Never get blocked
• Decouple yourself from the others
• Abstract the dependencies
• Mock or Stub the unknowns
• Feed your assumptions into evolving design
• Incremental improvements
• “First make it work, then make it right, then make it fast”
15. Development
Orthogonal Code
• Separation of Concerns
• Cohesion
• Coupling
Don’t Repeat Yourself Principle (DRY)
Don’t build frameworks
Design for Testability
16. 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
23. Coding Katas
Effortful study means
constantly tackling
problems at the very edge
of your ability. Stuff you
may have a high probability
of failing at. Unless you're
failing some of the time,
you're probably not growing
professionally. You have to
seek out those challenges
and push yourself beyond
your comfort limit.
– Coding Horror (Jeff Atwood)
24. 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
• Long methods
Software entropy is the enemy!
25. “Boy scout” Rule
“…Commit your code in a better shape than the
one it was when you started working on it. “
– “Uncle” Bob Martin
26. 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
27. 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
28. 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
29. Where Reversibility breaks
• Dependencies on external teams or external experts
• Publicly published interfaces
• Too late – other components may force your hand
• It’s important to decide when to decide!
30. Design Feedback
• SMELL test
• Mockups for customers
• Any Design is theory until proven
• 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
31. 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
32. Package Cohesion Principles
The Release Reuse The granule of reuse is the
REP
Equivalency Principle granule of release.
The Common Closure Classes that change together are
CCP
Principle packaged together.
The Common Reuse Classes that are used together
CRP
Principle are packaged together.
33. Package Coupling Principles
The Acyclic Dependencies The dependency graph of packages
ADP
Principle must have no cycles.
The Stable Dependencies
SDP Depend in the direction of stability.
Principle
The Stable Abstractions Abstractness increases with
SAP
Principle stability.
34. Development feedback?
• Continuous integration
• Continuous deployment
• Unit tests
• Code coverage
• Test automation
35. 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? Really?
• If the test fails – what does this mean?
• Do we know what failed?
36. 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
38. 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
39. 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
40. 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
41. 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
“Code Leaders and Beautiful
Teams”
– Roy Osherove
43. 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)
44. Thanks for ideas
Martin Fowler – Is Design Dead
“Uncle” Bob Martin – Principles of Agile Design
Jeremy D Miller – How Design Gets Done on an Agile Project
Roy Osherov
Others …
