Ship It! - 4.8 Selling Tracer Bullets

The primary benefits of TBD are:

• teams can work in parallel
• can see a working system earlier
• momentum, people like to make progress
• testing can begin just after the interfaces are defined
• easier to move people between layers because they have a basic understanding of what each layer is supposed to do

TBD Sequence:

• propose system objects (layers)
• propose interfaces
• connect interfaces
• add functions
• refactor, refine, repeat

Tip 24: You can't steer a boat unless it is moving

The main idea behind Tip 24 is that if your development progress is slow, you won't get timely feedback making it difficult to correct course.

How to Get Started:

• try it out
• discuss the concepts with the team first
• define system objects
• define interfaces between them
• write the interface stubs
• make the stubs talk with each other
• fill in the stubs with functional code

You Are Doing It Right If...

• the entire system is always up and running
• team members understand the system objects as well as "their" objects
• team members feel comfortable helping out wiht other system objects
• you can rewrite large portions of your code base and nothing breaks

I really like the idea of TBD.  I've operated in a similar manner on small projects just to see how stuff would "hang together" and enjoyed the process.  You run across stumbling blocks sooner and it feels good to have a working system that you can demo at a moments notice.  I'm curious to see how it functions on a larger scale.