Agile Embedded Software

Agile Embedded
Software Development
James Grenning
@jwgrenning
james@wingman-sw.com

Agile Embedded Software Development www.wingman-sw.com
Copyright © 2008-2013 James W. Grenning

All Rights Reserved.
Software Development is Easy!
• Just like this Black Diamond
2


We never have any
problems like
• Late Delivery
• Poor Quality
• Burnout
• Missed Customer Expectations
3
Software Development is Easy!


Can Projects be Managed Better?
Figure out
everything, then
do what you
ﬁgured
From Winston Royce’s
original paper on Waterfall
4


All Rights Reserved. 5
Thank you: Hubert Stoffels, from Pittsburgh, USA '''Title:''' Jonathan's Run Falls
'''Description:''' http://commons.wikimedia.org/wiki/File:Jonathan%27s_Run_Falls.jpg


Figure it All Out, Then Do It
6


Steve McConnell
from Rapid Development
“Software projects contain too
many variables to be able to set
schedules with 100-percent
accuracy. Far from having one
particular date when a project
would finish, for any given project
there is a range of completion
dates, of which some are more
likely and some are less.”
8


Project Cost and Schedule Uncertainty
9
time
1x
2x
4x
.25x
.5x
Project  
Complete
Cost
Uncertainty
Initial 
Definition
Requirements 
Specification
Design
1x
1.25x
1.6x
.6x
.8x
Schedule
Uncertainty
Barry Boehm, 1995


What is Agile?
10


Can we get features and functionality to flow?
11


What is Agile?
• Agile software development is a conceptual
framework for undertaking software engineering
projects.  
-- wikipedia
• a.k.a. Extreme Programming, Scrum, Feature Driven
Development, DSDM, Crystal Clear, Agile Unified
Process
12


Agile methods are Designed to...
• Manage with Data
• Improve Visibility
• Improve Predictability
• Improve Quality
• Improve Productivity
• Reduce Waste
13


Agile Principles
• Communications
• Simplicity
• Feedback
• Courage
• Respect
!
!
!
• Visibility
• Honesty
• Realistic
• High Quality
14


www.agilemanifesto.org
15


Individuals and Interactions  
over Processes and Tools
16


Skilled Self-Organizing Teams
• Developers work together to organize the work
• Customer or Product Owner works with the teams to
define work and establish priorities
• Managers usually take an outward focus, removing
roadblock, rather than managing day-to-day tasks and
schedules.
17


Collaboration
• Daily standup meeting
• Pair programming or Daily reviews
• Shared code ownership
• Team room
18


Working Software  
over Comprehensive Documentation
• Each team has different
needs
• Less formal documentation
might work.
• Prefer executable
Documentation
19


Customer Collaboration  
over Contract Negotiation
20


Responding to Change  
over following a plan
21


Agile Approach is more...
• Visible
• Predictable
• Productive
!
• With a focus on
– High Quality Work
– Reduced Waste
22


Challenges for Embedded
• Stories and incremental scope control
• Breaking dependencies on hardware
• Applying outside of software
– Mechanics, hardware, ASIC development
!
• Not unique to embedded, though prevalent
– Your own preconceived notions
– Organizational resistance
23


Iterative and Incremental
Development
Projects end, products don’t (hopefully)
!
Requirements analysis is never done
Design is never done
!
24


Why Iterative?
• A system's users seldom know exactly what they
what and cannot articulate all they know
• … There are many details we can only discover
once we are well into implementation
• … as humans we can only master only so much
complexity
• … external forces lead to changes in
requirements…
[LARMEN]
25


“A complex system
designed from scratch
never works, and cannot
be made to work. You
have to start over,
beginning with a simple
system.”


A Complex system that
works is invariably found to
have evolved from a
simple system that worked

www.wingman-sw.com

Copyright © 2010

James W. Grenning


Project Progress is Measurable
Functionality Built and Tested
Requirements
Design
Code
Test
29
CompleteStories
Sprints or Iterations (2-4 weeks)
Learning


Measure Development Velocity
Estimated work per Iteration
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8
30


Measure Development Velocity
Estimated work per Iteration
31
0
5
10
15
20
25
30
35
40
45
50
1 2 3 4 5 6 7 8


Product Burn Down Chart
Work to be Completed
32
0
75
150
225
300
1 2 3 4 5 6 7 8 9 10


Product Burn Down Chart
Work to be Completed
33
0
75
150
225
300
1 2 3 4 5 6 7 8 9 10


Change Becomes Visible
34
0
75
150
225
300
1 2 3 4 5 6 7 8 9 10
New features
added--what
happens?


The Backlog is Made up of Stories
• The short term plan is more detailed.
• Work on it, buying time to refine longer term plan.
!
!
!
• Generally stories are in the order set by customer.
• Engineers can ask to move up stories to reduce risk.
• Stories are tested in the iteration they are implemented;
story tests are automated.
• A story is done when it passes its tests.
35


Introducing the User Story
• The name of a feature.
• A promise for a conversation. (Ron Jeffries)
• Like the name of a use case, or extension.
– Acceptance tests provide the details.
• Fine grains help make visible progress and avoid gold
plating.
• I call them Product Stories
36
Weekend Light
Schedule
Weekday Light
Schedule
Specific day Light
Schedule
Chinese Holiday
Light Schedule
US Holiday Light
Schedule
Everyday-but
Light Schedule
Everyday Light
Schedule


Stories and Acceptance Tests
• Stories lack detail
• Details are provided in automated acceptance tests
• The test are like executable use cases
• Test either pass or fail
37


Fine Grained Scope Control
with Product Stories
Come to my next session ESC 227 for Details
38


Technical Practices
39


High Quality - Visible Progress
• Concurrent requirements and design
• Automated test, continuously, at many levels
• Test Driven Development
• Continuous Refactoring
• Architectural Vision
• Evolutionary Design
• Continuous Integration
• Coding Standard
• Team code ownership
• Pair Programming
• Team workspace
40


Edsger Dijkstra
Those who want really reliable
software will discover that they
must find means of avoiding the
majority of bugs to start with, and
as a result, the programming
process will become cheaper. If you
want more effective programmers,
you will discover that they should
not waste their time debugging,
they should not introduce the bugs
to start with.
41


Can we Realize Dijkstra’s
Dream and
Prevent Defects with
Test Driven Development?


This Work Flow is Designed to
Produce Defects
43
Development
Test
Defects


Your program will have
bugs. And they will
surprise you when you
find them.

Intel, Hillsboro, OR
www.wingman-sw.com

All Rights Reserved. For use by training attendees.
Zune 30G
45
Decem
ber31,2008


BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)

www.wingman-sw.com

47
One That Got Away
static void SetYearAndDayOfYear(RtcTime* time)
{
int days = time->daysSince1980;
int year = STARTING_YEAR;
while (days > 365)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}
!
time->dayOfYear = days;
time->year = year;
}

www.wingman-sw.com

48
Your program will have
bugs. And they will
surprise you when you
find them.


This Test Could Have Prevented it
TEST(Rtc, check20081231)
{
days = daysSince1980(2008, 366);
CHECK(ConvertDays(days, &time));
assertDate(WED, 2008, 12, 31);
}
!


The Physics of Debug Later
Programming (DLP)
• As Td increases, Tfind increases dramatically
• Tfix is usually short, but can increase with Td
50
Bug discoveryMistake made
(bug injection)
Bug found Bug fixed
Td Tfind T fix
Time


A Bug’s Life
51
From http://www.softwaretestinghelp.com/bug-life-cycle/


• Write a test
• Watch it not build
• Make it build, but fail
• Make it pass
• Refactor (clean up any
mess)
• Repeat until done
T
D
D


Development and Test are a Continuum
preventing defects
53
Development
Test


The Physics of Test Driven
Development
• When Td approaches zero, Tfind approaches zero
• In many cases, bugs are not around long enough to be considered bugs.
• See: http://www.renaissancesoftware.net/blog/archives/16
54
Mistake
discovery
Mistake
made
Root cause
found
Mistake fixed
T d Tfind T fix
Time


Testing is not a Phase
• Testing starts on day one
• Tests provide the
specification of what is to
be developed
• QA/System Test moves
upstream.
55
HELP


The Two Values of Software


Rushing Slows You Down
57
Long term slow
down
O
Delayed
opposite
effect
Delayed
effect
O
Feature Velocity
increased defects
Poor code
quality
Rushing
O
O
Short term
improvement
Cause and
effect
Opposite
effect
Copyright (c) 2009 James Grenning
Inspired by Scaling Lean and Agile Development [SLAD]


Slow Down to Go Faster
58
Inspired by Scaling Lean and Agile Development [SLAD]
Feature Velocity
decreased defects
Code
quality
Refactoring
O
Automated tests
Short term slow
down
O
Long term
speed
O
Delayed
opposite
effect
Delayed
effect
O
Cause and
effect
Opposite
effect
Copyright (c) 2009 James Grenning


Unit Tests are Critical
59


Higher Level Tests Cannot be
Broadly Thorough
60
10
states
10
states
10
states
5 interactions
5 interactions
5 interactions
Tests
1000 (or more) tests are needed to testthis simple system


Unit Tests Can Be Thorough
61
10
states
10
states
10
states
5 interactions
5 interactions
5 interactions
Tests Tests
As few as 30 unit tests and 15
integration test when tested as units


Manual Test is Not Sustainable
62


Et = f(Ed)
Et is the effort to test a new feature, and is a function of the
effort to develop the feature.
!
Ed is the effort to develop a new feature
Assume a constant linear relationship
!
Et = f(Ed) = KEd
63

test

Assume Test Effort is Proportional to
Development Effort
64
Effort
Iterations
dev
5
10
15
20
25


• 25% of all defects are
introduced while changing
and fixing code 
[R.B Grady, Software Process Improvement]
65
If a system is working,
leave it alone. Don't
change anything
Systems don’t
appreciate being fiddled
and diddled with


Etn = f(Ed) + C Et(i)
!
Etn is the effort to fully test a product at iteration
N
!
Because any change can break previously working
software, we must retest.
!
Etn is a function of the effort to develop the feature
plus some fraction of the effort to test all previous
iterations.
!
!
66
i = 0
n
x

test

Manual Test is Unsustainable
67
Effort
Iterations
Unsustainable growth
dev
5
10
15
20
25

test

Risk Accumulates in the Untested
Code Gap
68
Effort
Iterations
Unsustainable growth
dev
5
10
15
20
25 Untested Code Gap


Final Thoughts
69


Challenges
• Legacy C code
• Automated testing
• Stories
• Culture
• Getting out of the cube and into the team
• Engineers get too specialized
70


Getting Started
• Honest self-assessment
• Motivation for change
• Open to different approaches
• Learn
• Experiment
• TDD under the radar
• Stories for individual work
• Management support
71


References and Resources
• [XP] Kent Beck, Extreme Programming Explained, 1999
• [REF] Martin Fowler. Refactoring. Improving the Design of Existing Code. 1999
• [WELC] Michael Feathers, Working Effectively with Legacy Code
• [TDD] Kent Beck, Test-Driven Development, 2003
• [XUNIT] Gerard Meszaros, xUnit Testing Patterns, 2008
• [PRAG] Andy Hunt, Dave Thomas, The Pragmatic Programmer
• [SLAD] Craig Larman and Bas Voode, Scaling Lean & Agile Development
• [POP] Mary Poppendieck and Tom Poppendieck, Implementing Lean Software
Development: From Concept to Cash, 2006
• [AGILE] Robert C. Martin, Agile Software Development: Principles, Patterns, and
Practices, 2002
• [CLEAN] Robert C. Martin, Clean Code, 2008
• [KANER] Cem Kaner, et. al. Lessons learned in Software Testing
• [TD] Lasse Koskela, Test Driven, 2007
72


On-line
!
• Test harnesses
– [CPPTEST] www.sourceforge.org, project CppUTest
– [FITNESSE] www.fitnesse.org
• Groups
• http://groups.yahoo.com/group/testdrivendevelopment
• http://groups.yahoo.com/group/AgileEmbedded
73


See Embedded TDD and Related Blogs
and Papers
http://www.renaissanceSoftware.net
http://www.renaissancesoftware.net/blog/
• Embedded TDD
• Zune Bug: Test Driven Bug Fix
• Learning Tests are Free!
• TDD as a Design Rot Prevention System
• Crashing Your Way to Great Legacy C Tests
• TDD and the Big Framework Part
• Bug Fixes and TDD
• Physics of Test Driven Development
• Tests vs. Short Term Cache Between Your Ears
• Embedded Systems Conference FAQ
• I miss constructors
• Who says you can’t test drive a device driver?
74
• Why are You Still Using C?
• Planing Poker
• Agile Embedded Software Development (ESC)
• Launching Extreme Programming at a Process
Intensive Company (IEEE)
• Test Driven Development for Embedded Software
• Progress Before Hardware
• Agile Times - Containing Progress Before Hardware
• Test-Driven Development for Embedded C++
Programmers


Talk to me on Twitter
http://twitter.com/jwgrenning!
!
Find my book at!
http://www.pragprog.com/titles/jgade
!
Find me on linkedin.com
http://www.linkedin.com/in/jwgrenning
Please remind me how we met.
!
http://www.renaissancesoftware.net
http:// www.jamesgrenning.com
Please come to my other sessions

Agile Embedded Software

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Agile Embedded Software (20)

Recently uploaded (20)

Agile Embedded Software