Pay off Technical Debt by Good Code

tung_nt@septeni-technology.jp
Pay off Technical Debt by
Good Code
...and more
TechTalk 10 - 2016

Agenda
I. Technical Debt
– What’s technical debt & why it’s important
– Bad smells
– Consequences
– Where does it come from?
II. How to deal with it?
– Supple & Clean Design
– Clean Code Principles
– Agile method
III. Measuring & Tools
– Metrics
– Code analyzer tool
IV. Resources
– Good books

I. Technical Debt

Technical Debt ?
Technical Debt is a metaphor
developed by Ward
Cunningham in 1992 to
communicate problems due
to "developing not in the right
way" with non-technical
stakeholder

2 ways to do things
Quick and Dirty Slow and Clean

You may be thinking…

Debt isn’t always a bad thing...
But don't underestimate your risks.

Cancer & Diabetes
● The top two causes of death.
● Cannot be cured.
● Difficult to diagnose: we are failing to spot them until it’s
too late ~> The Silent Killer

Because...
Technical Debt like Cancer or Diabetes, It’s a
Silent Killer too. And nobody cares until it’s to
late.

What’s your choice?
Tradeoff: Pay it now or later (...with interest)?

Don’t let the debt kill your project

Bad smells

“Only he know how to change it.”

“If I touch, everything will break.”

Too many Todos

Legacy Codebase
The code is simply unreadable, and borders on
indecipherable.

Data structures are haphazardly
constructed, or non-existent

Hard to change or scale

Code duplication

Lack of documentation
- Did we mention documentation?
- What documentation?

Consequences

Big ball of Mud
… alias Shantytown or Spaghetti Code. A big ball of mud is a
software system that lacks a perceivable architecture

Loss of Productivity

Reduce your software quality

Being scared of changing anything

Can be stress

Cost increases

Uhm, So...

Where does debt & mud come from?

Common causes
● Business pressures
● Lack of process or understanding
● Lack of building loosely coupled components
● Lack of a test suite
● Lack of documentation
● Lack of collaboration
● Parallel development

Common Causes (cont.)
● Delayed refactoring
● Lack of alignment to standards
● Lack of knowledge
● Lack of ownership
● Poor technological leadership
● Last minute specification changes
● Scope Doping

II. How to deal with them

Supple and Clean Design

Making Behavior Obvious

Intention-revealing interfaces
● Name classes and operations to describe their
effect and purpose
● These names should conform to the
Ubiquitous Language so that team members
can quickly infer their meaning.

Side-effect-free functions
● Place as much of the logic of the program as
possible into functions
● Strictly segregate commands into very simple
operations that do not return domain
information.

Assertions
● State post-conditions of operations and invariants of
classes and Aggregates.
● If Assertions cannot be coded directly in your
programming language, write automated unit tests for
them.
● Write them into documentation or diagrams where it fits
the style of the project’s development process.
● Accelerating the learning curve and reducing the risk of
contradictory code.

Reducing Cost of Change

Conceptual Contours
● Decompose design elements (operations,
interfaces, classes, and Aggregates) into
cohesive units.

Standalone Classes
● The class will be completely self-contained and
can be studied and understood alone.
● Self-contained class significantly eases the
burden of understanding a Module.

Design By Contract
● Defensive programming style

Clean code

DRY
● Don’t repeat yourself

SOLID
● S - Single responsibility principle
– a class should have only a single responsibility (i.e. only one potential change in the software's
specification should be able to affect the specification of the class)
● O - Open/closed principle
– “software entities … should be open for extension, but closed for modification.”
● L - Liskov substitution principle
– “objects in a program should be replaceable with instances of their subtypes without altering the
correctness of that program.”
● I - Interface segregation principle
– “many client-specific interfaces are better than one general-purpose interface.”
● D - Dependency inversion principle
– one should “Depend upon Abstractions. Do not depend upon concretions.”

High cohesion & Low coupling
● Loose coupling makes it possible to:
– Understand one class without reading others
– Change one class without affecting others
– Improves maintainability
● High cohesion makes it easier to:
– Understand what a class or method does
– Reuse classes or methods

YAGNI & KISS
● You aren't gonna need it
● Keep it simple, stupid

TDD
● Focus into acceptance criteria
● Make code testable

Agile method

Definition of Done (DoD)
● Clear DoD make Design By Contract and TDD
coding style applied easier

Technical backlog
● Manage by PM or Technical Leader
● Easy to monitor
– Debt size
– The velocities of debt fixing
– Fix by debt priority
● No mixture between technical and feature task
● Visible and clear to everybody

Cost of Change
● Code of change curve with the feedback cycle

Fail fast

Refactor AS SOON AS POSSIBLE

III. Measuring & Tools

Measurement

Only one rule you need remember

That’s the joke

Metric 1
● Compiler warning / error

Metric 2
● TODOs

Metric 3
● Amount of Duplicate code

Metric 4
● Test coverage & C.R.A.P index (Change Risk
Analysis and Predictions)

Metric 5
● Total Line Of Code in 1 file
@Bulk members: BulkLogicComponent.php, do you remember?

Evaluate Debt
Debt (in man days) =
cost_to_fix_duplications +
cost_to_fix_violations +
cost_to_comment_public_API +
cost_to_fix_uncovered_complexity +
cost_to_bring_complexity_below_threshold
Where :
Duplications = cost_to_fix_one_block * duplicated_blocks
Violations = cost_to fix_one_violation * mandatory_violations
Comments = cost_to_comment_one_API * public_undocumented_api
Coverage = cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of
coverage is the objective)
Complexity = cost_to_split_a_method * (function_complexity_distribution >= 8) + cost_to_split_a_class
* (class_complexity_distribution >= 60)

Tools

Sonarqube
● SonarQube(sonarqube.org) is an open platform to
manage code quality.

PMD - Don't shoot the messenger
● Is a source code analyzer.
● Only CPD (the copy-paste-detector) is supported for Scala :(

Jacoco – Scoverage
● Both of them are code coverage tool
● Jenkin plugin is supported

Gatling – Stress test tool
● Gatling is an open-source load testing framework based on Scala, Akka and Netty
● Scenario recorder and developer-friendly DSL
● Ready-to-present HTML reports

Resources
● Read these:

One more thing...

References
1.https://en.wikipedia.org/wiki/Technical_debt
2.http://www.levihackwith.com/how-to-read-and-improve-the-c-r-a-p-index-o
3.http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/
4.https://blog.codinghorror.com/paying-down-your-technical-debt/
5.https://dzone.com/articles/real-cost-change-software
6.http://www.agilemodeling.com/essays/costOfChange.htm
7.http://www.dodgycoder.net/2013/01/big-ball-of-mud-design-pattern.html
8.https://pressupinc.com/blog/2015/04/why-software-becomes-a-big-ball-of
9.http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-
10.http://www.gregerwikstrand.com/technical-debt-reduction/

Thank you!

Pay off Technical Debt by Good Code

More Related Content

Viewers also liked (9)

Similar to Pay off Technical Debt by Good Code (20)

More from Tung Nguyen (6)

Recently uploaded (20)

Pay off Technical Debt by Good Code