Software Design and Technical Debts

Post on 30-Jul-2015

47 views 3 download

Tags:

Transcript of Software Design and Technical Debts

Software Designand “Technical Debts”

“TECHNICAL DEBT”

“With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest.” -- Ward Cunningham

“Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.” -- Martin Fowler

“A Mess is not a Technical Debt!” -- Robert C. Martin

SOFTWARE QUALITYWHAT IS WRONG WITH

The distance ...

Structural Problem/Defect

Schedule pressure

Trade-off

By design

Lack of knowledge Laziness; Unprofessionalism

Techinical Debt Design Flaw Mess

Software Structural Problems

Development speed

Predictability

Customer satisfaction

Cost of Change

VIOLATIONS MONETIZE

Tracking

Monetize

Schedule pressure

Trade-off

By design

Lack of knowledge Laziness Unprofessionalism

Techinical Debt Design Flaw Mess

Software Structural Problems

HOWAND

WHEN

Repayment Plan

Budgeting

Schedule pressure

Trade-off

By design

Lack of knowledge LazinessUnprofessionalism

Techinical Debt Design Flaw Mess

Software Structural Problems

Schedule pressure

Trade-off

By design

Lack of knowledge Laziness Unprofessionalism

Techinical Debt Design Flaw Mess

Software Structural Problems

If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.

Problem (Context)

Requirements

Information (Nature)

Dependencies

Personas

Inputs/Outputs

Solution

SOC

SOLID

Package Principles

Algorithm

Compositions

Design Patterns

1. Runs all the tests;

2 . Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies;

3. States every intention important to the programmer;

4. Has the fewest possible classes and methods.

Simplicity Rules

1. Passes the tests;

2. Reveals intention;

3. No duplication;

4. Fewest elements.

Simplicity Rules

WAYOF

CHANGE

Rigidity, Fragility, Immobility, Viscosity, Opacity,Nedless Complexity, Needless Repetition

Design Session

Just Enough

Who asked knows what was askedI know what was askedThe constraints are knownDefinition of done

Conceptual integrityConstraintsTechnology choicesSoCSimplicity Rules

Expertise

THANKS!

Rafael Souza

rafaelsouza.eng.br

rafael_psouza

rafaelpsouza