Prototypes are forever:
Evolving from a prototype
project to a full-featured
system
Alexandre Freire
Fernando Freire
Hugo Corbucci
Mariana Bravo

Introduction
Why should we throw our prototypes
away?

Introduction
Why is technical debt considered
harmful?

Context
+ 4 developers
80 pair hours per iteration
=
3 months prototype RCP project

Context
and
+
on m4 developers
ti e
o
ra 80 pair hours per iteration
o ad
pl or
ex y f
l: er
=
a v
o o
G c
dis
3 months prototype RCP project

Iteration 1 - 25 commits - Jun/2008

Practices
No full test coverage → Only crucial tests

Practices
Invest in Continuous Deployment (hourly builds)

Practices
“Buggy” software for well-behaved users
Client priorization:
● No corner-cases
● No validation
● No verification
● No exception handling
● Lots of new features

Iteration 4 - 211 commits - Oct/2008

Ready for demo?

Ready for demo?
No!

Ready for demo?
Needs text editor

Ready for demo?
Needs text editor
Deadline: Dec/2008
Complete focus on the editor

Iteration 6 - 352 commits - Dec/2008

Changing the rules
Demo cancelled!

Changing the rules
Demo cancelled!
● Less pressure → Fight against technical debt
● January 2009: a whole iteration dedicated to
refactoring

Changing the rules
● 6 months evolving editor features
● A complex editor means other less new
features
...
● Still no demo

Iteration 12 - 937 commits -
Jun/2009

This is no longer a prototype
Dedicated study group
of dramaturgy experts
● More ideas for new features
● Investment in UX

This is no longer a prototype
Outsourcing editor so team can focus
on new features

Tracking Technical Debt

Tracking Technical Debt

Difficulties
GUI testing
Loss of a team member

Difficulties
Prioritizing integration VS new features
● Integration with outsource team
● No steady rhythm

New direction
“I've invested too much!
This software is mine.”

New direction
“I've invented something new.”

New direction
Focus on quality
Aim for complete, bug-free features

Iteration 23 - 2005 commits - now

Conclusion
No need to throw away prototypes:
just write tests for crucial elements
and refactor mercilessly

Conclusion
Technical debt is acceptable if kept under control
and software delivers value for client

Conclusion
Throw away if all you wanted was to gain
knowledge

Questions?
contact@agilbits.com.br