The problem with templates by Ivar Jacobson

Over the years I've come to regard 'templates' as one of the great evils of software process efforts. I was actually leading the Rational Unified Process team about 9 years ago when we made a big push to create templates for all the artifacts.  At the time I thought it was a good idea since a lot of people had been asking for them. I now regard the decision as having done a lot of damage.

 That statement is likely to shock some - surely I can't be arguing against having standard formats for organizing project information!  Of course I am not arguing against this - but I am against the way that templates are used in many organizations.  

In these organizations, people have little idea of the purpose of many artifacts or work products - they don't understand what they are doing or why, they just know (or believe) that they need to produce these work products.  The templates have been provided as a cheap way of rolling out the process - rather than actually building skills the templates are provided and people are instructed to simply fill out the templates to follow the process.

This approach is wholly ineffective. Organizations fail their people when they require artifacts without explaining why they are needed, or helping them to understand if they are needed, or helping them to improve their skills doing the real work that the artifacts merely document.

The usual result of providing standard templates is that people often blindly fill out the template sections, not knowing what to put in them, feeling compelled to fill out every section because it's there.  Mindlessly filling out templates is a waste of time - the results are valueless, albeit standard, and do not contribute to positive project results.  

I am not arguing for eliminating templates, however - there is some value in having a standard way of formatting and organizing information, but there needs to be some real information in the results produced.  The real problem is lack of knowledge and skills needed to do the work - this is where effort should be spent, not in standardizing templates.  Once people have expertise in doing the work, a consensus can be reached in the organization about how to document the work.  "Templates" will emerge out of that.

Yes, RUP is my baby by Ivar Jacobson

 I often get the question:  “RUP was your baby, but how do you look upon RUP today?”  In an interview a couple of years ago I responded jokingly: “Yes, RUP is my baby, but you know babies grow up and some of them need correction.”  RUP was created in Sweden under the name Objectory.  This was in 1987. 


Objectory was really new since its base could be used to describe all aspects of software development.  Our focus was to identify all of the rules that we use when we develop good software: what are good use cases, good components, good test cases, etc.  The literature in software engineering was totally empty in this space at the time. In order to do this we used object modeling to describe Objectory.  Now we could let the base grow forever – technically speaking.    Any company could make their own new process using Objectory.


Objectory became very successful.  It survived the merge with Rational in 1995.  The next version was named Rational Objectory Process, but after the success of UML, the name was changed to the Rational Unified Process or RUP as we all know it.  In the work of merging the two companies, the process content grew significantly.  However, hidden behind the size, our innovation of how to create a process base and the rules for goodness survived.  The crown jewels of Objectory had survived!


Thus, RUP is one of my babies.  The challenges with Objectory and consequently with RUP were serious. 


  1. Adoption
    Although our way of working in creating a process base was new and great, adoption became quite expensive.  To truly be successful with the adoption and consistent usage was to involve customization, mentoring and consulting which most customers couldn’t afford.  Thus the success rate was too low.
  2. Growth
    RUP was developed inside one company and all new ideas from the outside world had to be filtered by our own people and added to RUP.  It goes without saying that ideas come from anywhere in the world and by having a process be company owned makes it difficult to assimilate these great ideas.  The use of community much like what has been done with open source models would allow for continuous input and improvement.  This also allows for scrutiny. 
  3. Execution 
    All processes are paper-ware and often managed by people who don’t use the process.  This quickly becomes a problem in most organizations because the process becomes a religious document and not a realistic one.  This then has the effect that what teams do and what the process tells them to do is often not in synch.  And since the team is in charge (doing the work) the value of process becomes small.


These challenges paved the way for the agile movement.  The different agile methodologists have one thing in common: they hate RUP.  But that is NOT very smart. There are lots of good ideas in RUP.  Many companies have made the effort in adopting RUP and done so quite successfully.  This has provided them with a very competent staff and something to build on for the future.


However, “the baby needs correction”, and I and my company have done so.  The adoption problem is attacked by focus on the essentials and being light instead of trying to be complete.  We use cards and game boards to describe the process.  Moreover, you don’t need to adopt a complete process all at once, just adopt a practice at the time.  The growth problem is not a problem anymore, since we downplay big process and we make instead practices first class citizens.  Practices can come from any source including the RUP and much of the practice work we have done is in support of RUP adoption. Practices can be composed to create your own way of working.  Finally, the execution problem which is the hardest to achieve, is for the time being our little secret, but you are welcome to learn more about it by studying EssWork and EssUP. 


Trust me, this is very smart.

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.