Search This Blog

Tuesday, June 30, 2009

Expectations and Citizenship

Cockburn writes:
There is an interesting and relevant aside to mention about this group, having to do with expectations and citizenship. For reasons I won't go into, this team of business analysts thought they were supposed to work in the XP style and that XP prohibited them from writing things down.

Notice four things about their situation:

1. They misunderstood XP. It does not forbid people to write things down.
2. Their citizenship was so strong that rather than be poor citizens and write down their thoughts on the domain model, they chose to be good citizens and not write down their business model at all!
3. Actually, they knew that the project wouldn't succeed if they really wrote nothing down. So they each clandestinely wrote pseudo use cases and other notes, which they passed to the programmers. They still did not create a domain model for themselves.
4. By writing down those notes, they subverted their own (mistaken) interpretation of the official process. I find this situation particularly interesting, because they were at war with themselves about whether to be good citizens and follow the process (at the expense of the project) or to be good citizens and protect the project (by violating the process).

What was significant in the end was that they posted an information radiator on the corridor wall, on which they scribbled individually and as a group, to give their thoughts and decisions some stickiness.

I feel like I have been in this situation before. I want to do the right thing, but I don't know what the right thing is. I often wonder if I am shooting myself in the foot by trying to be too strict with my attempts to follow the XP recommendations. I guess it would be helpful to have an Agile coach to talk to.

Monday, June 29, 2009

Repairing Design Discussions

Cockburn writes:
On project "Winifred" (Cockburn 1998), the lead programmer announced at regular intervals that design was unnecessary and that code simply grew under his fingertips.

As a predictable result, the young programmers working in the room with him also felt it unnecessary to design. The code looked that way, too.

He eventually left and I took his place. To reverse the situation, I arranged for us to design by having conversations at the whiteboard. After some period of doing this, I started getting questions like, "Could you look at the responsibilities (or communication patterns) of these objects?"

By setting an audible tone in the room and making these design discussions legitimate and valued, the programmers started to converse about design together.

We struggle with these discussions on my team. I want to have these discussions, but I have a hard time getting everyone to participate. There are a few vocal members on my team that complain that our efforts to design as a group are unnecessary. I wonder if there are ways to work through this problem without losing team members.

Saturday, June 27, 2009

Program by example

Cockburn writes:
You can and should start taking advantage of people's strengths in copying and altering work samples. Create a small, online library of real samples for work products produced on your (or some previous) project. Other people can then simply copy one of the samples as the base for their own work. In copying it, they will pick up both the structure and style from the sample, while changing the details to fit their purpose.

The implication is, of course, that you would like the work samples you collect to be relatively "good," having structure and style you don't mind having copied. They don't have to be perfect, of course, just "good enough."

I cut and paste code all the time. I think I have a catalog in my head of all kinds of patterns of solving problems. I wonder if people would use a WIKI site with code examples instead of cut and pasting from the codebase?

This HAS To Be The Coolest Way To Play Music

link -> This HAS To Be The Coolest Way To Play Music

Debunking Canadian health care myths

link -> Debunking Canadian health care myths

Friday, June 26, 2009

Cockburn writes

Piattelli-Palmarini describes a number of experiments involving risks and rewards. The interesting thing is that even when the outcomes are mathematically identical, the results are different depending on how the situation is presented.

Illusions of Choice

Piattelli-Palmarini cites a dual experiment. In the first, people are given $300 and then have to choose between a guaranteed $100 more or a 50/50 chance at $200 more.

People prefer to take the guaranteed $100.

In the second, people are given $500 and then have to choose between having $100 taken away from them or a 50/50 chance of having $200 taken away from them.

People prefer to risk having $200 taken from them.

(Piattelli-Palmarini, p. 58)

Mathematically, all outcomes are equal. What is interesting is the difference in the outcomes depending on how the problem is stated.

Piattelli-Palmarini sums up the aspect relevant to project managers: We are risk-averse when we might gain.

and then later

This characteristic, "preferring to fail conservatively rather than to risk succeeding differently," gets coupled with people's fear of rejection and the difficulty they have in building new work habits. The three together explain (to me) why managers continue to use the long-abused one-pass waterfall development process. Based on this line of thinking, I expect that people will continue to use the waterfall process even in the presence of mounting evidence against it and increasing evidence supporting incremental and iterative development. Use of the waterfall process is anchored in a failure mode.

Our group has been trying to practice XP for over a year now. I like it, but I think it is going to be a long hard journey to get some people to try this.

Wednesday, June 24, 2009

Repositories And Abstract Classes

Ran into weird problem where my Aggregate Root was an abstract type with many concrete classes. Should I have one Repository for each concrete class or one Repository for the base class?

I couldn't find anything in the big blue book or online so I made something up. I have one Repository for the base class. Then each GetByXXX method is a generic method that takes the type of objects you expect to get returned. So you can get a list of the base classes or a concrete type or an interface that allows you to group concrete types together.

Them's Funky People

Cockburn writes:

There is some resistance in our industry to the idea that people factors dominate software development.

As I participated in initiatives for formal program specification, advanced programming environments, and new development processes, I kept discovering that successful teams were still delivering software without using our latest energy-saving ideas.

Initially, I viewed this as a nuisance: "Why can't those people just realize how much better off they would be if they used our ideas?!"

Eventually, it went from a nuisance to a curiosity.

Slowly, it became a discovery.

I reversed my assumptions and found that the opposite correlation held: Purely people factors predict project trajectories quite well, overriding choice of process or technology.

I found no interesting correlation in the projects that I studied among process, language, or tools and project success. I found successes and failures with all sorts of processes, languages, and tools.

A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology might help or hinder them along the way).

I need to remember this. Put the people above all else.