Why lean?

Designing and Maintaining Software (DAMS)
 Louis Rose

Habitable Software Leaner

Avoids Duplication

Less Complex

Clearer

Loosely Coupled

More Extensible

More Cohesive

???

Lean “Perfection is finally achieved not when there
 is no longer anything to add, but when there
 is no longer anything to take away.” - Antoine de Saint-Exupery

Lean software… Has no extra parts Solves the problem at hand and no more Is often easier to change (i.e., is more habitable)

YAGNI The argument in favour of lean software (part 1)

You Ain’t Gonna Need It!

“Always implement things when you actually
 need them, never when you just foresee that
 you need them.” - Ron Jeffries

YAGNI Examples Don’t implement a feature today that you
 won’t be shipping for a long time. Don’t use a database when flat files will do. Avoid “speculative generality”.

UNIX Philosophy

Favour small, focused and composable tools
 over large, monolithic and integrated tools.

UNIX Example Problem:
 Count number of DAMS students named “Bob” Solution:
 Write a bespoke program

UNIX Philosophy Problem:
 Count number of DAMS students named “Bob” Solution:
 Write a bespoke program

UNIX Philosophy Problem:
 Count number of DAMS students named “Bob” Solution:
 Reuse existing programs: cat dams_students.csv | grep Bob | wc -l


Microservices

http://martinfowler.com/articles/microservices.html

Worse is Better The argument in favour of lean software (part 2)

The Right Thing Simplicity

The implementation and the interface must be simple.

Correctness

The design must be correct in all observable aspects.
 Incorrectness is not allowed.

Consistency

The design must not be inconsistent.
 A design can be less simple / complete to allow consistency.

Completeness

The design must cover as many use cases as is practical.
 Simplicity is not allowed to overly reduce completeness.

http://dreamsongs.com/WIB.html

Worse is Better Simplicity

The implementation and the interface must be simple.
 Simplicity is the most important design consideration.

Correctness

The design must be correct in all observable aspects.
 It is slightly better to be simple than correct.

Consistency

The design must not be overly inconsistent.
 A design can sometimes be inconsistent to allow simplicity.

Completeness

The design must cover as many use cases as is practical.
 Completeness can be sacrificed for any other quality.

http://dreamsongs.com/WIB.html

“Worse is Better” is Better Quality does not necessarily increase
 with functionality WIB software is more likely to “survive”
 and be improved over time “Unix and C are the the ultimate computer viruses”

KISS

Keep it simple, stupid!

When lean is mean The argument against lean software

Overheads If I split a class, I have to edit >1 file If I split a program, I have to manage >1 project If I split an application, I have to manage >1 server

Legacy Systems I have a huge, bloated, monolith.
 Where do I start? Huge: refactor as you go.
 Bloated: run coverage in production.
 Monolith: start to identify boundaries in the domain.

Designing and Maintaining Software (DAMS) - GitHub

Habitable Software. Leaner. Less Complex. Loosely Coupled. More Cohesive. Avoids Duplication. Clearer. More Extensible ??? Page 3. Lean. “Perfection is finally achieved not when there is no longer anything to add, but when there is no longer anything to take away.” - Antoine de Saint-Exupery. Page 4. Lean software…

196KB Sizes 0 Downloads 107 Views

Recommend Documents

Designing and Maintaining Software (DAMS) - GitHub
ASTs are tree data structures that can be analysed for meaning (following JLJ in SYAC 2014/15) ... More Cohesive. Avoids Duplication. Clearer. More Extensible.

Designing and Maintaining Software (DAMS) - GitHub
%w.rack tilt date INT TERM..map{|l|trap(l){$r.stop}rescue require l};. $u=Date;$z=($u.new.year + 145).abs;puts "== Almost Sinatra/No Version has taken the stage on #$z for development with backup from Webrick". $n=Module.new{extend. Rack;a,D,S,q=Rack

Designing and Maintaining Software (DAMS) - GitHub
Clear Documentation. Designing and Maintaining Software (DAMS). Louis Rose. Page 2. Bad documentation. Misleading or contradictory find_customer(id). CustomerGateway. Used to look up a customer by their customer number. Page 3. Bad documentation. Red

Designing and Maintaining Software (DAMS) - GitHub
R&D: sketch habitable solutions on paper, using UML. 4. Evaluate solutions and implement the best, using TDD. Probably start again at 3. 5. Give to the product owner to validate. Probably start again at 1. 6. Put into production for customers to eval

Designing and Maintaining Software (DAMS) - GitHub
Observers. Designing and Maintaining Software (DAMS). Louis Rose. Page 2. Page 3. Delivery people need to know when pizzas are ready class Pizza def initialize(delivery_person). @delivery_person = delivery_person end def bake cook # blocking call. @d

Designing and Maintaining Software (DAMS) - GitHub
When we are testing the way that a unit behaves when a condition is met, use a stub to setup the condition. Solution: use stubs for queries class Subscription ... def bill(amount) unless payments.exists(subscription_id: id) payments.charge(subscripti