AOP Used to Isolate Change on Large-scale Financial System

A large-scale J2EE-conversion project of 50+ developers at a financial services company recently had a chance to use aspect oriented programming (AOP) as a mechanism to isolate change. Vincent Frisina, a consultant on the project was interviewed on TSS about his experiences on a large scale project. Part of the interview covered their use of AOP and also lessons learned applying Agile. The following is a summary of some of the key points:

AOP

With such a large team, no one person could keep the whole project in their head. They used inversion of control/dependency injection (home grown, not Spring) to minimize dependencies on external interfaces.   At one point however they found that they needed a change to the transaction handling semantics of their container. Rather than manually enforce workarounds in the code across the project, the team used AOP to isolate this change in one place and make it work across the project:

The way we handled this was, weave some aspects on the exit from the server that would inspect all return values which in this application were essentially status reports of what occurred, there maybe some messages indicating warning conditions, informational messages and errors, and one of the rules that we need was on an error, roll back the transaction.

Rather than having each developer responsible for adding this behavior, we wove it in as an aspect that made it look like a container service and this way the business logic developers didn’t need to care about what is really an infrastructure service. It was completely isolated from them. We could implement it in one place and not affect ongoing development for other people and simplify the code at the same time.

Vincent went on to say that performance was not impacted by the changed; "one common nicely optimized implementation was at least as good if not better than everybody’s spot fixes that they’d been putting in place and so we didn’t have to tradeoff performance, we just got quality."  Introducing AOP did not cause major debugging issues since change was well isolated into specific aspects whose developers used AJDT to debug. The rest of the project team could just focus on their own business logic.

This approach of using AOP on large scale systems has also be documented in Adrian Colyer's classic Large-scale AOSD for Middleware (pdf): The team that specifies policies can move from writing and disseminating policy documents, to implementing the policy itself. Individual developers (of which the product-line has hundreds) need not then read, internalize, and remember to faithfully apply every one of those policies. "

Agile

Vincent then went on to discuss his how the consulting firm he works for (ePlus) used Agile processes across their various clients, all whom have different internal working processes. Rather than try to force Agile on their clients, they:

set up interface points with these other organizations where the different delivery model within the Agile project where we have iterative development and more frequent releases to a customer can be mapped onto what sometimes is a waterfall process or something that’s more input driven where you get your requirements from analysis and then six months later, they are supposed to be a deliverable.

They would establish feedback loops wherever possible,  but in frequent case that a client could not make time to talk to the team, they appointed the most domain-aware development or testing staff from their customers teams to be 'shadow customers', providing necessary feedback on internal releases before making major releases to true end users.

Finally, Vincent commented on how to introduce Agile to old-school managers, saying that showing results with small pilot projects can help to let managers realize the value of the visibility and adaptibilty Agile brings.  Some agilists have been known to promote the idea that in worst case scenarios, dev teams should secretly use agile processes while assigning a team member to block upper management from finding out.  Vincent responds:

That’s a recipe for disaster because without--if development management expects they are working from one process and the developers are really secretly doing something else, what you end up with, is a shadow management created just to coordinate the Agile effort from the real management. So you have added overhead there and you lose all the benefits of visibility and adaptability because you’re essentially hiding the agility of the project from management. You have to win them over before you can really have a success with the project.