Knowing Their Place

Following a link one day, I ran into a post on "Medieval Software Project Management," in which statistician John Cook likens the way many shops manage projects to the medieval practice of "beating the bounds:"

Software development hasn't reached the sophistication of geographic survey. Many software shops use a knowledge management system remarkably similar to beating the bounds. They hire a new developer to work on a new project. That developer will remain tied to that project for the rest of his or her career, like a serf tied to the land. The knowledge essential to maintaining that project resides only in the brain of its developer. There are no useful written records or reliable maps, just like medieval property boundaries.

Cook updates his post to include a link on how to avoid such a practice, and that writer correctly views the prospect of being "chained" to a project negatively. But it is worthwhile to consider how resistance to improving project management might arise. The answer comes from a much longer piece, which shows how sloppy project management can shelter laziness:

Such code can become a personal fiefdom, since the author [can] barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud. It becomes increasingly difficult for management to tell how long such repairs ought to take. Simple objectives turn into trench warfare. Everyone becomes resigned to a turgid pace. Some even come to prefer it, hiding in their cozy foxholes, and making their two line-per-day repairs.

The parallels between this situation and rent-seeking, which is worse, by virtue of arising from law, should be obvious.

-- CAV