Two complementary macro-trends in software engineering by Ivar Jacobson

From my horizon, I see two distinct and yet complementary macro-trends driving the way we become better at developing software. One could be called “Methods & Tools” the other could be called “Professionalism & Craftsmanship”. These two trends are not new, they have been around as long as we have built software. Both are based on the fact that it is people who develop programs, rather than methods and tools. But they take different approaches to the problem by focusing on different aspects of software development.

Trend “Methods & Tools,” exemplified by Semat Initiative (, of which I myself am one of the founders, drives the thesis that the way we develop software is immature and in need of being revolutionized. Yes, these are strong words, but the initiative is supported by more than 30 renowned scientists, scholars and practitioners in the software engineering field, including leaders from major industrial corporations (e.g., ABB, Ericsson, Fujitsu, IBM, Samsung, Microsoft, etc), academia (researchers, professors, institutional managers), and thousands of practitioners around the world.

Specific problems addressed are that often methods seem to be based on fashion and fads; that there are almost an infinitive number of methods that cannot be assessed or compared with each other. The number itself is not a problem. There should be many methods, however, these methods must be designed in such a way that they can be compared, assessed and improved. Finally, there exists a big barrier between academic research and industrial practices, which must be torn down.

The way forward is based on observation and understanding that:

  1. Every method is just a composition of practices, either human or technology related.
  2. Practices are reusable over many application areas and technologies.
  3. Underneath all practices is a small kernel of universals described by a small kernel language.
  4. Universals are things that we always have, do or produce when building software.  We will discover them!
  5. Practices and universals will be described by a small Process Kernel Language.

Using this kernel and the language, we can describe all known methods, and, because practices are comparable, methods that are composed from these practices can be compared. I would like to tell you a lot more now, but it can wait for later. The impact of this SEMAT initiative is that, if successful, we will streamline the entire software world: from academia to industry, from practitioners to teachers and researchers. We will become better, faster, and happier in developing software.

After all, it is people who develop software, not methods and tools. So we must address the “human” side of software development.

Trend “Professionalism & Craftsmanship”, which is popular with the original founders of the agile movement, for instance by Bob Martin (“Uncle Bob”), who takes a very different standpoint. From this perspective, the big problem is not the lack of methods or tools, but how we train, educate and mentor programmers to become professional craftsmen. Code can be written by anyone at any time, but what makes us professionals?

  1. We must be proud of what we do. We must be able to say “no” to either the boss or the customer, if necessary. We have our professional practices and these cannot be compromised.
  2. The boss and the client must accept the fact that our work is technical in nature; so let them think we are geeks, but respectable geeks.
  3. Eliminate hourly rate - doctors or lawyers are not paid by the hour (even if under pressure they may say so). There must be better ways to charge.
  4. Anything that is worth doing should be done well and with quality. When we ship code, we must know that it works. Acceptance testers should not find any errors.
  5. Become competent through an apprenticeship program. Choose a master and learn from him or her.  After some years you may select a new master and also learn from him or her.

Both trends are of course important.

Proponents of methods & tools suggest that it is clear that we must constantly improve professionalism. However, it would be much easier to be professional if we can elevate the level of our understanding of methods & tools.

Proponents of professionalism & craftsmanship are concerned that such an elevation means enforcing restrictions, and many are therefore hesitant or reluctant to work with or support initiatives related to methods & tools.

It is clear to me that we must do both. Since Bob Martin is a signatory of Semat, I think it is clear to him as well.

It is smart!

  1. Martin K | May 21, 2013 at 5:57 pm Reply


    I have been a software engineer for 20+ years. I agree with the need to nurture the “professionalism & craftmanship” of our profession. However, for me, the problem of not building software well lies in creating the opportunities. Sales people, including Project Managers, need to negotiate with the client to ‘create software the right way’. But, they are woefully inadequate at this because they don’t care about the software development process & “they think they know it all anyway”. Unfortunately, most software engineers are woefully inadequate sales people and negotiators. Therefore, a disconnect exists and the software engineer/craftsman loses out due to his/her inability to persuade their own Project Manager or Client Manager, of the importance of doing things right.

    I think Boehm did a great service in creating his estimation accuracy curve. However, I fear that I am the only person who still gets this down off the shelf and presents it to people.

  2. Niko Schwarz | May 8, 2010 at 9:33 am Reply


    As a matter of fact, in Germany both lawyers and doctors are paid by the hour. (It’s a bit more complicated than that, I’ll give you that, but that’s actually quite comparable with much consultant billing)

  3. Edmundo Andrade | May 7, 2010 at 11:53 am Reply


    I don’t know if these two macro-trends are really complementary. What everyone knows is that they are important to improve the art, science and craftsmanship embedding in the context of software development.
    Sometimes, they appear to be in opposite sides. In software development, it’s not rare to see a matured tool or method not so useful or productive as it was months/years before when it was beging beveloped, tested and assessed. It seems choosing and developing tools and methods needed to develop software are an crucial part of the development process itself.
    Many businessmen, marketing people, and customers see software product as something can be delivered by means of a clear and scientifc path, until they see the product or increment for the first time. Developers (analysts and architects, included) expect to find a stable environment to keep adding value to their stakeholders and users. This hopeness last until the first feedback from the clients (stakeholders and users).
    A good adaptive kernel process have to allow developers take decisions to change/extend the process with new methods and tools, according to the project/product variables present each moment.