10. Risk 1:
Fixing bugs late is costly
Source: http://www.agitar.com/solutions/ why_unit_testing.html
11. So why is most
software built Requirements
this way?
Design
Implementation
Testing
12. Risk 2:
Lack of team cohesion
“Your changes to Bar are incompatible with
mine. How do we merge now?”
“When did we decided to upgrade to version
2.0-alpha of the Super library??”
“I thought you fixed that 2 months ago!”
13. Risk 3:
Poor quality code base
“We have 3 classes doing the same thing??”
“Everybody knows double checked locking is
a Bad Idea!”
“Why can’t I just include Foo and not require
all of the other 13 libs?”
14. Risk 4:
Lack of project visibility
“What do you mean the tests are failing?”
“What’s in version 1.2.3 of the build?”
“What’s our code coverage now?
15. Risk 5:
Lack of deployable software
“It works on my machine!”
“I need a new build to test with”
“The [boss|customer|patron] is coming,
we need to demo progress asap”
46. print
me!
1. Commit Early, Commit Often
2. Never Commit Broken Code
3. Fix build failures immediately
4. Fail Fast
5. Act on metrics
6. Build in every target environment
7. Create artifacts from every build