Figure 1: The blind men and the elephant

Quite a few of us are familiar with the ancient story of the blind men and the elephant. Each man visualized the elephant based on his own perspective, and none of them had any idea what the entire elephant looked like. As a child, this was narrated to me as a cautionary tale –- don’t make decisions without knowing all the facts.

In modern times, the approach of looking at complex problems by focusing on one particular aspect of the problem has become valued as a thinking tool. Sometimes, a problem may be too difficult to understand or its scope may be too large to grasp unless one looks at a little piece at a time. In this article, I look at some of the ways in which we can use this technique to become better problem solvers.

One of the problems I face when working on new projects is that I walk in the door and am confronted with a mountain of code to understand and work with. When I was less experienced, I used to apply a brute force method — walk through the code with the help of a debugger, and test out all the functionality of the application until I understood exactly what each module, class and method did. However, this approach requires time, and that is not always a luxury one has. One is usually expected to jump right in and be productive.

What light through yonder window shines?

One of the tools that I’ve found to be helpful in assisting me with code comprehension is Juliet (see the Resources section for more information). Juliet is not merely a code browser. Given a codebase, Juliet parses the code to discover relationships that may not immediately be obvious. For example, I’ve sometimes provided Juliet with supplementary code, such as the JDK, or weblogic.jar in order to discover how application code relates to the deployment platform.

Figure 2: Juliet in action

When Juliet analyzes the code, it does so by focusing on a particular perspective of the code that I am interested in. Juliet is even considerate enough to let me hide comments and collapse methods down to their signatures. As you can tell, this is a huge improvement over the brute force method described earlier. For example, if I want to know exactly what code fragment A does, and how it relates to code fragment B, Juliet helps me figure it out. All tokens (variables, methods, classes, etc.) are hyperlinked so that I can instantly browse to the artifact of choice. Figure 2 is a screenshot of Juliet. (Who says you can’t design great user interfaces using AWT?) This perspective-based approach lets me focus on what’s important and neglect other code that may be unnecessary for my analysis.

Everything under the Sun is in tune

The idea that a codebase can be examined using a set of “perspectives” is familiar to anyone who has used Eclipse for development. The designers of Eclipse understand that as a developer, I don’t want to see my entire codebase all at once. I might perform many different actions with the same code. For example, I might want to interact with the codebase using a ‘work-with-scm-codebase’ mentality. If so, I can easily switch Eclipse to CVS perspective, and perform all my actions that are relevant to the SCM tool. Or, I might want to set up datasources for my J2EE application and run some test queries against a database. To do this, I can switch to a Database view. This focuses my efforts. I don’t have to sort through different menus trying to find the functionality I want (Is it under Tools? Edit?). I know that when I switch perspectives, I am working with a particular mindset, and all the actions I perform on the code will be relevant to that mindset.

One word, my boy: aspects!

This approach has been applied to software development in the form of aspect-oriented programming (AOP). AOP is a concept that is complementary to OOP. AOP gives us a way to deal with concerns (AOP calls these crosscutting concerns) that affect multiple objects all at the same time. Common examples include transactions, security and logging. You need to handle transactions in multiple objects and in multiple methods across your code. The same goes for logging. However, transactions and logging have nothing to do with the core business logic that you are using objects (and OOP) for. They are complementary concerns. AOP lets you deal with these concerns by viewing them as ‘aspects’ of your code. Doing this helps you focus on problems that span objects without getting sidetracked by the object-orientedness of your code.
If aspects are such a useful way to look at code, does it make sense to apply this way of thinking to everyday problems? In other words, can we train ourselves to think in aspects, and therefore become more effective thinkers? This would allow us to migrate this idea out of the realm of programming into the real world, allowing us to address problems that don’t traditionally require code to solve.

Six hats to rule them all

As it turns out, this is not such a far-fetched idea. In his book, Six Thinking Hats, Edward de Bono argues that we can train ourselves to think exactly like this. He contends that doing so can make us better thinkers and allow us to solve problems faster. This approach has been tested in real world situations, and in many instances has made it easier for groups of people to make decisions. It has also facilitated better communication among group members. Mr. de Bono encourages readers of his book to visualize different modes of thinking as hats of different colors. Then, when confronted with a problem, the thinker can mentally put on a relevant hat and invoke the method of thinking associated with that hat. This practice helps avoid the chaos that is caused when one tries to look at a problem in many different ways all at once.

As we’ve seen, the concept of crosscutting concerns can be adopted as a problem-solving tool in many different ways. At a fundamental level, it encourages a way of thinking about the world in terms of a particular perspective, so that common aspects of complex problems can be addressed. As developers, aspect-oriented programming can enhance our thinking and give us another way to model systems (complementing OOP and design patterns). With this in mind, I would encourage you to seek out and understand frameworks such as AspectJ, AspectWerkz and Spring-AOP that provide support for AOP. I also encourage you to read Six Thinking Hats to understand how you can apply aspect-oriented thinking to your own life.

Resources

• Juliet can be downloaded from http://www.infotectonica.com/
• Learn more about perspectives in the Eclipse platform at:
  http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html
• Learn about AspectJ at: http://www.eclipse.org/aspectj/
• AspectWerkz can be found at: http://aspectwerkz.codehaus.org/
• Spring AOP is discussed in the Spring documentation at: http://www.springframework.org/docs/reference/aop.html
• I want my AOP! is a series of JavaWorld articles on AOP using AspectJ:
• www.javaworld.com/javaworld/ jw-01-2002/jw-0118-aspect.html
• O’Reilly’s OnJava site has an introduction to Spring-AOP: http://www.onjava.com/pub/a/onjava/2004/07/14/springaop.html
• You can read the first chapter of Six Thinking Hats here:
  http://www.twbookmark.com/books/62/0316177911/chapter_excerpt9537.html

Entertainment
Some amusement might be found by deciphering the cultural references alluded to in the section headings of this article.