talk @ Agile Gurgaon 2016
Copyright © 2015 SolutionsIQ Inc. All rights reserved.
6801 185th Ave NE, Suite 200
Redmond, WA 98052
solutionsiq.com
1.800.235.4091
Change Vector Tracking
A reflective approach towards designing large scale
software
BY
Ranjith Tharayil
Senior Agile Consultant & Technical Coach
rtharayil@soultionsiq.com
Expectations and take always
Understand the problem wrt design debt in large scale software systems.
Exposure to a novel technique called Change Vector Tracking (CVT)
Can start applying it right away
Knowledge of how change can be modelled as a weighted vector
Using CVT to make informed decision on architecture refactoring.
talk @ Agile Gurgaon 2016
About Me
https://in.linkedin.com/in/ranjiththarayil
Ranjith Tharayil
talk @ Agile Gurgaon 2016
talk @ Agile Gurgaon 2016
Design Is a Wicked Problem , a “wicked” problem is one that
could be clearly defined only by solving it, or by solving part of it
.This paradox implies, essentially, that you have to “solve” the
problem once in order to clearly define it and then solve it again
to create a solution that works
“
”
- McConnell, Steve. Code complete. Pearson Education, 2004.
Architecture style wrt embracing change
Organic
Architecture
Architecture
first
Just enough
Architecture
Emergent
Architecture
talk @ Agile Gurgaon 2016
Emergent design
Test Code Refactor
Test Code Refactor
Test Code Refactor
Test Code Refactor
Test Code Refactor
Test Code Refactor
Test Code Refactor
Test Code Refactor
Design
talk @ Agile Gurgaon 2016
Problem : Refactoring less focus on
architecture
System
Sub-
system
Modules
Modules
Modules
Sub-
system
Modules
Modules
Modules
Sub-
system
Modules
Sub-
system
Modules
modules
Refactoring , observed trends
»More focus on classes inside
modules
»Less focus on Modules ,sub-
Subsystem and system
»Inexperience team members
»Accumulate design debt
»Technical debt
talk @ Agile Gurgaon 2016
Example : Super Market
I 'am using a simple example to explain the problem , same is applicable for bigger complex systems
The super market has many products to sell
Each product has a
 quality
 cost
The rules for computation of Quality and Cost are different for
each product
Abstract Product
computeQuality()
computeCost ()
Concreate product 1
Concreate product 2
Concreate product n-1
Concreate product N
Example of a
concreate product
talk @ Agile Gurgaon 2016
Is this the best design ?
Onion
computeQuality()
computeCost ()
»Is this following SRP ? Single responsibility principle
»SRP : A class should have only one reason to change
»What if the pricing strategy of a product varies
from time to time ?
talk @ Agile Gurgaon 2016
How about a different design
Abstract Product
Pricing strategy
computeQuality()
Concreate product 1
Concreate product 2
Concreate product n-1
Concreate product N
PricingStrategy
CompteCost()
Strategy 1
Strategy 2
Strategy 3
talk @ Agile Gurgaon 2016
Another design
Product
PricingStrategy
QualityRule
PricingStrategy
CompteCost()
Strategy 1
Strategy 2
Strategy 3
QualityRule
Quality()
Rule 1
Rule 2
talk @ Agile Gurgaon 2016
Which design is better ?
talk @ Agile Gurgaon 2016
Which design is better ?
Answer is : it depends
Dependents on what ?
Lest try to define this context
Context
talk @ Agile Gurgaon 2016
Which design is better ?
If mostly we will be only adding / removing products
talk @ Agile Gurgaon 2016
Which design is better ?
• We will be constantly adding new products , also
• We need to modify pricing strategy every now and then
for existing products
talk @ Agile Gurgaon 2016
Which design is better ?
• We need to often modify both pricing strategy & quality
rule for existing products
talk @ Agile Gurgaon 2016
Design should depend on how the system
should behave
The behaviour of a system changes with time
Due to
new requirements
enhancements
Change is constant and can disrupt design & architecture
Need to track change and its effect on design/architecture
talk @ Agile Gurgaon 2016
Modelling change as a vector
Change has multiple dimensions
Hence it can be quantified using a vector like ax+by+cz
Example:
3(New Products) +
2(Modify Pricing strategy)
4(New Products) +
1(Miscellaneous)
2(Modify Pricing strategy) +
2(Modify Quality rule) +
1(Miscellaneous)
talk @ Agile Gurgaon 2016
How change can be modelled as a weighted
vector ?
We need to periodically review & document change vector for our system
3(New Products)
+
2(Modify Pricing strategy)
4(New Products)
+
1(Miscellaneous)
Few Months
Change: new requirement , Enhancement
Change
requests
Dev
Track
Change
vector
Refactor
talk @ Agile Gurgaon 2016
Change vector tracking from Architecture to
class
System
Sub-
system
Modules
classes
Modules
classes
Sub-
system
Modules
classes
Change
requests
Dev
Track
Change
vector
Refactor
talk @ Agile Gurgaon 2016
Change vector tracking in context of micro services
talk @ Agile Gurgaon 2016
Process and Ceremonies
• Change vector tracking meeting
• with TL , Architects
• Every month initially
• Cadence decide by need
• Time boxed
• Analyse change request from
• Source control (Past)
• Analyse product backlog (Future)
• Document Change vector
• Identify if any design debt , ideally you should have none
Change
requests
Dev
Track
Change
vector
Refactor
talk @ Agile Gurgaon 2016
Re-visiting expectations
Understand the problem wrt design debt in large scale software systems.
Exposure to a novel technique called Change Vector Tracking (CVT)
Can start applying it right away
» Add this jargon to your resume :P
Knowledge of how change can be modelled as a weighted vector
Using CVT to make informed decision on architecture refactoring.
talk @ Agile Gurgaon 2016
Questions
Acknowledgments :
After hearing out this technique Sharad Julka coined the term reflective design .
talk @ Agile Gurgaon 2016

Change vector tracking in emergent design

  • 1.
    talk @ AgileGurgaon 2016
  • 2.
    Copyright © 2015SolutionsIQ Inc. All rights reserved. 6801 185th Ave NE, Suite 200 Redmond, WA 98052 solutionsiq.com 1.800.235.4091 Change Vector Tracking A reflective approach towards designing large scale software BY Ranjith Tharayil Senior Agile Consultant & Technical Coach rtharayil@soultionsiq.com
  • 3.
    Expectations and takealways Understand the problem wrt design debt in large scale software systems. Exposure to a novel technique called Change Vector Tracking (CVT) Can start applying it right away Knowledge of how change can be modelled as a weighted vector Using CVT to make informed decision on architecture refactoring. talk @ Agile Gurgaon 2016
  • 4.
  • 5.
    talk @ AgileGurgaon 2016 Design Is a Wicked Problem , a “wicked” problem is one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works “ ” - McConnell, Steve. Code complete. Pearson Education, 2004.
  • 6.
    Architecture style wrtembracing change Organic Architecture Architecture first Just enough Architecture Emergent Architecture talk @ Agile Gurgaon 2016
  • 7.
    Emergent design Test CodeRefactor Test Code Refactor Test Code Refactor Test Code Refactor Test Code Refactor Test Code Refactor Test Code Refactor Test Code Refactor Design talk @ Agile Gurgaon 2016
  • 8.
    Problem : Refactoringless focus on architecture System Sub- system Modules Modules Modules Sub- system Modules Modules Modules Sub- system Modules Sub- system Modules modules Refactoring , observed trends »More focus on classes inside modules »Less focus on Modules ,sub- Subsystem and system »Inexperience team members »Accumulate design debt »Technical debt talk @ Agile Gurgaon 2016
  • 9.
    Example : SuperMarket I 'am using a simple example to explain the problem , same is applicable for bigger complex systems The super market has many products to sell Each product has a  quality  cost The rules for computation of Quality and Cost are different for each product Abstract Product computeQuality() computeCost () Concreate product 1 Concreate product 2 Concreate product n-1 Concreate product N Example of a concreate product talk @ Agile Gurgaon 2016
  • 10.
    Is this thebest design ? Onion computeQuality() computeCost () »Is this following SRP ? Single responsibility principle »SRP : A class should have only one reason to change »What if the pricing strategy of a product varies from time to time ? talk @ Agile Gurgaon 2016
  • 11.
    How about adifferent design Abstract Product Pricing strategy computeQuality() Concreate product 1 Concreate product 2 Concreate product n-1 Concreate product N PricingStrategy CompteCost() Strategy 1 Strategy 2 Strategy 3 talk @ Agile Gurgaon 2016
  • 12.
    Another design Product PricingStrategy QualityRule PricingStrategy CompteCost() Strategy 1 Strategy2 Strategy 3 QualityRule Quality() Rule 1 Rule 2 talk @ Agile Gurgaon 2016
  • 13.
    Which design isbetter ? talk @ Agile Gurgaon 2016
  • 14.
    Which design isbetter ? Answer is : it depends Dependents on what ? Lest try to define this context Context talk @ Agile Gurgaon 2016
  • 15.
    Which design isbetter ? If mostly we will be only adding / removing products talk @ Agile Gurgaon 2016
  • 16.
    Which design isbetter ? • We will be constantly adding new products , also • We need to modify pricing strategy every now and then for existing products talk @ Agile Gurgaon 2016
  • 17.
    Which design isbetter ? • We need to often modify both pricing strategy & quality rule for existing products talk @ Agile Gurgaon 2016
  • 18.
    Design should dependon how the system should behave The behaviour of a system changes with time Due to new requirements enhancements Change is constant and can disrupt design & architecture Need to track change and its effect on design/architecture talk @ Agile Gurgaon 2016
  • 19.
    Modelling change asa vector Change has multiple dimensions Hence it can be quantified using a vector like ax+by+cz Example: 3(New Products) + 2(Modify Pricing strategy) 4(New Products) + 1(Miscellaneous) 2(Modify Pricing strategy) + 2(Modify Quality rule) + 1(Miscellaneous) talk @ Agile Gurgaon 2016
  • 20.
    How change canbe modelled as a weighted vector ? We need to periodically review & document change vector for our system 3(New Products) + 2(Modify Pricing strategy) 4(New Products) + 1(Miscellaneous) Few Months Change: new requirement , Enhancement Change requests Dev Track Change vector Refactor talk @ Agile Gurgaon 2016
  • 21.
    Change vector trackingfrom Architecture to class System Sub- system Modules classes Modules classes Sub- system Modules classes Change requests Dev Track Change vector Refactor talk @ Agile Gurgaon 2016
  • 22.
    Change vector trackingin context of micro services talk @ Agile Gurgaon 2016
  • 23.
    Process and Ceremonies •Change vector tracking meeting • with TL , Architects • Every month initially • Cadence decide by need • Time boxed • Analyse change request from • Source control (Past) • Analyse product backlog (Future) • Document Change vector • Identify if any design debt , ideally you should have none Change requests Dev Track Change vector Refactor talk @ Agile Gurgaon 2016
  • 24.
    Re-visiting expectations Understand theproblem wrt design debt in large scale software systems. Exposure to a novel technique called Change Vector Tracking (CVT) Can start applying it right away » Add this jargon to your resume :P Knowledge of how change can be modelled as a weighted vector Using CVT to make informed decision on architecture refactoring. talk @ Agile Gurgaon 2016
  • 25.
    Questions Acknowledgments : After hearingout this technique Sharad Julka coined the term reflective design . talk @ Agile Gurgaon 2016