Summary
Jello has several very nice properties. It's cheap. It tastes good. It comes in cool colors. It's firm but not stiff. Systems need to be built like that. Firm, but not stiff. With clear boundaries.

I have been, more or less, uncomfortable at work since nearly my first day. We use an agile process and this means, among other things, there is a brief daily meeting where everyone presents what they did in the last 24 hours and what they plan to accomplish in the next 24. Frequently I've been simply dumbfounded by how much people actually do in 24 hours. Finished this, added that, fixed such and so. When my turn comes I find myself mumbling things like "trying to figure out how XYZ works", or "working on understanding where to put ABC". Every few days, more or less, I get to say "finished". It's difficult to describe how uncomfortable how dumb I sometimes feel in the face of the endless series of "finished"s, "done"s, "next"s that spout from the mouths of folks at pace that is, simply, incredible. So, uncomfortable. Until a couple of days ago.

I had to implement something in a part of the system that I've never ventured into (UI stuff, if you're curious). I was lucky enough to be able to convince this incredibly bright kid to pair with me and help guide me through the UI code. What this really means of course is that he drove and, mostly, I watched. At some point we needed something that was not available in the system in an immediate and obvious way. There was something that sort of did what we wanted, but not exactly. So, without a thought, he snarfed up the code, put it close to where we were and made it do what we wanted. Voila! Done! And I realized a couple of things. First, I now knew why I was slower in "completing" things than it seemed others were. Second, this is why XP doesn't scale.

It has been my contention for some time that XP doesn't scale well in terms of organization size. That is, XP works very, very well when the people working on the system have essentially total system knowledge. However there comes a point in the life of non-trivial systems where it is impossible for any one human to understand the system in the nuanced, detailed way that one must in order to not end up create a pile of spaghetti.

The code we copied and modified to do what we needed came from a major subsystem. What we did not do is consider what the impact to the system, and other developers, this semantic decentralization caused. In essence what we did was create a slightly varying way of doing something that was very specific to what we needed. So if you want to do X, you would look here. If you want to do X', look there. If you don't know that X or X' exists, you'll probably just create your own. The likelihood that you'll know these exists is probably proportional to how hard you have to work learn where it is. Knowing where something is, or where it should go, in a larger system is what I call the vocabulary of the system. I use this term in the Alexander sense.

This, in effect, is why I say "Done" in our daily meetings rather less frequently than others. When I need to add or modify something in the system my first order concern is not to get the damned thing functionally complete and move on. No, my first order concern is to not modify the vocabulary of the system without knowing I'm doing so. That is, I spend real time understanding where something should go, why it should go there, and what the impact on everyone else is. I think this is valuable and required. It allows one to reason about the system. If the ABC thing is responsible for, say, describing the structure of the persistent store, then when one needs to understand some aspect of the structure of the persistent store they look at ABC. If it's not there, it's not in the system and you add it. To ABC. Not to XYZ. This avoids something that I think is far, far worse than duplicated code, something XP says is very bad. It avoids duplicated ideas.

I think the folks who think about XP need to start thinking about how to address the issue of larger systems and their attendant organizations. How does one ensure that ideas are not duplicated in the system? I reject the idea, entirely, that when one finds these duplications you refactor them out with vigor. It sounds like a great idea, but it ignores the real world of deadlines, making money, and the expectations of business people. The fact is, and I can say this from real world experience, when you find these sorts of duplications you almost never have time to remove them entirely. Other commitments have been made, your time has been allocated in some other fashion, you have a set of user visible functionality that has been promised. And you must deliver in a bounded time frame. The number of times the business can tolerate you saying, "Right, found this duplication and I have to remove it. I need to add 20% to my estimate" is substantially smaller than the number of times you need to say it.

XP doesn't scale. Believe it. I'm living it and it's true. XP is, I think, the right substrate. It's got the ring of truth to it. But it needs something else. Something above it that talks about how to rationalize a change in the context of the longevity of the system. It has to talk about not just refactoring, but about how to avoid the need for refactoring. The XP guys should read Alexanders books. The idea of "vocabulary" in the macro rings as true to me as XP does in the micro.

For myself, I'm no longer uncomfortable at work. I realize that while I might not be saying "done" as often as others, I realize also that I'm not adding unseen or undetected, eventually certain, work to the system. Those who are responsible for figuring out if I'm doing good may, or may not, care about this. They may choose to place more importance on saying "done" alot than saying done and meaning it in a long term, years sort of way. I'm comfortable with that.

Talk Back!

Have an opinion? Readers have already posted 10 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Rick Kitts adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger