Chapter 14: Scalability

Overview

Big Projects Got No Reason to Live

(Sing to the tune of Short People by Randy Newman)

Big projects got no reason
Big projects got no reason
Big projects got no reason to live
If you got too many coders
To fit in a room
You know that your project
Is destined to doom
So we don t want no big projects round here

Big projects got no reason
Big projects got no reason
Big projects got no reason to live
When you smell the code
You know you got to inhale
We like small projects
Cause XP don t scale
So we don t want no big projects round here

It is difficult to build extensive tacit knowledge without good osmotic communication, and that is hard to do with more people than conveniently fit in a room. ^[1]

Code is definitely worse than we started. ^[2]

Metaphors are unrealistic with large projects. They are just too complex. Period. ^[3]

In this chapter, we analyze the difficulties faced by XP teams when dealing with scalability. For the purposes of our discussion, there are two types of scalability:

• The ability of the product being delivered to scale architecturally

• The ability of the development process to handle larger projects. Larger projects could be

• Larger in team size

• Larger in terms of the amount of functionality being delivered

Most of this chapter is concerned with the second type: process scalability. (Although we will also discuss some ramifications that emergent design may have on architectural scalability.)

But before we look at either of these scalability types, let s examine some important available research.

^[1] Alistair Cockburn, Agile Software Development (New York, NY: Addison-Wesley, 2001), p. 169.

^[2] Amr Elssamadisy, XP On A Large Project ”A Developer s View, http://www.xpuniverse.com/2001/ pdfs /EP202.pdf, paper presented at the 2001 XP Universe conference.

^[3] Ibid. We analyze the paper containing this quote and the last in the Painting Over the Cracks section in this chapter.