Posts Tagged ‘interview’

Interview: Dr Jeff Sutherland, father of Scrum

February 2, 2008

Jeff Sutherland has piercing blue eyes – friendly, but probing – and a frequent smile. They are a bit like a distant uncle who wants to know what you have made of yourself.

After several CTO assignments at various companies, Jeff Sutherland found himself at Easel corporation where he created Scrum together with Ken Schwaber. Ken later presented this methodology at the OOPSLA conference in 1995.

A dozen years later I find myself in search for a good spot where I can concentrate on my interview. Jeff and I sit down at a café at the Øredev conference. My computer has been acting up going blue screen on me twice that day. Time is short and I wonder if it’s an omen.

Photo of Dr Jeff Sutherland.

Photo of Dr Jeff Sutherland.

Dr Jeff Sutherland. Photo by Mai Skou Nielsen, Trifork

Q: I hope I’ve done my reading. As far as I understand you’ve been a fighter pilot in Vietnam, an assistant professor in math and medicine and the CTO at nine different high tech companies. Moreover, you travel the world to teach Scrum. Does it take a resumé like this to invent a process like Scrum?

The key part of what makes Scrum work is “complex adaptive systems” and you need some understanding of this. Also you need to understand systems theory and how to optimise a system as a whole.

You do not have to be smart, but you have to thoughtful.

Q: How did Scrum start and from where does it draw its heritage?
Scrum and Lean both derive from complex adaptive system theory. Constraint theory is a narrow subset of complex adaptive systems thinking. Lean implementations of these theories have been created at companies like Toyota and Honda. Honda was actually more aggressive at this in the nineties, but then Toyota was more successful in the market. They also were more formalised and better known.

Q: Why does it work?
The first reason for all of this is important – super intelligent performance out of ordinary developers. In order to do that we need we need to set up a simple framework so that people will self-organize. The second reason is that there is no central point of control. The manager needs to back off. That is critical.

The third principle is behaviour that emerges in the team based on self-organizing in order to get max production.

The fourth reason is that the production is far higher for the group than any single developer. Groups actually achieve more than any lone bright developer.

These are the basic principles of a complex adaptive system. Any organization is a complex adaptive system. Software production is an organizational phenomenon. It is an empirical process that must absorb significant change in requirements, technologies, priorities, and people.

Q: You talk about managers, why is it important for them to back off?
A company needs to stop sub-optimizing locally. That is the thing that Toyota figured out, largely due to the efforts of Edward Deming and other Americans who trained the Japanese in WWII industry processes. Most managers just care about local performance. Managers have to work as a team to look across the whole spectrum. It is difficult for them. They’re paid and given bonuses on a single level, not the company as a whole.

For instance, look at the General Motors manufacturing plant in Fremont, California. GM shut down that plant 1982 due to several problems, among them quality. Two years later it reopened as a joint venture between Toyota and GM. Toyota needed a plant in the US in order to avoid import restrictions. In an agreement with the labour union they offered reemployment to the former employees.

Two years later the NUMMI plant was producing over 200 000 cars per year and was twice as productive as the typical GM plant. The thinking they applied is the same as “lean production” where Toyota makes the team responsible to figure out the best way to solve the problems and achieve the goals. NUMMI later won several awards for quality.

“Your battery is running low”, declares my machine solemnly. Jeff and I make a run for a power outlet and find one on the second floor. My power chord is too short so we stack up real close to the wall. It will do. More than that actually, it feels like we really are working together on this interview.

Q: Some parts of Scrum are frightening, like making the group totally responsible for an implementation. How come people in management buy this?

The best answer I can give you, is the discussion I had with my first CEO when I introduced the ideas of Scrum. We had a critical project with a hard deadline. It was a question of survival.

The CEO expected a Gantt chart [ed: a timeline specifying activities and their dependencies, showing the progress of a project].

  • How many Gantt charts have you received that actually worked? I asked the CEO.
  • None, was the short answer. In my 25 years I haven’t received a single one that was correct. I asked him if a 100% failure rate wouldn’t make it foolish of me to give him one.
  • What are you going to give me, he asked?
  • Working software. Decide for your self to if we’re on track. In return I made him promise not to disrupt the team before the deadline. At this point he started to worry.

I said that at the end of the month he could change everything he wanted, but not during that month.

  • If you do this, you will get significant more code with better quality.
  • I can live with that. Let’s do it.

Scrum was born in that minute.

It’s a basic contract between management and team. The team delivers twice as much stuff with twice as good quality (minimum) and the management supports the team in their efforts to self-organize and self-manage. If either party does not fulfil this contract then it will fail.

Q: Doesn’t Scrum fail?

Scrum itself is a set of rules that causes self-organization if certain things are put in place. It’s like the rules of soccer. Does soccer fail?
With Scrum you will fail significantly less.

The Standish Group \[ed: a company that specializes in IT studies\] reports that project in the range 3-6 million dollars with a traditional project plan fail more than 85% of the time. Scrum does a lot better than that!

Q: What are your top three tips on using Scrum?

Bas Vodde was the Lead trainer for Scum Master at Nokia Siemens Networks. He has the shortest set of questions to identify a dysfunctional Scrum team.

You must have iterations of 30 days or less with working software tested at system level at end of each iteration. You need an agile specification, just enough for programmers to start for that iteration.

You need a product owner who orders activities by business value of the feature set. The team estimates the product backlog.

And lastly, the team needs to monitor progress with a burn down chart and know its velocity at the end of the iteration.

Q: Finally, what is in the future for Scrum?

Hyper productivity on an economic and marketing level where companies consistently out perform their competitors. Scrum is a disruptive technology that will alter markets. Companies doing Scrum well will grow rapidly in both size and profitability and dominate their waterfall competitors. There is already a brain drain going on where the better developers are fleeing from waterfall companies to Agile companies. This will hasten the demise of traditional projects.

Q: Is this a shameless plug?
Oh no, we have achieved it in several departments at my company \[PatientKeeper\]. It is doable. Other companies I work with right here in Scandinavia are doing it as well.

Going away from this fast paced interview, I still have the feeling that I could have done more with my life. If Jeff can do it, then so can I …I hope

Originally published in JayView.

Interview: Martin Fowler – man in the know

February 2, 2007

I am in search of an empty room at the Øredev conference. Normally this is an easy task, but I’ve got Martin Fowler on my tail. My mind is still blank. What on earth can I ask him that he hasn’t already written himself?

Finally, an empty room, well almost. Another speaker, Erik Dörnenburg, is sitting half way into his screen and mutters.
– What’s up, I ask.
– I’ve updated my machine and my demo doesn’t work. I’ve got 45 minutes until the presentation.
We sat down next to him. Do not disturb a developer while he’s coding…

So I got a man who has coined phrases like Dependency Injection and POJO in front of me. What next? Martin is easily recognizable both in accent and appearance, a frequent and brilliant speaker.
He has an excellent web site, http://www.martinfowler.com, which contains loads about his work. Articles and references abound. That is when it suddenly hits me – who is he as a programmer and person?

Q: When was the last time you coded?
Well, I do code my own website. But it’s been a while since I had any paying customers. I’ve been pairing quite recently though. A real delivery? That was some time ago. I’m actually afraid to lose contact with code, but I have smart people around me.

Q: But what makes you tick?
I enjoy trying to figure out new techniques – to organize knowledge. I see myself as a conduit [ledning] for transferring knowledge, to process what is out there and make some kind of structure out of it. Brian Foot actually described me as an “intellectual jackal with a good taste in carrion” [intellektuell schackal med god smak för kadaver].
I look around for interesting stuff and try to make sense of it.
The “Refactoring” is a good example. I figured out how to describe it and wrote a book that came out when it could make a difference and move the area forward.
I also enjoy writing a lot, that’s a big thing. I’m better now at speaking, but that’s not what makes me tick.

Q: You’ve written quite a few books – how do they compare?
Out of the five, “Uml Distilled” sold more copies than the others put together. Usually you can’t make a living out of your books, I guess I could though.
All of the books had their good sides, but I would have to say that it was fun to write with Kent Beck [red: wrote “Extreme Programming”, created JUnit etc]. We were in tune and could support each other through the dull bits.
I would have to say though that I’m proudest of “Refactoring”. It’s an important technique and didn’t get the attention it should have received – the book helped.

Q: How did you start out?
I was an independent consultant for many years. Giving talks was a good way of getting jobs. Articles same thing – it got my name known.
Also, I write something because I don’t understand a certain area or technology. It’s a good way to learn.
Erik is now on the phone with California. We calculate that time is roughly 6:30 there – in the morning.

Q: Then what? How come you started working for Thoughtworks (TW)?
I’ve been there for six years and done a lot of consulting. I never wanted to work for a company, but there was something about TW that made me interested.
Get the work done and tons of bright people. But more importantly is that it is a sort of social experiment. A notion that good people makes a difference.
I hope we can affect IT, which is a difficult and skilled exercise at best.

Q: What is the most difficult part of being a celebrity?
I’m not an extrovert person. I’m not good at the “person to person”. I get emails with questions like “I got a problem on…what is the magic trick”. They worked for months on it and I can only point to a book. That clearly wasn’t an answer they liked. It’s frustrating.
However, celebrity is also a nice thing – it opens a few doors. I can email people like Rod Johnson [red CEO of Interface 21 that created the Spring framework] if I have a question about something. And he will answer.
People tend to think I’m an ingenious programmer. I’m not. I’m pretty good, but not necessarily that great.
Erik suddenly spits out:
– F—!…ok the demo will be shorter.

Q: Looking forward, what’s next?
Oh, there is tons of stuff to write about. The design patterns area for instance. I’m also interested in DSL [domain specific languages] and agile development. But in agile there are too many writers and I don’t like competition. There are too many smart people in agile development.
My strategy is to look for topics that no one has written about. Basically I don’t foretell the future.

Q: What are your top three pieces of advice to a programmer?
My first advice must be to learn to collaborate with the user or purchaser. The really good ideas usually come from them. You don’t have to be an expert to do this. This I found to be a good general advice.
Secondly, it would be “continuous learning”. It’s like running up a downwards-moving escalator – you have to keep running.
The third one is difficult…
“Buy lots of books by good authors” would be it.
Erik suddenly releases a big:
– Yes!
I saw Erik’s demo some twenty minutes later – it was really good.
As for Martin, our discussions continued well into the debate panel and beyond. He would frequently forget his back pain and sip into some extra energy pack. I wonder how he did that.

Originally published in JayView.

The scent of freshly cut code

March 4, 2006

I just had to be there. My friend was starting out anew. A fresh idea, a start up – I was hoping it was going to be good. I was not disappointed.

I could smell it straight away when I en- tered the small office – the fresh and raw scent of newly cut code. Two men sat in front of their computers. One of them smiled at me.
Jon Hauksson and I had hacked code, back to back, against a fast moving dead- line in a distant project. He had given up his daytime job as a consultant at a respectable firm. Now, he was shoulder deep into his new venture, bringing au- dio books to the mass market of mobile phones.

Jon and Andreas in a classical image – happy men with computers.

What had he learned? What is it like to develop a business to consumer app running on all those different Java mo- biles? A lunch later we were heading back into his office at Ideon – an incu- bator for new companies. Mobiles were strewn across their tables. Blank walls. Shelves were more or less empty. It all breathed start up and focus – get that app out trough the door!
We sat down and Jon pulled an SQL- statement to calculate the last 24 hours of commerce.
– Yeah, rising, he said and smiled.

It has been said that developing a Java ME solution for all those different mo- biles is difficult and time consuming. Is it that hard?
Yes… but it has improved, especially for Nokia and Sony Ericsson. But some other brands can be trickier. We usually code for the Sony Ericsson emulator and then bring the code over to the Nokia one. Usually there aren’t any problems here. From here on we test the other brands. If we hit a problem we either try to solve it or we have to program our way around it. It used to be more difficult. The situation has improved in the last year. Especially Sony Ericsson is working hard to make it better.

Does this mean you have different sets of your code?
We have four variants of the result- ing jar/jad file and that is enough for us. Fortunately NetBeans has pre-process- ing that makes life easier and allows us to only work with one code base.

Without any time to think, what are the top three hard to learn lessons that you can you share with us?
1) Testing, testing, testing is extremely important. Many unforeseen things can happen in areas like operator handling, memory management, the mobile network and different quality issues – a lot can happen and usually does.

Bokilur’s application playing a book.

2) The Java settings are often not in- stalled correctly on the terminal from start. The user can download the set- tings for Java from the operator but sometimes these settings are not cor- rect. We’ve tried to add a guide that pops up when this happens but fiddling at this low level is not a pleasant experience for the customer. Some call our support number and we try to help them, but it is still a problem.
3) Streaming solution
The network, GPRS or 3G, has gaps and this affects our application. We’ve had to develop a streaming solution with a five-minute buffer so that you can listen to our books while driving. We’ve even tried it on trains, on the X2000 for instance, which reportedly has its share of problems when it comes to mobile network connections. But to our relief it worked there as well.

Would you do use Java again?
For sure, it is easy to work with and even though it has problems, it is getting better.
Although, we’ve chosen to imple- ment a number of our own frameworks even though there might be a good open source solution available. It is im- portant to us to keep our code size to a minimum and we usually don’t want the whole nine yards.

Any examples of when you’ve had to roll your own solution?
Well, we implemented a GUI frame- work a bit like J2ME Polish. This way we can target our application’s needs and keep control. We’ve also developed an RMI like protocol to interact with the servers. There are, however, a lot of open source solutions to try out.
We also have a simple debug solu- tion where the phone sends back debug information to the server so it can be logged. Very handy. And of course simple stuff like text han- dling.

Would you do anything differently now when you look back? How long has it been anyway?
One and a half year. Ha-ha, it feels a lot more! We are trying to improve the user friendliness of the entire browsing and purchasing process in the applica- tion. That’s user interaction, but I can’t think of anything technical. Keeping the program easy and intuitive is important to us.

Any practical hints on starting a prod- uct company in the mobile space?
Get the operators as partners. For a data rich service like ours, you need to get a deal without traffic charges. Other- wise it will be hard to develop a pricing model that is attractive to your targeted customers. Besides, the operators have a strong interest to bring in attractive services into their portals. They need more than just games and ring tones.
Oh, and one more thing, keep track of the top selling mobile phone list. That way you know which models to target during testing.

What about the future?
Our business idea is to be the best mobile literary service both here and abroad. You can expect us to go after the Nordic countries.

Has the “market” for new companies changed?
Yes. During the last year more of my former colleagues have started compa- nies of their own! It’s even come to the point where venture capital has a prob- lem finding something to invest in…

During our interview Bokilur’s other programmer, Andreas Melvanius, kicks in.
– We have a problem.
It turns out that a single Nokia phone is thrown into silence. A quick round of questions and they agree on some new tests.
After a while Jon asks whether I’d like a tour of the ”pavilion”. Walking in the corridors, we find a new com- pany behind every door. I cannot help but being impressed, such diversity. We stumble upon solutions for detecting schizophrenia, simulation of combus- tion engines, cameras that can see in fog and darkness and so on. I leave the barracks feeling elated – I too want to start up my own company.

PS. Curious about the Bokilur applica- tion? Check out http://www.bokilur.se.
PPS. Bokilur later changed their name to StoryTel.com
Originally published in JayView.

Bert Rubaszkin, the quote master

March 3, 2006

Bert R working on his sauna raft.

Bert Rubaszkin is the Chief Technologist, CTO to us mere programmers, for Sun Sweden. He is often quoted in such computer mags as Computer Sweden. Questions cover a lot of ground, from Sun servers being tossed from tall buildings to the future of some new Sun technology.

Bert comes across as the wise ol’ programmer who has seen most of what there is to see. Always in a good mood, I find it hard to see him loosing his cool despite being probed with difficult questions. But first, let’s start off with a simple question.

What’s it like being asked to comment on just about everything under the Sun?
There are two problems. If you have worked long enough, people expect you to be an expert at everything. The truth is that you only know a fraction of what is needed, but I do know who to ask.
Another major problem are magazines. They are mainly interested in either new information or mud raking. Some are seriously interested in what has happened, others… they only want to talk about things that don’t work. But it is my job. I just try and answer the question. Sometimes it’s actually flattering that people think I know so much.

Open Source has become quite important to Sun of late. As I understand it, you’re going to open source all of your code. Why?
It is correct that we plan to release all our source code, but I would like to point out that there is no time plan saying that at a certain point in time all the code will be released. The most important open source project for us now is OpenSolaris. The cat is, so to speak, out of the bag. We have been discussing this for several years. Once we took the decision, we needed to wash the code and make sure we had the copyrights to do this.
The effect is quite positive. We now have a community around OpenSolaris 10, and version 11 will contain features that wouldn’t otherwise have made it in there without the community. And bug tracking of course. Plus it defused the Linux versus Solaris debate. We can now discuss things with our customer in a much more interesting way. Someone at Sun said “It’s not about the code stupid, it’s about the dialogue!”
Internally it has also been a vitamin injection. Involvement is a lot higher. Everything we wished for has happened.
There was a suspicion that we would only let go of the old stuff. Instead we released innovative bits like DTrace etc. This has the positive side effect of code going cross operating systems. For example: a group of people are working on a distribution of FreeBSD, which will include DTrace. That’s one example of code becoming de facto standard outside the GPL arena.
Other high priority Open Source projects from Sun are OpenOffice and Netbeans. The end result of all of this is that we get more competitive. We get better tools and the risk of stagnation disappears.

What is the story with CDDL (pronounced “cuddle”), Common Development and Distribution License? Wasn’t the Mozilla open source license good enough for Solaris?
I’m no expert on licensing but CDDL is based on Mozilla except for the one paragraph that states that the license can be changed at any given moment. It doesn’t even require any approval. Our big clients don’t accept this single difference.

Most readers of JayView already know about the resurgent Javaforum. Apart from that, what is the status of Java in Sweden? Can you spot any trends?
Trends are meta trends and so… What I see from my angle is that Java still dominates the server side. Microsoft probably would have hoped that it would have made a more visible dent in the server side of things. We see very little impact from Dotnet among our customers.
The meta trend is SOA and web services and how to interact in a mixed environment such as Java and Dotnet. We work together with Microsoft on this and more is going to happen. J2EE dominance on the server is not threatened. From a customer point of view, it’s good to be able to encapsulate web services in the different worlds and that there is a consensus on how to interact between the two.
Looking on Java end-to-end, we’ve only started. There have been problems with limited midp hardware and different profiles between small devices. These mobiles will be more powerful. The problem of coping with differences between small platforms will be forgotten in 5 years.
We’re not there yet… but the APIs will be the same and so on.

Q: Sun has had this ambiguous relationship where it both owns Java, but also lets it play with the programmers on the block. It’s not hard too find examples of changing times. Take for example the Apache Harmony project (an open source implementation of Java 5 SE) or the interest in dynamic languages and the effort to provide support for these in the JVM in Java 6 SE. Are Sun’s dual roles over Java changing?
There is a concept within Sun which refers to “church and “state” as far as Java is concerned. Some work within the state it’s no more difficult than that. Java is a big investment for Sun and we want to see it spread, to complete its potential. It’s important that standards are kept and that nobody can corrupt them. Journalists typically want to make a big thing out of this. Our customers think JCP (Java community process) works. Maybe it is true that Sun has been able to keep the two roles apart and at the same time have products.
One strategy that we have followed is that every time there has been a split view, a 50-50 vote, on any subject within a JCP committee, we haven’t used our deciding vote. We’ve actually let the other point of view “win”. I believe that off the record even IBM will agree to this. The common denominator for those who complain, is that they haven’t actually looked into the JCP. It’s rather quick work nowadays. In the beginning some smaller companies complained, but that has been resolved. It’s rare to hear someone say “Damn Sun”.

Java is more of an ecosystem than just a language. What’s the status of that system today? And where is it going?
A flora of tools and frameworks has grown up, but doesn’t necessarily run within the JCP. Java is sort of the centre and further out are things like Ajax. You can go far out from the middle of this system and that is a good thing. James Gosling himself thinks this is very good. He was asked what happens if something can be done smarter in a different language to Java.
“I’m all for it!” That goes for most Sun folks. There is no single person in the world that can answer all the questions within that field – that’s good.

At the far end of that ecosystem I actually place Microsoft and C#. Some of the recent improvements in Java were inspired by the “other camp”, just as ideas and open source flow in the other direction. To me this is “competing symbiosis”. Take away one and the other would stagnate, much like Internet Explorer vs. Netscape. What’s your view on this?
It’s good with competition, but I’m critical of the fact that Microsoft with a budget exceeding some countries’ GNP cannot produce anything better than a pure Java clone, C#, with some minor improvements. Pitiful! But then again, competition is good. The Java community has a keen ear for improvements.
I have to give Microsoft credit for building tools that are easy to use. But this is partly at the expense of power and has meant that some things have not been developed. For instance, I’m totally convinced that Excel is a threat to mankind. People make decisions based on small errors that are impossible to debug.
If we at Sun can maintain the power and at the same time increase ease of use.

What is the best/worst thing that has happened in Java?
The best thing that is happening right now it is that we succeeded with Javaforum. It’s an embryo for an independent organisation. Tremendous. On a more technical level there are lots of good things happening. One thing that I like, but I would not classify it as “tremendous”, is annotation in Java 5.
The worst thing that has happened in Java was Microsoft signing an agreement, only to break it again immediately after. That wasn’t nice – not funny at all. But what was funny was them being made to pay.

Looking into your crystal ball, where is Java heading? Is there a device that will _not_ hold a JVM?
Different times place different demands on tools. Java’s dominance will be broken sooner or later. For instance, there are more network-oriented languages at academic level. Old languages don’t die. Look at how much Cobol code there is.
Java was the fist programming language for the net and shows no signs of old age. I would guess that Java will have a lifecycle similar to Cobol. It will take hundreds of years before it disappears – ha ha.

It has been said that Java will be the Cobol of the future. I dare you to make a guess at when that will be!
20 years from now it will be legacy. Not within five.

I once managed to make James Gosling speechless. He was taking questions from the audience and I managed to sneak in _”What’s the meaning of Java, as in ‘what’s the meaning of life’?”_ What’s your take on that?
It was the first programming system built for the net, just as NFS was the first file system for the net. That was the meaning.

Dang, I thought that at least the last question would stomp Bert.

Originally published in JayView.

Jonas Bonér, your regular AOP guy

February 4, 2006


Jonas is still standing when I meet him at the Öredev conference to discuss an interview. Even though a cold is doing its best to bring him to his knees. He still has a ‘roundthe-globe’ trip to Tokyo to do and the following sprint to reach JavaOne in Japan another one of those Swedes going places.

Jonas Bonér is the founder of AspectWerkz, an aspect oriented framework without the need for special compiler. It later joined forces with AspectJ, which could be described as the Father Christmas of aspect oriented programming in the Java world. He used to work for BEA in Sweden, but has recently joined Terracotta, San Francisco.

Jonas you’re a long term AOP advocate. When and how did you start with aspects and, perhaps most importantly, why?
I started using AspectJ back in 2001 and I was immediately very fascinated by the concepts of AOP, its power, beauty and ability to solve really hard problems in such an elegant way. I have always valued clean design and simplicity and in AOP I found a way of letting design and concepts map directly to actual code.
I started by using ‘policy enforcement aspects’, e.g. AspectJ’s declare error/warning, logging and tracing aspects, as part of the build process. After a while I gradually started to use it for more advanced things, such as security, transaction demarcation, persistence, caching, “unit of work”, design patterns etc. for better modularity, reusability, maintainability and simplicity.

Why did AspectWerkz and AspectJ merge?
The short answer is that the users needed a standard. But let me elaborate a little bit. During recent years the AOP landscape for Java has flourished. When a technology is new and immature it is usually a good thing to have many frameworks/products competing, since they can inspire and push each other and the technology even further, but when the technology matures it starts to become a problem. For example, the users might end up not knowing which framework, syntax and semantics to start using, since they do not know which ones will even be around a year later. If you see this happen a lot, like it did with AOP, then there is a need for standardization.
During 2004, AspectWerkz and AspectJ slowly converged, but the two projects were still focused on different areas and had complimentary strength. We had some discussions and both teams saw the need for standardization and felt that both projects as well as the user community would benefit from unifying the projects, roadmaps and teams instead of competing. So we decided on the merger that was announced in the beginning of 2005 and was completed with the release of AspectJ 5 at the end of last year.

So where do you think we’re heading for in the future, as far as AOP is concerned?
I am confident that AOP will play an important role in the future of enterprise application development. Many vendors are already starting to embrace AOP as an enabling technology for separation of concerns, transparency, simplicity etc. For example Terracotta DSO, JBoss EJB 3, TopLink, Spring etc.
These are all examples of vendors using AOP to layer infrastructure services on the user’s domain models in a transparent fashion. That is great, but I hope that it won’t stop with that, my wish is that users will see the value of using AOP in their application specific code, in order to achieve more modular design, code that is more easily written, understood, reused and maintained. In some ways AOP had a healthy backlash over the last year, which has removed most of the hype around it. It has matured, has a standard in AspectJ 5 and is ready for real-world deployments.

Tool wise it seems that we have several things in place in Eclipse/AspectJ/ AJDT to get a good grip on aspects. Examples: being able to see what code an aspect affects, diff engines to compare changes to an aspect etc. Do we have all we need?
The AJDT team has done a tremendous job and I think that we have already come a long way, even though more work can of course be done and needs to be done in this area. But while this is true for static views of the system, like AJDT is showing, there is almost no support for monitoring and introspecting the runtime view of the system, something that is getting more important now when the usage of dynamic AOP is becoming more widespread, which has the ability of redefining the behavior of the system at runtime. This is an area in which I hope that the academic community will contribute more in the future.

Can you see anything that needs to be fixed or added before we see more widespread adoption of AOP?
I think that the most important thing now is education trainings, books, articles etc. We need to try to reach beyond the group of “expert” developers. Another thing is a standard library. We need an ADK (Aspect Development Kit) in the same sense that Java has its JDK. I am involved in an attempt to gather and develop a set of library aspects for AspectJ 5, and we’ll see where that leads. Finally I hope to see more best-practices, patterns as well anti-patterns emerge.

Terracotta, the new company you work for, has a distributed cache product. What’s so cool about it?
It is completely transparent. Meaning that zero code changes are required to cluster an arbitrary J2EE application. Our only requirement is that you have to write a correct multi-threaded application. We then take that multi-threaded single VM application and a tiny bit of XML configuration to declaratively specify what should be shared, lock semantics etc., and turn it into a multithreaded multi-JVM application. These are the features I find most interesting:
* True transparency.
* Noserialization.We only send the actual changes to an object graph (the delta) as well as keep track of who is referencing who, so we can send these changes only to the nodes that need it, e.g. lazily.
* Object identity is preserved. We maintain Java’s “pass-by-reference” semantics, so regular object references work, which means that you can use your domain model the way you have designed it, as well as traditional OO design patterns etc. without a need to think about distribution, caching or clustering. • Coordination and memory manage-ment. We maintain the Java Memory Model transparently throughout the cluster, including distributed coordination, for example wait(), notify(), synchronized() etc., distributed garbage collection etc. We work as a virtual heap, meaning that you can for example run an application with 200G heap on a machine with 4G of RAM in which we then page in and out the heap on a demand basis.

How does it work?
We use AOP technologies to adapt the application at class load time. In this phase we extend the application in order to ensure that the semantics of Java are correctly maintained across the cluster, this includes object references, thread coordination, garbage collection etc. For example, we extend the semantics of a regular synchronized block, or actually maintain them across the cluster, by taking a global lock for the object instance that you are synchronizing on right before entering the block and releasing it right after exiting the block. You can declaratively define the exact semantics for the block, e.g. read, write, concurrent etc.
Another example is the invocation of notifyAll(). Here we turn this call into a cluster wide notification, which will open up for all nodes to contend for the lock.
The architecture is hub and spoke based, meaning that we have a central server which manages the clients, we use TCP/IP so the server just needs to be somewhere on the network. The client in this case is simply your regular application together with the Terracotta JAR. People always ask whether the server is not a single-point of failure, but we have a SAN-based solution to support fail-over in an active-passive manner. You can have an arbitrary number of (passive) servers waiting in line and upon failure the selected one will pick up right where the master server that has crashed left off.

Finally, as an active open source contributor, do you have anything up your sleeve for the future?
I have some ideas, but nothing I can talk about now. Stay tuned…

Something tells me that we will hear more from Jonas Bonér.
His cold? Well the trip actually made it go away. He made JavaOne with half an hour to spare. I guess it’s that Viking blood.

Originally published in JayView.

AOP featuring Rickard Öberg

February 2, 2004

I didn’t know what to expect, but the appearance of Rickard Öberg – a renowned programmer on the Java world scene – surprised me.
Apart from having written a book on RMI, he has been one of the core programmers behind JBoss. He instigated the XDoclet tool. WebWork, winning Java programming competitions, lectures and other achievements are also on his CV. Moreover, he’s not your average online personality, or perhaps he is? Anyone who remembers the Pet Store debacle*?

* Microsoft vs. Sun over the J2EE blueprint called PetStore. It resulted in a hot debate with many arguments.

I was sort of waiting to meet someone, well, far out. Instead this wholesome dude with a four-day beard greets me with a smile. I can’t help but to think of a strong caffe latte smooth milk blended with mind-altering caffeine.

Q: SiteVision is the content management system (CMS) sold by the company you work for, SenseLogic. Ok, without any prenuptial agreement, let’s get at the first question why?
Why do you use aspect oriented programming in SiteVision? After all, there isn’t that many product grade systems using aspects as a core design choice.

A: There are several reasons. When we began writing SiteVision we soon realized that we had to encapsulate reusable code in a number of places, especially features that were side effects of method calls. Object had to be saved on setter calls, events had to be sent, logging had to be done, transactions should be managed, and so on. We couldn’t figure out a way to do it using standard technology, e.g. EJB, so the only solution was to use AOP.

We were also on a very tight schedule. In just a couple of months we had to build a commercially viable CMS-tool using only five developers, and after that we had to maintain and develop it at such a rate as to catch up, and pass, our competition. It really should be impossible, and it would be with standard technology. The solution was to avoid writing code by using AOP. AOP allows an extreme degree of reuse of code, and because of this we managed to write lots of features with a minimal effort, and since we avoided writing unnecessary code to a large extent it also became easier to maintain. In addition, since AOP makes it easy to add functionality incrementally we were also able to enhance the architecture and implementation as we went along without having to change much of what was already written.

Q: Why roll your own aspect engine? Why didn’t you decide to use AspectJ or some other aspect-inspired tool?
A: After the decision to use AOP was made I researched the available tools on the market, and compared their feature sets with our requirements, especially with regard to code maintenance, performance, scalability. None of the tools, including AspectJ, had been written with such requirements in mind, so we had no alternative but to write our own tools. My background in EJB made it possible for me to combine the principles of AOP with our requirements in a good way.

In hindsight I can conclude that it was the right decision, and if I were to make the same decision today I would still do the same. There is, in my opinion, still a lack of good AOP-tools that support the demands of a complex server side application. The awareness of the importance of such tools is on the increase however, so I would be surprised if this has not changed by next year.

Q: AOP being a true paradigm shift what are the biggest changes when going aspect?
A: There are two things that stand out, from a design and implementation point of view. First of all it takes some time to learn to recognize “cross-cuttting concerns”, that is, code that can be extracted into an aspect. Second, the use of static introductions as a design tool gives one a whole new set of posssibilities with regard to domain model design. Instead of using inheritance as the main building block for reuse of code one would use design by composition, which gives you many more possibilities for combining existing components. It takes a while to get used to this new freedom, but once you do that everything is fine.

Q: SiteVision is soon to go version 2. Has your view on AOP changed during the trip?
A: In the beginning I was, as most others seem to be now, fascinated with the concept of interception. What difffers now, almost two years later, is partly a realization of the importance of static introduction, and partly the understanding of how important it is to have a powerful pointcut model. AOP has so much more to offer than just method call side effects.

As for AOP in general it is great to see that more developers are beginnning to see the advantages of it, even though the examples often are so trivial that it’s hard to see the point of it. I’m also waiting for more people to realize just how powerful static introductions are as a design tool, and the consequences this has for design pattterns and such issues.
It’s going to be quite a revolution, and several tools that exist today in order to avoid the problems of current system design techniques are going to get a tough time.

Q: Do you dare to mention tools, or types, that will have problems?
A: I suppose XDoclet is the most obvious one. We are not using any code generation at all in SiteVision, and that is solely because we have been able to avoid all the problem of standard design principles by using AOP.

Q: Let’s pull out the tarot cards. What’s in the future for AOP?
A: The theoretical part of AOP seems to be stabilizing, but we will probably see more tools in the AOP space. Some people ask, “Why not only use AspectJ?” but I think that’s like saying, “Why not just drive BMW?”. There’s nothing wrong with a BMW, but sometimes a Volkswagen works better, and sometimes a Porsche is the only choice.
As usual it’s about choosing the tool that best matches your requirements, and I can’t see AspectJ being able to match all different kinds of requirements at the same time.

Apart from the AOP frameworks it will also be very important to have good support tools, especially with regard to visualization of AOP systems. Since AOP to a large extent is about fragmentizing and componentizing code it can sometimes be difficult to see what a component does just by reading code. A visualization tool for AOP can put together all the different pieces that make up the whole, and present them as one unit even though they have been developed separately. Access to this kind of tools is, of course, crucial.

We have built such a tool ourselves for our own system, and it has been very helpful when we are expanding the system and when we are looking for bugs.
The step after that, I guess, is the possibility to build packaged aspects that can be reusable in your own projects. However, predicting component markets have proven to be a notoriously difficult task so I’m not going to bet on it.

Q: …and the future for SiteVision?
A: Without revealing too much we can see that our framework and way of building systems gives us interesting opportunities to build application using AOP which run in SiteVision as portlets. Our next version expands the product into the portal segment, and the next logical step after that is to include document management features. We are also looking into how to provide scalability through clustering, and have some rather unique ideas there. But, one thing at a time.

Q: For the finale What are your top five advices for the wannabe aspect programmer?
A:

  1. Read “Design Patterns” (the GoFbook)
  2. Read the documentation for AspectJ
  3. Find a medium size example application and implement it fully using AOP. Pick the framework which best suits your needs. I would start looking at AspectJ for client side development and AspectWerkz for the server side.
  4. Apply design patterns using AOP as far as possible.
  5. Read the AOP-entries in my blog 🙂

It is somewhere around here, at the end of the interview, that I start to long for a good cup of coffee, some Java and lots of aspects 🙂

Resources
SenseLogic: http:// www.senselogic.se
Rickard's blog: http://www.jroller.com/page/rickard

Originally published in JayView.