Ivar Jacobson avatar

Software Reuse by Ivar Jacobson

February 8, 2004

Many organizations are trying to achieve software reuse. Many of them think that they will achieve reuse if they just put their components in some sort of repository. Then they just expect others to reuse their valuable assets. I never cease to be surprised that people still do that. We have said for at least a decade that you don’t get any substantial reuse by just posting components. It seems as if people, instead of learning from others experience, always have to make the same mistakes as others over and over again.

The book I wrote with Martin Griss and Patrik Jonsson on Software Reuse is very explicit about how to achieve reuse. The subtitle of the book is: Architecture, Process and Organization for business success.

It all starts with Architecture. You design an architecture which identifies which components are reusable and which are not, thus a layered architecture. Usually two layers on top of middleware are enough. The top layer contains application components, which are not designed to be reusable. The second layer contains the domain components intended for reuse by several applications in the top layer. The only practical way to get a domain component is by designing an architecture in which the component has a clear role. Without this architectural setting, a component will never really be reused.

Process comes next. The way you develop the domain components is different from how you develop application components. They are documented for reuse. We suggested in our book that you design a façade for each domain component. This façade contains an extract of the models of the component, an extract defining how the component can be reused. In case the domain is big enough (e.g. banking, telecom, airline), the façades can through careful design evolve into a more powerful tool – a domain-specific language (DSL). Instead of designing on top of the interfaces of the domain components, expressed through their façades, you will design using a domain specific language.

Domain components also come with a kit containing tools for its reuse, examples of how to reuse it, and other things that help in getting it reused.

Developing application components is different. Application components don’t require to be documented for reuse. Instead they are designed using domain components and through interaction with other application components.

Finally Organization. In order to get successful reuse, you also need to develop an organization which maps 1:1 to the architecture. This means that for each component in the architecture there is a corresponding responsibility in the organization. Higher level components are the responsibility of a subsystem-owner. Lower level components are the responsibility of an individual developer. Without such a simple mapping between architecture and organization it will be practically impossible to get good reuse. Such an organization will become an expert organization – people will become experts in a subject matter. It grows people that want to create quality products. I call such an organization an architecture-based organization as opposed to a project-based organization. A project-based organization has a line manager for each project. The manager should only care about his own project. Such an organization is counterproductive to reuse.

In an architecture-based organization, the project managers are not line managers. Instead they own the budget for their project. Using this budget they can buy resources from the line organization (that is the subsystem-owners with domain expert developers) to get their projects done in time. The line organization can work with several projects concurrently and they have to prioritize them based on delivery dates. Yes, there may be conflicts, but these are usually not large. The total costs are substantially lower because the domain components are developed and maintained by experts. Thus in the case of conflicts, more resources can be added to remove the conflict, and still the costs are much lower than with a project-based organization.  

The approach I just presented also has the advantage that you grow the reusable components as you work with real projects. You will start with an empty architecture, but you fill it as you go. You don’t sit there and speculate about what might be reusable; instead you design the components in the architecture that are first needed. They have probably not stabilized for the first project, so they may have to grow through several projects before they really become reusable without redesign.

To achieve reuse is not easy. People have tried simple solutions like class libraries and component libraries into which component designers post their components hoping that other people will reuse them. We have seen very little reuse coming this way. Managers have thought it was the lack of incentives so they have stimulated all kinds of initiatives to get reuse. This is ignorant. You will get reuse, but only by standing on top of an integration of A, P and O, that is Architecture, Process and Organization. In another postcard I will tell you how you can move to an architecture-based organization from a project-based organization without revolution. It is really fascinating to see how easy it can be done, given that you are smart. However, that is not a problem, since you are smart, aren’t you?  

Architecture by Ivar Jacobson

February 1, 2004

Singapore is one of my favourite cities in the world. I like it for its people, for its various kinds of delicious food and for its advanced software companies. Singapore is also the cleanest city in the world.

I have just finished a week of intense work, meeting customers in rather small but competent groups. Basically all customers have expressed that the week was very important and they are now looking into how to move forward. Thus I feel happy with my work. I will soon take a flight to Seoul in South Korea, but before doing so I will reflect on one of my concerns with RUP.

In my earlier email I said that I often get the following question? “Is there nothing in RUP you don’t like?” I responded:

“Of course, there are many things I don’t like. However, they are in comparison with what I like rather small.” I said that one of them is “The way RUP describes architecture is unnecessarily complex and confusing.” In this postcard I will elaborate on this concern.

The single most important determinant of the quality of a software system is its architecture. A good architecture is an understandable architecture, it allows a system to grow gracefully for years to come, and it forms a system that is built out of reusable assets or that has harvested such assets.

Develop architecture first
Developing the architecture should therefore be done as early as possible. Even in theory it is very difficult to change a poor architecture into a good one with incremental techniques such as refactoring. In practice it is close to impossible. The costs are too high for any business-oriented manager to accept and he/she will typically opt for quick fixes instead. A good architecture needs to be created when the cost of creating it is small or even non-existent. Prioritization of architectural work has a very good return on investment. It will reduce the need for redesign and minimize throw-away work during the remainder of the project.

Architecture is captured by a skinny executable system
However, architecture is not just a paper product. The architecture must be verified and validated. We do that by first building what I call the “skinny system”, a system that includes a backbone with enough muscles to be able to exercise it. It is a system in its own right. It has everything a system has, but only things that are significant. Thus, it has all significant paths through the use cases (or scenarios); it has all significant subsystems, components, classes, nodes. Usually this skinny system only includes 5-15% of the final code, but enough to demonstrate that the significant elements work. And most important, we know that this skinny system can grow to become the complete system. This is so because we have scrutinized all features and use cases and selected to implement (part of) those that carry the largest risk, have the highest priority, or are unique in some other way. The remaining parts of the system can then be added incrementally without disruption. This skinny system is accompanied by a paper product called the architecture description. But now, this paper product is verified and validated. The architecture is actually working.

The architecture descriptions are views of the models.
The models are the models that we have in RUP. Thus it is the use case model, the analysis model, the design model, the implementation model and the deployment model. Well nowadays we have more models. We have a user experience model, we have a domain model and when we work with asset based systems (software reuse) we have even more models.

So far there is no major difference in what RUP describes as an architecture description and how I think it should be presented. The problem comes now when we start to look at these views of models. In RUP each view has been given a name. They are the use case view, the logical view, the process view, the implementation view, and they don’t map exactly to the models. It means that the developers have to deal both with names of views and with names of models. It is just confusing. I have yet to meet one developer or one tech rep at Rational that understands both this view structure and the model structure. Even some top experts at Rational could never really explain how these structures were related to one another. Most people either understood the view structure or the model structure.

And it could have been made so simple.
Since the final product is described by its set of models, and architecture is about an extract of these models, there is no reason for having separate names for views. Instead just call them simply the architectural view of the use case model, the architectural view of the analysis model, the architectural view of the design model, etc. Most people I talked to agreed that this was a simplification, but I could not convince the key people…and I didn’t get a reason for their hesitation. The only reason, I was told, for keeping view names separate from model names was that for architecture we needed a process view and there was no process model. That is an argument that I don’t accept. If we need an architectural view, we most certainly need a model as well, since the models are the complete description of the system.

Thus the most natural way to deal with architecture is to describe it as an extract of the model structure and call this extract for the architectural views of the models.

This is the right approach for other reasons as well:

  • There are more models than the original 4+1. The more we get the harder it becomes to give names for views that are different from the names of the models.
  • With asset based development we get many more models; it becomes almost ridiculous to name its architectural views different than the models.
  • The user experience model is as important as other models from an architectural viewpoint, something the advocators of separate names originally didn’t agree with. Would we give the architectural view of that model a separate name? No!
  • Finally, test is nowadays not a separate model, but instead each of the other models has a view for testing (verification and validation). Thus we have test views of basically every model…are we going to give these separate names as well? No!  

Thus, this is my proposal for you RUP developers. It is my hope that you take the chance to simplify the presentation of one of the most important artefacts in the software industry. Make the architecture description what it ought to be – an extract of the complete set of system models and remove it from being a creature living side by side with the system. The most important reason is to make RUP easier to understand. RUP is complex enough without making it unnecessarily complex.  

Putting the "R" in RUP by Ivar Jacobson

January 15, 2004 

Let me first wish you a very happy new year 2004. I hope it will be an exciting year both personally and professionally. A lot of things are happening in my life right now, so my expectations are very high. My work on aspect-oriented software development is going very well and Jaczone is in a very thrilling growth period. My passion has never been higher.

Yesterday, I gave five talks here in Jacksonville, of which the talk to the Rational User Group in Florida had most attendees. I spoke about Use Cases and Aspects and about "What you didn't know about RUP". It is always demanding, but also fun, to speak to people who have followed my work for many years.

My talk about RUP is of course very positive to RUP. As most of you know, RUP was originally created in Sweden but at that time it was called Objectory. When Rational acquired my company in 1995, we changed the name to Rational Objectory Process and later in 1998, when UML was adopted; we again changed the name to Rational Unified Process. We wanted to surf on our success with UML.

To tell you the truth, I have never been happy with putting Rational in front of the Unified Process. It is OK to have the company branding in front of product names, but to put it in front of intellectual work is different. Personally, I don't like to have to use a company name every time I utter my approach of thinking. However, working for Rational made it not so hard for me, but all my friends out there working with customers don't want to use our brand every time they mention our approach. I can't see that the standard approach of software development should be branded by one single company, even if this company is large.

Since I express myself so positively about RUP, I often get the following question? Is there nothing in RUP you don't like?

Of course, there are many things I don't like. However, they are in comparison with what I like rather small. They are still in absolute terms very important. In this postcard I will just list them. In later postcards, I will explain what I mean.

These are the three top issues in RUP that I don't like:

The way RUP recommends us to do analysis is a compromise that won't help customers succeed.

  • The way RUP describes architecture is unnecessarily complex and confusing. I agree with what architecture is, but not with its presentation. Very few people understand what the architectural views are and how it is related to the different models being advocated.
  • RUP has grown and become to complex. Too complex for users of course, but even more complex for the poor people that will have to maintain and develop it further.

Of course, I have recipes for how to solve these problems … and many more. The user complexity will be eliminated with the help of tools such as WayPointer from IJI.

Complexity by Ivar Jacobson

November 15, 2003

Even if I am Swedish, it is not often that I give speeches in Sweden. However, once a year I have been invited to speak at the Nordic Rational User Conference. Thus, today I gave my talk about Use Cases and Aspects. This is probably my best talk ever. It is better received than anything I have talked about before. I think there are several reasons for this reaction. Use cases are already very well adopted. Aspects are new and hip. Use cases and aspects are really a couple - aspects are the missing link to keep use cases separate all the way down to code -- even down to runtime. If you want to learn more about use cases and aspects there are a couple of articles I have written on this subject, look at: http://www.ivarjacobson.com.

The conference ended with a panel discussion on the biggest challenges that we face in software. Each panellist was supposed to suggest one challenge only. The moderator then asked the audience to vote for the challenge they felt was most important. The superior winning challenge was Complexity in software development.

This was of course something I could wholeheartedly agree with. Since someone else gave the winning challenge I had to suggest something else: complexity in usage. Users usually only learn 10-20 percent of the features in an application. The rest they never learn. It is too complex, people don't read manuals, and even if they did, they would forget what they have read before putting it to use. 99% of all software of today is passive software. It is waiting for the user to figure out how to make the software useful. We need a new kind of software. We need active software. This is software that instead can figure out what the user is trying to accomplish and actively help him or her to be successful in doing just that.

The next question to the panellists was "How are we going to tackle complexity in software development". Here we heard all kinds of answers. I suggested that we need a new approach to software development. Software development has never been as complex as today. We need a new class of process & tools. We can't continue with a passive process like RUP and we can't continue using passive tools. We need active process & tools.

The winning proposal was that we need to invest more in training. About 70% of the audience voted for this proposal. Maybe 10% voted for active process & tools. I must admit I was quite disappointed. As if we have not invested in training over the years. Traditional training is simply not effective. It is done out of context with artificial examples and at a single point in time. With active processs and tools you learn as you work when you have a concrete business problem to solve. OK, I had to accept the answer, but to my inner self, I said that this will change. This is not the first time that I have suggested a new idea and almost no one liked it. A couple of years from now, I think we will see much more of active software. At the least I will work to make it happen.

UML by Ivar Jacobson

October 30, 2003

The largest conference on object technology is OOPSLA. The first OOPSLA conference was in 1986 and I have attended all of them but one. And, I have presented papers, or given tutorials or been on panels each time. Last year I decided not to go there. I wanted to break the rule (to go to OOPSLA) so that I wouldn't become a slave under it. This year the conference took place in Los Angeles, or more precisely in Anaheim - the home of Disneyland.

OOPSLA is a meeting-place for pioneers in software technology from all over the world. Everywhere there are friends from many years back, and we really get together and discuss what we are doing, what we want to do, what we think is hot and what we need to change.

This year I participated in two panels, one on Reuse and Repositories, another on Model Driven Architecture. The most interesting and passionate one was the one on MDA. Much thanks to my friend Dave Thomas (also on the advisory board of Jaczone) who dared to question the UML as well as MDA, as envisioned by OMG, in a very direct way.

Dave: "UML is currently a language with no conventional syntax, and not even a comprehensive standard way for tool interchange (XMI is both awkward and inconsistently implemented). UML was designed by committee, most of whom are methodologists and hence have little experience with language design. UML lacks a simple semantic account as an executable language. There is no published semantic account although proponents claim it is well defined via action semantics."

In general (not only from Dave) I understand the critique against UML as follows. UML is designed by people who have no experience from traditional language design, which means that the language is a mess. Even worse, they have no experience of real software development but they come from the methodology camp with no real software product background. These people have never developed any real software.

Of course, in a setting like OOPSLA Dave's words fell in very good soil. It was a very popular standpoint.

While I am not completely positive to everything in UML, I heard nothing really new in Dave's position. To me it was a dejà vue. I have heard the same critique for more than thirty years. I heard it when I introduced component-based development with visual modelling back in 1967. I heard it when we developed SDL that became a world standard in 1976 within telecommunications. And now I hear it again.

I was originally very critical to how we worked with UML 1.0. Some people wanted a very intuitive approach and define the language with basically just a notation, some meta-model diagrams and plain English text. UML 1.0 became hopeless to understand. I advocated that we should apply classical language design techniques. Starting with an abstract syntax, build a static semantic model on top of the syntax, introduce dynamic semantic domains. I didn't suggest that we should define the operational semantics formally. I made this compromise primarily because most people wouldn't understand it and very few people would care. Moreover this wouldn't be different in approach from most other language designs. I have personally done a lot of language design work when we defined SDL and CHILL, I also did it when working with my doctoral thesis. Thus from a practical point of view I couldn't recommend it. Also, I felt comfortable we could add it later.

During the work with UML 1.1 my approach was adopted. We didn't formalize the dynamic semantic domains. We defined the operational semantics textually only.

Thus it is not correct to say that language-design amateurs defined UML. My own thesis was a definition of a modelling language using classical language design techniques.

It is also not true that UML was designed by people with no practical experience from software development. I was not the only one with many years of hard work in real software development. The UML team was also backed by 10,000's of developers working behind the scenes and applying the technologies being proposed. We had reference groups all around the world that helped us understand the needs to satisfy.

This was UML 1.1.

With UML 2.0 the situation changed. A lot of new people entered the scene, and a committee took over. With "a fresh look", they changed everything they didn't like. And they added what their "fresh look" told them should be added. Personally, I was so bored working in a committee so I stayed out of the work almost completely (I had done language designs three times before, so I couldn't feel any excitement). I said "almost" because I had to get involved on one occasion. That was when the committee decided to remove use cases from UML. Well, they removed the kind of use cases we have had, and replaced them with something different…and then they called this new thing use cases. They were so arrogant, that they told me, without a blink, that I had never understood use cases, but now they had got them right. They voted in the committee and agreed to remove our use cases. Luckily, people outside the committee set things straight and put use cases back into UML.

Many members of that committee had never produced any useful software. Some members were really competent, but the politics became a burden. Now the committee took a lot of time, they were delayed by years, and the resulting proposal UML 2.0 is very complex. Still, I am optimistic. The interest for UML is so high and there are so many people that are willing to fix what potentially is broken. Thus, I am convinced without a single doubt that UML will continue to be successful. It represents very much what a good part of the software community wants to have.

However, this part is not in majority. It may today be 20% of the software community. The remaining 80% have not adopted visual modelling at all. Twenty years ago I believe that it was less than 5% that used visual modelling.

Thus I believe the reason UML is criticized have other roots than bad language designs. The critique represents symptoms not the root cause. I believe that the roots of the critique are that some people don't believe in visual modelling as such but that textual languages work better.

The critique is healthy. UML will most certainly become better defined. We will get better and better tools. The tools will make software development less complex, we will be more productive, get higher quality, and get software much faster --- very much thanks to UML and how you can apply UML.

Anyway, it was a very good panel. People love a good fight. Dave was the clear winner, but that was a given. He was playing on home ground.

During the aftermath of the heated discussion, someone said that whether you are for or against UML or MDA rests on religious grounds. That is something I can wholeheartedly agree with. On the other hand, this is what I heard when I introduced components, use cases, … I have been very honest about it. I have never been able to prove that my approach is better than anyone else's. At best, I have been able to make it believable.

With UML and MDA we have a similar situation. It is very much about gut feeling. Either your gut feeling tells you that UML and MDA are good, or it does not. Your way of working will be coloured by your feelings.

Regarding UML, I have absolutely not a single doubt about its long-term success. About MDA, I am very sympathetic. I know that MDD (model-driven development) has been successful and will become even more successful in the future. Whether MDA will be successful is a question of execution, i.e., how well OMG and its members succeed in implementing the vision. I will support them, and I wish them very good luck.  

Seoul by Ivar Jacobson

October 27, 2003 

This is the third time that I have been in Seoul this year. I must like Seoul and Koreans very much because going from San Francisco to Seoul is a twelve-hour flight! It is actually longer between San Francisco and Seoul than from Stockholm to Seoul. Most Europeans would not have guessed that.

One objective for this trip was to meet Samsung Electronics - a company that have impressed me very much. They are world-leaders in so many areas and technologies. Their people are world-class and they work very hard. I think they shape the future.  

IBM Rational in Korea had arranged for me to talk at the Korea University. Rational and the university celebrated an agreement on using Rational Rose. It is so refreshing to talk to students. They are so immediate and spontaneous. Lots of laughs, autographs and photos.

There is one thing I would like to ask you. What do you think is the most important property one needs to be successful in software development? The answer is being SMART. I think we should teach students what it means to be smart, so we always recognize non-smart behaviour.

Being smart means that you do what you need to do, no more and no less. For instance, when applying RUP, do it right, do it as agile as possible. I have never believed in just buying RUP and have your people apply it. They will do too much or they will just give up. When I meet customers and get project reviews, I often see that people are not allowing themselves to be smart. Often they work too hard and do too much, or they do too little and have given up. You need to apply as little process as possible, but NOT less. The trick is to know what is less. For that you need experience.

Smart is not the same as intelligent. I know many people who are very intelligent but not smart. Smart requires that you have knowledge, not just experience. Smart is not just about how to apply techniques, it is also about how to deal with customers, managers, and the unexpected.

As an example, I see agile as a property you get from a process like RUP by being smart. Personally I think RUP applied in a smart way is the most agile we can be.

I would like to see more on this subject. If anyone has seen a book or a paper that develops the meaning of smart, I would love to read it.  

New York by Ivar Jacobson

October 9, 2003

This week has been hectic, arrived Monday to New York from Copenhagen. In the limo to the hotel, I called Agneta – CEO of Jaczone. She had arrived a day earlier and was at the hotel. She told me that her luggage hadn’t arrived yet and that she needed to go out shopping. OK, see you for dinner. I was looking forward to a couple of hours of work in the hotel room, happily knowing that I had my luggage in the car. When I got into my hotel room, the first thing I always do is to hang my clothes in the closet. I open my bag and stare into it in surprise. I had my luggage but it was EMPTY – apart from shoes and underwear!!! I had forgotten to put the hanger with suits, shirts, pants, into my bag. All of it was left in Copenhagen at the Marriott hotel. Thus I had to call Agneta and tell her – I also have to go shopping. See you at Saks.

Tuesday night, the Swedish Consul Olle Wastberg had arranged an investor seminar in his private residence on Park Avenue. Five companies presented their visions for the future. Mike Romach, IBM Rational, gave the Rational perspective. Jaczone was represented by Agneta and me. I outlined our vision that the software industry will move to a new era of software, from passive software to active software. I said bravely that the last time we saw a similar paradigm shift was when the automation industry moved from electromechanical technology to software. And that was less than 50 years ago.

Agneta introduced WayPointer as an example of this vision, and she also told the audience that Jaczone was looking for people in New York. She got a lot of attention from investors as well as a few applications directly after the seminar!

Wednesday, after a full day of customer meetings, we left for Ottawa, Canada. Thursday, Rational had arranged a seminar on the Future of Process. I talked about my Four Macro Trends and Agneta about Making Software Process Active and she gave a demo of WayPointer. Afterwards we had a Q & A session. Almost all questions were for Agneta. It is amazing how excited people become about Jaczone’s technology. Well, it is for very good reasons.

Now, I am on my way to San Francisco after a day of customer meetings in Toronto. The week has been very good. With a glass of champagne in my hand, I reflect over some problems the software industry is facing.

It has taken many years for outsourcing of software development to really happen. Now it is happening at a galloping speed. Every larger software organization is on its way to the Far East, in particular to India. I expected this to happen many years ago. I have been in India many times over the last five years. Well, now it is happening. When I listen to CIO’s from Europe as well as USA, I think this can very well become a bubble that burst. Many companies outsource the work in a completely thoughtless way. Some of them view the Indian developers as code chimpanzees. The architecture work and the design work will continue to be done in the West, but the coding and testing will be outsourced. And they do other similar wrong-doings.

We will need to help them. First, they need a good process to develop software with a team that is located cross the world. We have one – it is the Rational Unified Process. They need tools of course. Rose and XDE are capable of supporting distributed teams. However, to train the people in RUP and in the tools, they will need a mentor. The only reasonable way to provide these mentors is by providing them with a tool like WayPointer. This is a great subject for a book!

Not a single boring moment in front of me. Please, give me another glass of champagne.  

Iceland by Ivar Jacobson

September 29, 2003

Today, I am in Iceland for the first time. I have always wanted to go to Iceland. This is the country where people today speak a language that has changed very little in 1000 years. At that time our ancestors in Sweden, Norway and Denmark spoke a language more similar to Icelandic of today than to our modern languages. And, most amazing, I didn't understand much.

The reason I came here is that I just gave a talk at a WebSphere user conference. Unfortunately, I can only stay for a very short time. I arrived at 4 pm yesterday from Bonn in Germany and I leave at 1 pm today for Stuttgart - also in Germany. Since it takes about eight hours to get from Germany to Iceland, this nothing less than crazy! I have had a very interesting discussion with some key people. We all agree that software is becoming harder and harder to use - for many reasons. How are we going to change this trend in a dramatic way? Those of you who have followed my work the last couple of years know where I am heading. I believe we need to take a magnum leap. Basically, today all software is passive. The user needs to take initiatives and step by step tell the software what to do. I think that this needs to change for many reasons. Software gets too many features that most people don't know how to use. For instance, how many of the features in a mobile phone do you know how to use? Twenty percent? I believe we need to change this. I believe the trend needs to go from passive software to active software. By active software, I mean software that can help the user to use it - in many different ways. Our WayPointer is such a tool to help people use RUP, Rose or XDE. It makes RUP active. And WayPointer is just the beginning of a trend that will encompass all software.  

Aspect Oriented Development by Ivar Jacobson

September 8, 2003

Last week I gave a talk on aspect-oriented software development at an IBM conference on this subject in Yorktown Heights. Last time I was at this IBM facility was in 1984 when I spent a year as a visiting scientist at MIT. IBM then offered me a job doing research in language development (Prolog-based). I was very excited about moving permanently to the US and so was my family. However, I decided to go back to Sweden to complete my thesis and get a Ph.D. If not, I probably wouldn't have founded Objectory, which was acquired by Rational, which in its turn was acquired by IBM. However, the "end" result was almost the same - working for IBM :-). I am now an executive technical consultant of IBM.

I believe that aspect technology will dramatically improve the way software is developed. I have described this technology as 'the missing link' to keep use cases separate all the way from requirements to code and test. I have written several papers on this subject. Right now I am working on a new book on aspects & use cases.

Last week I gave the same talk on Aspects & Use Cases at the Rational User Conference in Orlando. It was a very well organized conference - a lot of good technical stuff as well as a good portion of fun.

The conference was in Disney World, Orlando, so there were lots of opportunities for having fun. One evening we were dancing at the hotel. Great Caribbean music. The bad part was that the music had to stop at 10 pm! There is no doubt that the interest for aspect-oriented programming (AOP) is growing dramatically. The good news is that the use-case driven development approach is a perfect fit with AOP. To make AOP successful, it needs a methodology. We have such a methodology. Still, it will take a few years before tools support this technology.

At the same conference Jaczone (www.jaczone.com) demonstrated WayPointer. WayPointer really got a lot of attention. All the time there were people waiting to get a demo. What is so exciting is that WayPointer makes process active and at the same time practically invisible. This is done, by using intelligent agents to support developers in the many micro-activities in software development.

Aspects and agents will be important complementary technologies for the next years to come. You should take the time to learn about them.  

Future of Process by Ivar Jacobson

August 15, 2003

I am currently in Lima, Peru where I have participated in an international conference and given a series of workshops.

This week started in New Orleans, where I gave a keynote at the XP Agile conference. I arrived late Sunday night but my XP friends were kindly waiting for me. Ward Cunningham, Bob Martin and Ron Jeffries were there. I had a great time with these people whom I respect very much. I have known Ward since 1987 and he is one of the few people who has moved technology into the masses with ideas such as CRC Cards, XP and also Wiki. Ron Jeffrey and I have been on a panel discussing light versus rich processes and we will be on another panel in October. We were missing Kent Beck (who arrived later) and my old personal friend Dave Thomas (who is on the advisory board of Jaczone).

I sympathize a lot with XP and agile methods. I have different opinions on some XP ideas, but in general I think XP is a good approach when exploring a new product. However, I think that XP doesn’t help you grow an organization. Therefore I want a process that can be as light as XP when you start a new initiative, but a process that can grow with the organization as you become successful. Well, I could talk a lot about that but not in this short postcard. My keynote was about the "Future of Process". The core message is that we talk too much about process instead of focusing on getting the job done. Instead we should rely on best practices of many kinds: technical, human, project, organizational etc. These best practices need to be well-defined, they need to be kept separate, but composable, and need to change as time goes by. Ideally the end-result should come across as an "Invisible Process". Here techniques like Waypointer developed by Jaczone will play a very important role.

Peru was very friendly, but the conference could have been better organized. I gave three presentations, I had about 200-400 people each time despite my talks being announced just 4 hours in advance of the actual talks. One challenge in Lima is that people in general don't speak English that well. Luckily, they found an excellent translator for me -- Elizabeth Ramirez Perasso, who has been studying my work for many years. I found that I have many fans in Peru. Thus I need to go back!

Page 8 of 812345678