Simple design

Simple Design

and

Development Strategy

for agile teams

Duong Trong Tan

[email protected]

Objectives

• Issues of Planned

Design

• What is Simple

Design?

• Simplicity

• Design for Code

• Design for

Communication

• Design for

Collaboration

• Refactoring

• Simple Design in

practice

2

Design is the key,

Planned Design is not … • Takeuchi & Nonaka: overlapping is better than sequential

Not efficient:

• Time consuming

• No backward

• No “better idea” on the go

But how to do this kind of overlapping development?

3

What is Simple Design?

• Design grows as implementation

– Complete design NOT required. Just enough, GO!

• Part of programming processes

• Program evolves the design changes

• Not “code and fix” tactics

Evo

lve

4

Simplicity Rationale behind Simple Design

• "Do the Simplest Thing that Could Possibly Work“

• "You Aren't Going to Need It“

• Invest in patterns

• Simple system 1. Runs all the Tests

2. Reveals all the intention

3. No duplication

4. Fewest number of classes or methods

5

Design for

Communication • Draw design stuffs for discussion within your

team – Just enough for clarifying solutions

• Only use diagrams that you can keep up to date without noticeable pain

• Keep diagrams visible – Post to wall or board

– Encourage people to edit

• Pay attention to whether people are using them, if not throw them away.

6

Design for Construction • “Working software is the primary

measure of progress”

• Your design will be realized into a working

item, so:

– Design should be code-able in team

• separation, interfacing, collaboration between

components

– Design should be testable

– “Architect must code!”

7

Refactoring • For simpler design

• For maintenance\upgrade

later

• MustHave task in your

DoneDefinition checklist

• Invest in patterns and best

practices

Learn more: http://www.refactoring.com/

Image: http://www.testically.org

8

Development Flow

Requirement Analysis

UI Mocking

•Customer discussion

Design Draft

•Design Discussion

Code the skeleton to

test the design

Coding in team

Refactoring and

Refinement

Build the increment

$

DevTeam PO

Collaboration:

Steps:

Artifacts: As a super user,

I want to …

A

B

IDo

Interface IDo{

//TODO …

}

Class A{

//TODO …

}

Class B:IDo{

//TODO …

}

Note: 1. TDD|BDD|AMDD can be used or not

2. Images are for illustration only

Interface IDo{

//TODO …

}

Class A{

method1(){

//Mr. A codes here

}

}

Class B:IDo{

method1(){

//Mrs. B codes here

}

}

Class C{

}

$

PO

9

How about Architecture?

• PO works with DevTeam to specify

– Technologies used

– Frameworks used

– Initial Architecture

• Before Sprint 1

– @User Story Writing workshop

– @ Initial Requirement Envisioning and Initial

Architecture Envisioning

10

Evolution of Models

11

com.myapp.Models

com.myapp.Views

com.myapp.Controllers

Sprint 0

updated story

V1

M1

IDo C1

V1

M1

IDo C1

V2

M2

Sprint 1 Sprint 2

Product

Backlog

Items burnt

Items burnt

Initial Architecture Model1 Model 2

“Continuous” Architecting Sprint #1: without layering

12

Presentation Tier Application Layer Business Layer Data Access Layer Data Tier

“Continuous” Architecting Sprint #2: refactoring to layers

13

Presentation Tier Application Layer Business Layer Data Access Layer Data Tier

“Continuous” Architecting Sprint #3: architecting “on the go”

14

Presentation Tier Application Layer Business Layer Data Access Layer Data Tier

Summary

• A good design is simple

• Keep It Simple, Stupid!

• Using incremental design for agile

development

• Design evolves during development

process

• Using refactoring to maintain simplicity

• There should be a vision for architecture

15

References • Agile Alliance, Agile Manifesto http://agilemanifesto.org

• H. Takeuchi & I. Nonaka, The new new

Product development game, Harvard

Business Review, 1986.

• M. Fowler, Is Design Dead? http://martinfowler.com/articles/designDead.html

• http://www.refactoring.com/

16