Tuesday, September 26, 2006
Quadrants
A few days ago, I was consulting on a troubled project. Progress is slow; we don't have enough people. Senior developers are in Italy, but they're too concerned with other projects to help on this one. We have [mostly] junior resources in India. There is an overall optimistic plan, but reality is not going according to the plan :-).
The only viable path right now is to grow the team in India, adding senior and junior developers. However, this won't help unless we radically change the plan. We need a complete reordering of activities. Here is the most useful quadrant for this project:
Each task is a point inside one of the quadrants.
On one axis, we have the dominant complexity of the task. Some tasks are dominated by the business complexity. Some by technology complexity.
On the other axis, we classify the dominant force as stable or unstable. Someone may complain that there is no such a thing as a stable task, but that's simply not true. We may have instability at some granularity level, but we always have several stable decisions. Stability may be on the technology side (when the dominant complexity is technology) or on the business side.
Now, why does this help with re-planning? Because the original plan was built around senior developers, with significant exposure to this particular business and several (up to 20) years of programming experience. So, the original plan tackled several unstable problems from the very beginning, as part of an exploratory phase + risk identification strategy.
This is very different now. [Mostly] junior programmers, with limited exposure to the business, structured in a delocalized team can't follow the same plan. Note that it's not a problem with the new team: it's a problem with the old plan!. Anyway, we need to gain momentum on this project, and that means immediate, useful progress.
Now, the simplest tasks for any programmer are the technology-centric. It's much easier to explain a technological problem than a business problem, especially to someone with no experience in that particular line of business. Working with stable technologies may not be so fun, but will give back results quickly. So, we need to identify "quadrant 1" tasks and start from there.
We can't ignore the other quadrants, of course. We have a few resources in India knowledgeable about the business. They'll soon have to take more responsibilities. We need some investments so that they can help with quadrant 3 (starting at the edge between 1 and 3).
Time can help with quadrant 2: the involved technologies will naturally translate from 2 to 1 (or die) in the next few months, so I don't really feel any pressure to deal with them (actually, I feel some pressure not wasting time dealing with them right now).
Quadrant 4 must be handled locally. There is only one guy who can make key decisions about the best way to model some business concepts. We have to make sure that he can actually spend some time on that. Which is another problem, not well suited for quadrants (but just fine for effect diagrams :-).
As an aside, this may (and in fact did :-)) not look agile to someone (as by staying away from quadrant 2 for a while I'm not "embracing change", and I'm also trying to have [gosh!] a detailed plan, and so on). I guess it depends on your definition of agility. In my book, doing whatever is necessary, useful and possible with the resources you can find beats following a recipe (not a plan :-), any time. I'm pretty sure true agile guys would somehow agree with me at this level. Then, we may use different approaches and tactics. I think agility is not in the practices. It's in why you do what you do. Following recipes (that includes TDD, Pair Programming, and whatever else if not carefully considered in context) just doesn't look agile (or plain old sensible ;-) to me.
In this sense, I would even say that I have embraced the biggest change: from a tight team of experts in Italy to a delocalized team that has never worked on similar projects. My plan is entirely based on the new environmental conditions. That's the most important choice at this point in time; but a good plan is dynamic, and we'll steer as the environment changes...
Sunday, September 10, 2006
Some notes on AOP
More recently, authors have tried to define similar properties for Aspect-Oriented languages. An interesting work is "Aspect-Oriented Programming Is Quantification and Obliviousness", from Robert Filman and Daniel Friedman (published in "Aspect-Oriented Software Development", Addison Wesley, 2005, but probably available on the net as well). I do not agree on all their conclusions (like "AOP is not for singletons", which is somewhat confusing separation of concerns with separation of crosscutting, pervasive concerns), but the idea of Quantification and Obliviousness as the cornerstones of AOP are quite well-grounded.
The authors discuss different type of Quantification (static and dynamic) but do not dissect Obliviousness any further. I think we have two types of obliviousness as well: caller and callee. This is also somewhat reflected in AOP languages (for instance, in AspectJ we have both call and execution pointcut expressions) and emerges in library-based attempts to bring AOP to traditional OO languages (with explicit factories preventing caller obliviousness).
[As an aside, the paper mentions rule-based systems; I've already said a little, and I would have more to say, about the great inheritance of artificial intelligence in OOP and AOP, but hey, it's getting late :-)].
Obliviousness can be quite limiting if applied to both the caller and the callee. In many cases, good separation of concerns can be obtained by callee obliviousness alone. That means we can also live with library-based AOP in many (but not all) cases. More on this another time; meanwhile, another interesting paper is "Spectators and assistants: Enabling modular aspect-oriented reasoning" by C. Clifton and G. Leavens, Technical Report 02-10, Iowa State University, October 2002. In a sense, only spectators can be considered as totally oblivious aspects (for both caller and callee). Interestingly enough, the strong focus on spectators-like aspects in many introductory papers is giving many the false impression that AOP is only useful for logging. Many papers are also focused on container-like facilities (security, sinchronization, remoting), and we should definitely move beyond that too...
