Monday's message of the day on the XP mailing list:
>> Programming can't be successful without design. But I begin
>> my projects with very little design and seem never to do any.
>> On the contrary, I'm designing all the time. That's what
>> makes incremental delivery possible.
> To be able to do this is great!
> But I must say that I have been involved in too many projects
> where the developer just started coding and never looked back.
> The reason this works for you is probably two fold. (1)
> experience/intuition (2) you in fact do refactor.
> I would rather have someone spend a little time up front and
> think about design. Most certainly they will get a few things
> wrong and need to rework some areas, but it has been my
> experience that the vast majority of the population will
> benefit from a little pre-trip planning.
I'm all for thinking about design at all times, including up front. It is important to let the code participate in the design as soon as possible, because none of us is likely to see all the issues without that participation.
And if a team will not do the necessary things for success, whether those are up front design, refactoring, or both, they're not likely to have success. The things we all recommend work more or less well ... unless people won't do them at all!
Why not solve the problems (numbered above)? Is that not possible?
... which brought to mind a story I heard at the State Farm presentation yesterday, about the slowness with which programming proceeds in some large organizations. The problem: You don't know who will be changing your code later, so you have to document everything to the hilt... Why not just hire (or train) better programmers? Does the documentation really give you confidence that a sub-par programmer can do a satisfactory job?
The agile methods question traditional assumptions, looking for new leverage points in how we build systems. The idea of questioning assumptions is a powerful way to make progress in the world...
We've tried some agile practices on toy projects and seen how the cycle of test-code-refactor works. But we've only seen it for the simplest programs and for situations in which the tests are given or when the overall picture of the project can be understood as a unit. What do we do to implement a big project?
Recall this list of XP practices from Session 4:
I summarized the last four items on the list.
The planning game is an agile way to manage projects on a short time scale. We'll use it, but after we have a better picture of agile project management at a global scale.
Quick Exercise: Which of these practices do you think would be easiest to introduce into a development group? Hardest?
Some folks thought pair programming would be among the easiest, and other placed it with the hardest. One of the hard things is convincing management. From the programmer's viewpoint, it may be easy or hard, depending on the kind of people the programmers are.
Collective ownership was rated difficult. It involves both the programmer's ego and the surprise value of coming back to code that is in a different state from which you left it. Issues of format and style can be supported by tools...
Refactoring seems to take time, but remember: You have saved all the upfront design time that would have been allocated to the project. Be sure to use that time here. If you choose not to practice a discipline, it definitely can't work for you! And the XP practices support each other in sometimes unexpected ways.
Here is a summary of XP-style agile project management, based on your reading of Agile Project Management, XP Style, by Bill Wake:
The team consists of the customers and programmers (and managers) working together to release a working system. Releases occur frequently, from every few weeks to a couple of months.
The customer describes the system in terms of a set of stories, each of which describes a feature that the customer values. The programmer estimates the cost (in time and manpower) to implement each story. The customer selects the stories it values most to be implemented in the current release.
Each release cycle consists of a period of exploration, when customers create stories and programmers estimate them, followed by several iterations, each a fixed period in which the programmers implement stories. If the estimation was optimistic, the stories are dropped; the iteration is never lengthened. The team create a release plan to cover all of the stories to be implemented in the release and a set of iteration plans that group stories by iteration within the release.
Joel on Software says it this way: "A schedule is like wood blocks. If you have a bunch of wood blocks, and you can't fit them into a box, you have two choices: get a bigger box, or remove some blocks."
And from wiki's Planning Game page, we learn:
The customer writes stories. The prgrammer estimates the cost of the story, in increments of 1, 2, or 3 "points" or weeks. If a story requires more than 3 points, then the customer must split the story into smaller parts. The customer and the programmer work together to commit to a particular set of stories for the next release. Two common ways to "drive" the commitment phase are:
- story-driven: The customer puts stories into the release, and the programmer recomputes the release date. The customer stops when the set of stories constitutes a meaningful unit.
- date-driven: The customer sets a release date. The programmer computes the number of story points that can implemented in the time available. The customer selects stories whose cost adds up to the number of points available.
We'll practice this soon!
I'm your client, and not even a surrogate. I'd like to write a book on programming. This involves two elements: the content of the book and the presentation of the content. The presentation might take the form of a static web site, a wiki, or a format suitable for generating print (Latex, Framemaker, Word, ...).
This problem is a form of the content management problem:
This image is taken from CMS and the Single Web Designer, by James Ellis.
A large-scale content management system (CMS) would provide a lot of functionality. For example:
Most talk of content management systems (CMSs) on the web focus on presenting content on the web, but that's only one presentation domain. It also tends to focus on the content management in a large organization, say, a university trying to exhibit a consistent web image. These problems are where the money lies in content management systems.
For now, our project will concentrate on the needs of a single content developer. What are some of the problems? Consider me writing a book:
We will start off with one initial story:
I write one chapter (the equivalent of a lecture) with code references into a single directory, and have the system generate a single, static HTML page for viewing.
Even such a simple system would be of enormous value to me! But, of course, even such a simple story is a big programming task, including at least the reading of content from a file and the generation of an HTML file.
I will settle on a scripting language for my content by next time. The choices are a simple plain-text form and XML (or an XML-like language). There are advantages and disadvantages to both. At this point, I'm pretty sure that we will go XML-like, because it allows me to structure my content semantically, rather than using syntactic tricks.