The implementation of Scheme we shall consider in chapter 5 does not share this defect. It will execute an iterative process in constant space, even if the iterative process is described by a recursive procedure. An implementation with this property is called tail-recursive.

With billiard ball sprints, the team finishes one sprint, isn't ready to start the next, and--whack!--the start of the next sprint is pushed into the future. The second sprint often starts in name, but the team is so unprepared to do the work of that sprint that it spends days learning about what is expected. The best way to avoid billiard ball sprints is to follow the boy scout motto: Be prepared. Expend a little effort in each sprint preparing for the following sprint. Ken Schwaber recommends allocating about 10% of a team's available time in any sprint toward preparing for the next sprint (2009). I've found this to generally be about the right amount as well. The team should, of course, adjust this amount up or down based on its experience.

The Law of Demeter for Functions The Law of Demeter for functions attempts to minimize coupling between modules in any given program. It tries to prevent you from reaching into an object to gain access to a third object's methods. By writing "shy" code that honors the Law of Demeter as much as possible, we can achieve our objective: While it sounds good in theory, does following the Law of Demeter really help to create more maintainable code? Studies have shown that classes in C++ with larger response sets are more prone to error than classes with smaller response sets (a response set is defined to be the number of functions directly invoked by methods of the class). Because following the Law of Demeter reduces the size of the response set in the calling class, it follows that classes designed in this way will also tend to have fewer errors (see [URL 56] for more papers and information on the Demeter project). Using The Law of Demeter will make your code more adaptable and robust, but at a cost: as a "general contractor," your module must delegate and manage any and all subcontractors directly, without involving clients of your module. In practice, this means that you will be writing a large number of wrapper methods that simply forward the request on to a delegate. These wrapper methods will impose both a runtime cost and a space overhead, which may be significant—even prohibitive—in some applications.