Rickard has spoken up to the concern that Gosling had on AOP:
Rickard Oberg
We have been using AOP (note the “P”) since July 2002, when we started building our CMS product SiteVision. Many on our team used to work on another similar product for another company before, and it’s interesting to look at some of the metrics. In half the time, with roughly half the code, we have twice as many features implemented as the other product. We’re 5 developers, but since we also do installation, training, support, and sales, I’d say we have had about 6 man years of effective development time. To go from scratch to top-five CMS’s in Sweden in such a short time, and with such a small number of developers, is a pretty decent thing to accomplish methinks.
Our typical time from idea-to-implementation is roughly between two days and one month, because typically we can reuse 30-80% of a new feature by using already built aspects (both advice and introductions).
We have, among many other things, implemented replication, client-side undo management, transactions, transparent partial object state versioning, security, locking, etc. as aspects, which we can reuse on any component or object model. Whenever we start on a new feature all such things are already there and “just works”.
I do know that we are probably an anomaly when it comes to using AOP, both in what we use (=homegrown) and how (=throughout product), but I still think it’s a good sign that AOP as such is not only viable, but can be a *key factor* in developing competitive software. I can safely say that *without it* our company would be dead by now.
Oh, and it’s both performant *and* maintainable. How ’bout that!
James Gosling
AOP is kind of a complicated one for me, because AOP is one of these things where the theory sounds really good. I actually mostly like the theory. The way it turns out in practice tends to be pretty dangerous. It’s fraught with all kinds of problems. You know when the AOP folks talk about AOP they list you like three or four use cases for AOP and they actually mostly make sense, although they have problems in the details. But there actually aren’t very many use cases outside of that. And when you find people who are using AOP, the average ones that I’ve talked to have been using it for things that are just like incredibly inappropriate. It’s like a really, really, really bad idea to be doing what they’re doing. And so I feel very conflicted because on the one hand I basically like the concept, but I don’t think that the research community has really figured out how to encapsulate those in a mechanism that really works for people. It’s like giving them a chainsaw without any safety instructions.
People have replied to Rickard saying “well. your opinion isn’t valid for the Real World, as you are smarter than the average bear”.
This has been said many times over the years hasn’t it. We could look at this point in a few ways:
- Yeah it is different and dangerous. Let’s never touch it, even though it can give us benefits
- I will use it cautiously. No need to jump on AOP for everything today, but I can incrementally use it (policy, testing, debuging, etc before going to production)
- It is very powerful. I see this as a GOOD thing. This will be my secret sauce, and will enable me to deliver faster than the cautious ones.
Rickard has gone with #3, and is able to do just that. Would a junior guy be able to jump into the codebase? Maybe so, maybe not. Who cares… his company is thriving.
NOTE: Just because AOP is being used, some junior guys wouldn’t have to be in those modular concerns, and their code would be SIMPLER because of it!
