HEALTHY

KEEPING

SOFTWAREDEVELOPMENT

ECOSYSTEM

Dainius Mežanskas © 2015Software Architect @ Intermedix Corp.

dainius.mezanskas@gmail.com www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt

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

DESIGNSoftware

TEAMT-DEBT

DEMO

DESIGN

CODE

DESIGN

ARCHITECTURE

because of –ilities!

DESIGN...is important!why?

MAINTAINABILITY SECURITYTESTABILITY SCALABILITYEXTENSIBILITY USABILITYRELIABILITY VULNERABILITY

-ilities

... and several dozens more

system quality attributes

-ilitiesACCESSIBILITY ACCOUNTABILITY ACCURACY ADAPTABILITY ADMINISTRABILITY AFFORDABILITYAGILITY AUDITABILITY AUTONOMY AVAILABILITY COMPATIBILITY COMPOSABILITYCONFIGURABILITY CORRECTNESS CREDIBILITY CUSTOMIZABILITY DEBUGABILITYDEGRADABILITY DETERMINABILITY DEMONSTRABILITY DEPENDABILITY DEPLOYABILITYDISCOVERABILITY DISTRIBUTABILITY DURABILITY EFFECTIVENESS EFFICIENCY EVOLVABILITYEXTENSIBILITY FAILURE TRANSPARENCY FAULT-­TOLERANCE FIDELITY FLEXIBILITYINSPECTABILITY INSTALLABILITY INTEGRITY INTERCHANGEABILITY INTEROPERABILITYLEARNABILITY MAINTAINABILITY MANAGEABILITY MOBILITY MODIFIABILITY MODULARITYOPERABILITY ORTHOGONALITY PORTABILITY PRECISION PREDICTABILITY PROCESSCAPABILITIES PRODUCIBILITY PROVABILITY RECOVERABILITY RELEVANCE RELIABILITYREPEATABILITY REPRODUCIBILITY RESILIENCE RESPONSIVENESS REUSABILITY ROBUSTNESSSAFETY SCALABILITY SEAMLESSNESS SELF-­SUSTAINABILITY SERVICEABILITY SECURABILITYSIMPLICITY STABILITY STANDARDS COMPLIANCE SURVIVABILITY SUSTAINABILITYTAILORABILITY TESTABILITY TIMELINESS TRACEABILITY UBIQUITY UNDERSTANDABILITYUPGRADABILITY USABILITY

All?

https://en.wikipedia.org/wiki/List_of_system_quality_attributes

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

DESIGNIS IMPORTANT?

Espe

cially

for..

.

§ PRODUCTION CODE

§ TESTS

§ BUILDS | DEPLOYMENT | AUTOMATION

§ TOOLS

§ UX

§ PROCESSES

DESIGNapplies to

WHOISRESPONSIBLE

FOR DESIGN?and quality

IS

RESPONSIBILITYTEAM

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 PAIRING...if there are new ideas or challenges

GITFLOW

2 MEMBERS TO APPROVE

WORKFLOW

OFFLINE PAIRINGPULL REQUESTS

TWO HEADS ARE BETTER THAN ONE

...it is like

...are four even better?

POC

WORKING CODE CHUNKS

… in separate repo ...fully of partially functional

...discuss with teamDESIGN PROTOTYPE

a.k.a. proof of concept

EXAMPLARSPRODUCTION

READY ARTIFACTS

CREATED FROM SCRATCH

...reusable examples

... or pre-generated

ARCHITECTURE

& DESIGN

POTENTIAL BUGS

COMPLEXITY

DUPLICATIONS

CODING RULES

COMMENTS

STATICCODE ANALYSIS

§ MULTIPLE LANGUAGES

§ CROSS-TEAM RULES

§ TIME MACHINE

§ CODE COVERAGE

§ IDE PLUGIN

§ 60+ PLUGINS

son

arqu

be

INFORMATION RADIATORsonarqube

DEBTTECHNICAL

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.

REASONS✓ BUSINESS PRESSURE

LACK

OF ✗ PROCESS, KNOWLEDGE or COLLABORATION

✗ ALIGNMENT TO STANDARDS

✗ TEST SUITE, DOCUMENTATION

✗ LOOSELY COUPLED COMPONENTS

✓ PARALLEL DEVELOPMENT✓ DELAYED REFACTORING

TECHNICAL DEBT

§ POSTPONED RELEASES

§ CONSTANT HOT FIXES

§ BEING SCARED ON CHANGING ANYTHING

§ LOW CODE COVERAGE

§ UNREDABLE CODE, EVIL HACKS

... what are your TD symptoms?

SMYTOPMSTNECHAICL

§ CLEAN CONSTANTLY (10%+)

§ ATTACK NEXT T.D.

§ DEFINE OUTCOMES

§ EVALUATE CHANGES

§ CLEANUP RELEASES

REMOVINGTECHNICAL DEBT

of P 1

PROPERTY

vs.INJECTION

CONSTRUCTORINJECTION

§ BETTER TESTABILITY

§ ALL DEPENDENCIES VISIBLE IN ONE PLACE

§ ENCAPSULATION IS PRESERVED

§ TOO MANY DEPENDENCIES - SRP IS BROKEN?

CONSTRUCTOR DI

“

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.

— Ernest Hemingway

“

Stay clean, stay agile. Encourage others.— Internet wisdom

LAST...but not least

THANK YOU

Q&ADainius Mežanskas © 2015

Software Architect @ Intermedix Corp.

dainius.mezanskas@gmail.com www.agileturas.lt/kaunas intermedix.com kaunas-jug.lt