Keeping software development ecosystem healthy

Keeping software development ecosystem healthy from Dainius Mezanskas

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 § 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 PRESSURELACKOF ✗ 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. § BETTERTESTABILITY § ALL DEPENDENCIES VISIBLE IN ONE PLACE § ENCAPSULATION IS PRESERVED § TOO MANY DEPENDENCIES - SRP IS BROKEN? CONSTRUCTOR DI
29. 29. “ 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
30. 30. THANK YOU Q&A Dainius Mežanskas © 2015 Software Architect @ Intermedix Corp. dainius.mezanskas@gmail.comwww.agileturas.lt/kaunas intermedix.com kaunas-jug.lt