This time I have something to tell you about my visit to Peru. I had been nominated to receive an honorary Doctorate degree from the University of San Martin de Porres (USMP) in Lima Perú. USMP is one of the most prestigious universities in South America. Thus, when I got the offer from USMP and saw people who previously had been awarded honorary degrees, I felt I was in great company. James Martin (the father of case tools and much more) and Nick Negroponte (the founder of MIT’s Media Lab and the “One Laptop per Child” Initiative) received the honorary degrees in 1997 and 2007 respectively. Read More
More than twelve years have passed since UML, the Unified Modeling Language, became a standard. During these years the perception of UML has ranged from the heights of the heavens to the depths of the earth.
At the beginning of the 1990s there were 26 published methods on object-orientation, most methods with its own notation. It was to address at least the notation problem that UML was conceived. As most of you probably know, Grady Booch, Jim Rumbaugh and I initiated the design of what became UML, but very quickly many other great people joined the effort and OMG undertook to launch the result. UML quickly made most other notations superfluous. Along with the notations many methods also fell by the wayside, leaving the Unified Process, which had embraced UML, as a de-facto standard along with UML. UML’s adoption spread like wildfire. Read More
To an external observer it would appear that the consensus about the way software should be developed changes dramatically every second or third year, more frequently than the whims of fashion. Trends seem to come and go with no rhyme or reason, and it seems that the label you adopt is more important than the results that you get or the things that you actually do.
Are we working in engineering or in a fashion industry?
Have you ever taken the time to investigate a new method or practice only to find that it is just the re-branding and re-gurgitation of ideas that you have seen many times before? Read More
Traditionally many large software organizations have one group to write requirements, other groups design and code, and still others to test, etc. Thus, every group has some form of specialist competency. This is a kind of “siloed” organization. Project work is moved from group to group, with hand-offs between groups that result in delay and inefficiency due to loss of time and important information at each hand-off. This is not agile. Read More
A couple of weeks ago Kent Beck delivered the keynote at a conference in Gothenburg, Sweden. He began by saying that, in the US, agile already starts to get old. Programmers are tired of all these daily meetings where they have to be social. They want to code – they don’t want to talk. This being said by the father of XP and the individual who is probably most associated with triggering the whole agile movement – a fantastic accomplishment that has my greatest respect.
We also have had many indications that, at least in the US, people are getting tired of talking about agile. A CIO of a large company with whom we work won’t use the term “agile”. A CTO from another very large company with thousands of developers where we have been rolling out practices, says he doesn’t care about approaches – agile, RUP or whatever - only the result count. He has distanced himself off from agile since it creates religious zealots in his organization and this zealotry only gets in the way of achieving results. Read More
We software people run after the latest fashion. Five years ago we ran after RUP, now we run after Scrum, and in five years we will run after something else. At each transition we start over, failing to learn anything; we fail to keep what is working and improve what is not. In my two latest blogs I have talked about how we can diminish the tiresome element of religion and fashion when it comes to methods and processes. This is a precondition if we are to ever become software professionals.
The solution looks somewhat like this: all methods have quite a lot in common. After all, they are all used to develop software, and there are certain things that always need to be done when you develop software. Let’s call this the “kernel”, a kind of elementary process which is the mother of all methods. With this kernel as a base all methods can be described in a uniform way, as extensions to this base. Read More
In my last blog I described our immaturity when it comes to software development. Companies follow the latest fashion and jump from method to method without standing on what they already have adopted and that is working. This is expensive and it results in bad software. When I am upset I say that it is stupid and ridiculous. How do we change this?
We need a basic theory describing what software development actually is. In my opinion, this theory is right in front of us - we just need to grab it. We can start with all these methods, processes, and practices and find the "truth" of software development. We have already done this in my company and the result has been used by hundreds of companies around the world. Read More
I am deadly tired of all the buzz that we are suffering from. Our view on how software should be developed seems to change dramatically every second or third year, more frequently than the whims of fashion. Big companies around the world carelessly discard expensive process and tool investments, almost before they have even tried them. Instead of learning from experience they heedlessly start with something they believe is fundamentally new. In reality very little has changed. As in the fashion world, there is much ado about next to nothing. In something as trivial as clothing this may be acceptable, but with the size of our investment in software this is wasteful, expensive and absurd.
The latest trend is “being agile” (as exemplified by Scrum). The “agile” movement has reminded us that people matter first and foremost when developing software. This is not really new - this theme resurfaces every decade or so as naive managers try to mechanize and commoditize what is basically an exercise in creative problem solving. It is important that we not lose track of how to work as a team, how to collaborate, how to document what we do, and how to plan our work on daily, weekly, and monthly timescales, etc. But in bringing these things back to focus, much is lost or obscured by new terms for old things, creating the illusion of something completely new.
The result of this is a lot of wasted effort as old truths are rediscovered but cloaked in apparent new clothing. Younger and less experienced coworkers promote new trends, following new gurus, supported by the hype of a media always hungry for “news”. Managers who have lost touch with actual development find themselves in a hopeless situation: resist the newest fashion and they brand themselves as out of touch. Pilot projects are run to force proof of merit for the new approach, but motivated developers can make anything work on a small scale. As a result the new approach overtakes the old, and all that was working with the old approach is thrown out along with the parts that were not. Only too late do they discover that the new approach itself has parts that don’t work along with the parts that do.
At the root of this problem is a deep misunderstanding of the nature of software development. Researchers have tried to attack this problem with new theories like formalism to prove correctness of programs, or through formal languages which never have been adopted outside the academic world. Industry efforts have spent years standardizing swollen meta-models that defy easy understanding.
Universities and technical institutes teach us a particular way of working. Every project adopts a special method which we must first learn and master before we can begin to work. Every time we change jobs we have to learn a new approach before we can get on with the real task at hand. This is not effective; we cannot learn from experience as we are forever starting over.
We need to stop forever chasing after fads and easy answers that forever disappoint. But how? This is a problem I have thought about for at the least ten years and of course I have a concrete idea on how we can get there. However, I will have to wait to tell you that until my next blog. Let me however say this much: We need to start small and simple and keep it small and simple. We did so with SDL and UML. We can do it again.
That would be smart!
What they don't teach you at institutes of technology – how to be smart
I am slowing down a bit this year. For many years I have made more than ten around-the-world trips and lots of local traveling, but this year I have made only eight. J During this time, I have given a dozen keynotes and more than fifty other kinds of talks. I am often invited to universities or institutes around the world, and I have been offered professor jobs, surprisingly even in Sweden. Thus, I feel I have quite a good understanding of what they teach you about software.
Interestingly, most professors in software have never built any useful software. This is natural since they have grown up in the academic world where software engineering is not as fine as computer science. Of course, this is not true for professors in your part of the world, but elsewhere. J Thus, most professors can’t possible teach in software engineering with any passion.
As a consequence new ideas about software engineering have come from practitioners around the world. The best ideas come from practitioners with an appreciation of science, people that agree with Kurt Lewin: "There is nothing as practical as a good theory". Examples of good theories were Newton’s laws, and Einstein’s relativity theory. Most research represents useless theories. Of course, this is not true in your part of the world. J
Personally, I adopted this motto thirty years ago and it has been leading my work all these years: components, use cases, Objectory that became RUP, SDL and UML, and now practices. Many other people such as Kent Beck and Ken Schwaber have made similar contributions. This is the true essence of software engineering and it stands on a sound theoretical basis, meaning it can be explained so others can understand it and practice it. But, very few universities teach it and even fewer do it well. As I said, this is of course not true for universities in your part of the world. J
However, these exceptional institutes that teach you software engineering practices don’t teach you how to be smart when working with these practices. And this is fine. I am happy if they teach good practices, but to provide real value, each practice needs to be applied in a smart way. The software industry has the capability to help itself in this regard, but I really don’t see that happening.
Smart is about being agile, but it is also about doing the right things, the right way. You can become smarter through training one practice at a time. However, without experience your alternatives are too many and only a few of them are smart. Experience is of course something you can get sooner or later, but it takes time if you must learn by your own mistakes. This is where the utilization of what we call “smart cases” becomes essential. We have a large number of smart cases that relate to working with people, teams, projects, architecture, modeling, documentation, testing, process, outsourcing, and many more.
Each smart case has a key motto for how to be smart, for example:
· People: Software is developed by people, not by process and tools.
· Teams: A software team is like a sport team with all needed competencies to win.
· Project: Think big, build in many steps.
· Architecture: Start to build a skinny system, add muscles in later steps.
· Testing: Whatever you do you are not done until you have verified that you did what you wanted to do.
· Documentation: Focus on the essentials - the placeholders for conversations – people figure out the rest themselves.
· Process: Don’t throw out your baby with the bathwater: start from your existing way of working, find your pain points and change one practice at the time.
And on it goes.
All of this to say, we should learn software engineering practices at school. We should shorten the time to get experience of practices by collecting reusable smart cases. We have started this. We hope others will contribute. I think that would be smart by the industry. J
Scrum is excellent for lightweight management of small projects developed by co-located teams. However, it is not designed for large complex systems, or systems that build a SOA (banks, car companies) or PLA (product line architecture for instance Ericsson) or for large organizations with or without outsourcing. Moreover, Scrum is just one practice. You need many more to develop software.
But can’t we just scale Scrum? Scaling is challenging. In the 1970’s people tried to scale to ‘programming in the large’. Later people tried to scale objects to ‘objects in the large’ (mega-programming). Both never made it. Hundreds of books and even more papers were written on the subjects, but it didn’t help. Instead ideas that were scalable at their roots became successful such as components and objects. At Ericsson we never had to struggle with ‘programming in the large’ since we went straight to components and later to objects.
Why is it so difficult to scale? Explaining this is not difficult but takes a lot of space. Instead let me make an analogy. Suppose you have been able to produce a new chemical substance by using a test tube and a Bunsen burner and the new substance helps with an important problem. Now you want to produce tons of the new substance. Nobody would dream of industrializing the laboratory method by simply building a larger laboratory with hundred meter long test tubes and fifty meter high Bunsen burners. Instead a chemical process would be built in which you would not recognize the original method.
Now, why do we need to scale Scrum itself? Why not let Scrum stay the pearl it is. Treat it as one of your practices in your portfolio of practices also including for example practices for requirements to test, architecture, components. Scale by composing Scrum with other practices.
To the fathers of Scrum I would say: Please, don’t extend Scrum with all kinds of other practices such as use cases, user stories test-driven design, etc. and brand the whole soup as Scrum. Doing so will make Scrum heavier and it will threaten the survival of Scrum because of deficiencies in these other practices.
We help companies around the world to adopt Scrum. However, we don’t see Scrum as the center of all you need. Instead, the center is the practices you already have in your organization, the ones your people already have adopted. Replace them carefully with better practices – one by one. Scrum could be one of these better practices but not the only one.
Do you agree with this approach? Now, it doesn’t happen by itself. It is clear that a practice-based approach is what is needed. We have been promoting and working with practices since 2003. Now, even IBM and Microsoft have started to join this movement. And this is really good for the industry. It is very smart!