Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
HEALTHY
KEEPING
SOFTWARE
DEVELOPMENT
ECOSYSTEM
Dainius Mežanskas © 2015
Software Architect @ Intermedix Corp.
dainius.meza...
DAINIUS MEŽANSKAS
§ Telecommunications, E-commerce, Health Care,
Insurance, E-learning (17+ years)
§ Developer, Architec...
DESIGN
Software
TEAM
T-DEBT
DEMO
DESIGN
CODE
DESIGN
ARCHITECTURE
because of –ilities!
DESIGN...is important!
why?
MAINTAINABILITY SECURITY
TESTABILITY SCALABILITY
EXTENSIBILITY USABILITY
RELIABILITY VULNERABILITY
-ilities
... and severa...
-ilities
ACCESSIBILITY ACCOUNTABILITY ACCURACY ADAPTABILITY
ADMINISTRABILITY AFFORDABILITY AGILITY AUDITABILITY AUTONOMY
A...
CONTINUOUS  ATTENTION  TO  
TECHNICAL  EXCELLENCE  AND  GOOD  
DESIGN ENHANCES  AGILITY
WHEN
§ LARGE CODE BASE
§ LONG LIVING PRODUCTS
§ DISTRIBUTED | BIG TEAMS
§ HIGH PRICE OF FAILURE
§ HIGH THROUGHPUT
DES...
§ PRODUCTION CODE
§ TESTS
§ BUILDS | DEPLOYMENT | AUTOMATION
§ TOOLS
§ UX
§ PROCESSES
DESIGNapplies to
WHOIS
RESPONSIBLE
FOR
DESIGN
?and quality
IS
RESPONSIBILITY
TEAM
DESIGN
...and every member should be
responsible
A
DEFINE
FOLLOW
REVIEW
IMPROVE
TEAM
ü TECHNICAL VIDEOS
ü SELF-IMPROVEMENT SESSIONS
ü CROSS-TEAM COMMUNICATIONS
ü OFFICE LIBRARY
IMPROVEMENT
PAIRING
üSTART WITH PAIRING
...and define guidelines
üREVIEW RESULTS IN PAIR
...in case task were complex
üRETURN TO PA...
GITFLOW
2 MEMBERS TO APPROVE
WORKFLOW
OFFLINE PAIRING
PULL REQUESTS
TWO HEADS ARE BETTER THAN ONE
...it is like
...are fou...
POC
WORKING CODE CHUNKS
… in separate repo
...fully of partially functional
...discuss with team
DESIGN PROTOTYPE
a.k.a. p...
EXAMPLARS
PRODUCTION
READY ARTIFACTS
CREATED FROM SCRATCH
...reusable examples
... or pre-generated
ARCHITECTURE
& DESIGN
POTENTIAL
BUGS
COMPLEXITY
DUPLICATIONS
CODING
RULES
COMMENTS
STATIC
CODE ANALYSIS
§ MULTIPLE LANGUAGES
§ RULE SETS INHERITANCE
§ CROSS-TEAM RULES
§ TIME MACHINE
§ CODE COVERAGE
§ IDE PLUGIN
§ 60+ P...
INFORMATION RADIATOR
sonarqube
DEBT
TECHNICAL
TECHNICAL  DEBT  IS  A  METAPHOR
THAT  REFLECTS  THE  EXTRA  
DEVELOPMENT  WORK  THAT  ARISES  
WHEN  THINGS  ARE  DONE  Q...
REASONS
✓ BUSINESS PRESSURE
LACKOF
✗ PROCESS, KNOWLEDGE or COLLABORATION
✗ ALIGNMENT TO STANDARDS
✗ TEST SUITE, DOCUMENTAT...
§ POSTPONED RELEASES
§ CONSTANT HOT FIXES
§ BEING SCARED ON CHANGING ANYTHING
§ LOW CODE COVERAGE
§ UNREDABLE CODE, E...
§ CLEAN CONSTANTLY (10%+)
§ ATTACK NEXT T.D.
§ DEFINE OUTCOMES
§ EVALUATE CHANGES
§ CLEANUP RELEASES
REMOVINGTECHNICA...
PROPERTY
vs.
INJECTION
CONSTRUCTORINJECTION
Property Injection
Constructor Injection
§ BETTERTESTABILITY
§ ALL DEPENDENCIES VISIBLE IN ONE PLACE
§ ENCAPSULATION IS PRESERVED
§ TOO MANY DEPENDENCIES - SRP...
“
Prediction is very difficult, especially if it's about the future.
— Niels Bohr“
Great software is not built, it is grow...
THANK YOU
Q&A
Dainius Mežanskas © 2015
Software Architect @ Intermedix Corp.
dainius.mezanskas@gmail.comwww.agileturas.lt/...
REFERENCES
• http://www.agilemanifesto.org/principles.html
• https://en.wikipedia.org/wiki/List_of_system_quality_attribut...
Dainius Mežanskas - Keeping Software Development Ecosystem Healthy
Upcoming SlideShare
Loading in …5
×

Dainius Mežanskas - Keeping Software Development Ecosystem Healthy

352 views

Published on

Agile Tour Kaunas 2015
http://agileturas.lt/kaunas

Published in: Leadership & Management
  • Be the first to comment

  • Be the first to like this

Dainius Mežanskas - Keeping Software Development Ecosystem Healthy

  1. 1. HEALTHY KEEPING SOFTWARE DEVELOPMENT ECOSYSTEM Dainius Mežanskas © 2015 Software Architect @ Intermedix Corp. dainius.mezanskas@gmail.comwww.agileturas.lt/kaunas intermedix.com kaunas-jug.lt
  2. 2. DAINIUS MEŽANSKAS § Telecommunications, E-commerce, Health Care, Insurance, E-learning (17+ years) § Developer, Architect, Team Lead, IT Trainer § Software Architect at Intermedix Corp. § Co-Founder and Leader of Kaunas JUG
  3. 3. DESIGN Software TEAM T-DEBT DEMO DESIGN
  4. 4. CODE DESIGN ARCHITECTURE
  5. 5. because of –ilities! DESIGN...is important! why?
  6. 6. MAINTAINABILITY SECURITY TESTABILITY SCALABILITY EXTENSIBILITY USABILITY RELIABILITY VULNERABILITY -ilities ... and several dozens more system quality attributes
  7. 7. -ilities ACCESSIBILITY ACCOUNTABILITY ACCURACY ADAPTABILITY ADMINISTRABILITY AFFORDABILITY AGILITY AUDITABILITY AUTONOMY AVAILABILITY COMPATIBILITY COMPOSABILITY CONFIGURABILITY CORRECTNESS CREDIBILITY CUSTOMIZABILITY DEBUGABILITY DEGRADABILITY DETERMINABILITY DEMONSTRABILITY DEPENDABILITY DEPLOYABILITY DISCOVERABILITY DISTRIBUTABILITY DURABILITY EFFECTIVENESS EFFICIENCY EVOLVABILITY EXTENSIBILITY FAILURE TRANSPARENCY FAULT-­TOLERANCE FIDELITY FLEXIBILITY INSPECTABILITY INSTALLABILITY INTEGRITY INTERCHANGEABILITY INTEROPERABILITY LEARNABILITY MAINTAINABILITY MANAGEABILITY MOBILITY MODIFIABILITY MODULARITY OPERABILITY ORTHOGONALITY PORTABILITY PRECISION PREDICTABILITY PROCESS CAPABILITIES PRODUCIBILITY PROVABILITY RECOVERABILITY RELEVANCE RELIABILITY REPEATABILITY REPRODUCIBILITY RESILIENCE RESPONSIVENESS REUSABILITY ROBUSTNESS SAFETY SCALABILITY SEAMLESSNESS SELF-­SUSTAINABILITY SERVICEABILITY SECURABILITY SIMPLICITY STABILITY STANDARDS COMPLIANCE SURVIVABILITY SUSTAINABILITY TAILORABILITY TESTABILITY TIMELINESS TRACEABILITY UBIQUITY UNDERSTANDABILITY UPGRADABILITY USABILITY All? https://en.wikipedia.org/wiki/List_of_system_quality_attributes
  8. 8. CONTINUOUS  ATTENTION  TO   TECHNICAL  EXCELLENCE  AND  GOOD   DESIGN ENHANCES  AGILITY
  9. 9. WHEN § LARGE CODE BASE § LONG LIVING PRODUCTS § DISTRIBUTED | BIG TEAMS § HIGH PRICE OF FAILURE § HIGH THROUGHPUT DESIGNIS IMPORTANT?Especiallyfor...
  10. 10. § PRODUCTION CODE § TESTS § BUILDS | DEPLOYMENT | AUTOMATION § TOOLS § UX § PROCESSES DESIGNapplies to
  11. 11. WHOIS RESPONSIBLE FOR DESIGN ?and quality
  12. 12. IS RESPONSIBILITY TEAM DESIGN ...and every member should be responsible A
  13. 13. DEFINE FOLLOW REVIEW IMPROVE
  14. 14. TEAM ü TECHNICAL VIDEOS ü SELF-IMPROVEMENT SESSIONS ü CROSS-TEAM COMMUNICATIONS ü OFFICE LIBRARY IMPROVEMENT
  15. 15. PAIRING üSTART WITH PAIRING ...and define guidelines üREVIEW RESULTS IN PAIR ...in case task were complex üRETURN TO PAIRING ...if there are new ideas or challenges
  16. 16. GITFLOW 2 MEMBERS TO APPROVE WORKFLOW OFFLINE PAIRING PULL REQUESTS TWO HEADS ARE BETTER THAN ONE ...it is like ...are four even better?
  17. 17. POC WORKING CODE CHUNKS … in separate repo ...fully of partially functional ...discuss with team DESIGN PROTOTYPE a.k.a. proof of concept
  18. 18. EXAMPLARS PRODUCTION READY ARTIFACTS CREATED FROM SCRATCH ...reusable examples ... or pre-generated
  19. 19. ARCHITECTURE & DESIGN POTENTIAL BUGS COMPLEXITY DUPLICATIONS CODING RULES COMMENTS STATIC CODE ANALYSIS
  20. 20. § MULTIPLE LANGUAGES § RULE SETS INHERITANCE § CROSS-TEAM RULES § TIME MACHINE § CODE COVERAGE § IDE PLUGIN § 60+ PLUGINS sonarqube
  21. 21. INFORMATION RADIATOR sonarqube
  22. 22. DEBT TECHNICAL
  23. 23. TECHNICAL  DEBT  IS  A  METAPHOR THAT  REFLECTS  THE  EXTRA   DEVELOPMENT  WORK  THAT  ARISES   WHEN  THINGS  ARE  DONE  QUICKLY AND  DIRTY. The term was coined by Ward Cunningham in 1992.
  24. 24. REASONS ✓ BUSINESS PRESSURE LACKOF ✗ PROCESS, KNOWLEDGE or COLLABORATION ✗ ALIGNMENT TO STANDARDS ✗ TEST SUITE, DOCUMENTATION ✗ LOOSELY COUPLED COMPONENTS ✓ PARALLEL DEVELOPMENT ✓ DELAYED REFACTORING TECHNICAL DEBT
  25. 25. § POSTPONED RELEASES § CONSTANT HOT FIXES § BEING SCARED ON CHANGING ANYTHING § LOW CODE COVERAGE § UNREDABLE CODE, EVIL HACKS ... what are your TD symptoms? SMYTOPMS TNECHAICL
  26. 26. § CLEAN CONSTANTLY (10%+) § ATTACK NEXT T.D. § DEFINE OUTCOMES § EVALUATE CHANGES § CLEANUP RELEASES REMOVINGTECHNICAL DEBT of P 1
  27. 27. PROPERTY vs. INJECTION CONSTRUCTORINJECTION
  28. 28. Property Injection
  29. 29. Constructor Injection
  30. 30. § BETTERTESTABILITY § ALL DEPENDENCIES VISIBLE IN ONE PLACE § ENCAPSULATION IS PRESERVED § TOO MANY DEPENDENCIES - SRP IS BROKEN? CONSTRUCTOR DI
  31. 31. “ Prediction is very difficult, especially if it's about the future. — Niels Bohr“ Great software is not built, it is grown. — Bill de hÓra“ There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self. — ErnestHemingway “ Stay clean, stay agile. Encourage others. — Internetwisdom LAST...but not least
  32. 32. THANK YOU Q&A Dainius Mežanskas © 2015 Software Architect @ Intermedix Corp. dainius.mezanskas@gmail.comwww.agileturas.lt/kaunas intermedix.com kaunas-jug.lt
  33. 33. REFERENCES • http://www.agilemanifesto.org/principles.html • https://en.wikipedia.org/wiki/List_of_system_quality_attributes • https://en.wikipedia.org/wiki/Technical_debt • http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-the-danger?related=1 • http://www.slideshare.net/zazworka/identifying-and-managing-technical-debt

×