Ivar Jacobson and Paul McMahon
As a developer, you care about building great software quickly and making your customers happy. A developer is anyone involved in developing software. This includes architects, analysts, programmers, testers, etc. As time goes by developers want to become more and more professional working with software. When they move from team to team or even organization to organization they want to hit the ground running and be productive as quickly as possible.
If you agree with this, then Semat is for you. We want to explain why we think so, but first we need to brief you on some key ideas of Semat. These ideas will, as we will explain further down, help you work better, faster, and be happier, which we believe is your ultimate goal. But before getting there let us tell you a story, which you as a developer might appreciate.
The Zigzag Story of Software.
In the software world we have been moving in a zigzag path for close to 40 years. We zig to one method and then zag to the next. Often it feels like we are moving from one extreme to another. While there has been evolution we have also thrown out valuable ideas along the way only to later rediscover them. Some developers are tired of the zigzag story of software. They have had enough of it.
Once, about ten years ago, when I (Ivar) spoke to a small group of 50 people, a senior guy stepped up, very frustrated, and told me that UML and RUP would be dead in five years and I would be gone as well. I like provocations so I asked him calmly what he based that upon. He told us that he had worked with software his whole life. ‘In the 1960s we all worked with assemblers, then we got Cobol and Fortran, then we got database design’ and he continued describing a zigzag path with new methodologies in every step: ‘structured programming, structured analysis and design, object-orientation, components and so on.’ He felt it was awkward hearing about yet another silver bullet. If he had continued to be in business he would have been zigging and zagging with even more bullets: UML, RUP, CMMI, XP, and now Scrum, Kanban, Lean. And, if we don’t do anything about it we will find new bullets to zigzag with forever and ever.
Semat is addressing this problem by identifying a common ground of software engineering including the essential elements we always have to work with. This common ground is made concrete in the form of a kernel. The kernel is small. It is expected to just include 10-20 elements. Our initial kernel, which we are providing to a small group for review and feedback this month, contains four elements (Team, Work, Requirements, Software System), each with a small set of progress or health states and checklists. Thus, you can easily learn the basics about the kernel in a couple of hours, as it should be.
To keep this blog short we have had to make some claims that we unfortunately can’t provide detailed evidence for here. If you follow the work of Semat (www.semat.org), you will find our claims being supported by facts.
Based on this kernel your team can describe their method in a simpler way than ever before. Even more important than describing their method is that your team will get support in using their method in a real endeavor and they can adapt it as they learn more.
Semat is focused on you – the developer.
In contrast to most previous initiatives, which have attempted to get a grip on software engineering, Semat has recognized that it is the developers who best know how to build (architect, analyze, design, code, test, manage and deploy) software. They can learn from others but eventually it is up to them to select and be responsible for succeeding with their own method. To do this, they need just enough help to know the approach they take is sound.
Now back to our statement that Semat is for you:
Semat helps you become professional
Today almost all developers learn software engineering by example. At school (universities) you learn one or two specific methods. For instance, many universities teach XP, Scrum, and UP today. Other universities are more ambitious trying to teach formal techniques in software engineering. At work you will learn the method used for the project you will participate in.
All of these different approaches are great as examples, but these examples will not give you what you need to know to work better, faster and be happier. Many who have been involved in Semat believe with good reasons that it will be significantly easier to achieve this goal once the essentials of software engineering are widely accepted. Then developers will learn software engineering at its roots. You will learn the kernel. You will also learn how to select practices that are defined on top of the kernel, to create your own method. This is what Semat will help you do. Then you have taken the first steps to achieve your goal.
Semat recognizes that each team involved in developing software has its own method. Semat can help developers make their own method better in multiple ways. Once you as a developer understand the kernel and how to apply it:
– You will be able to easily compare methods. For example, you will learn how to objectively compare Scrum with Kanban, or user stories with use cases, and select what works best in your context to help you get your job done. The kernel helps you to see the differences.
– You will know how your team can improve their existing method by considering new ideas, such as backlog-driven development. Your team’s existing method will be represented on top of the kernel and you will know how to improve by replacing an existing practice with a better one.
– Understanding the kernel will allow you to learn and evaluate new ideas quickly.
– You will easily be able to detect when a new approach is really just a minor variation on an old theme. Because you have a solid understanding of the kernel you will be able to quickly determine whether for instance iterations and sprints are really two different things, or just variations on the same thing.
Even more important is that you will actually get support while you run a software endeavor. You will get more value out of your method than ever before. This is made possible since the kernel includes essential elements prevalent in every software endeavor, such as Requirements and Software System. These elements have states with checklists to ensure you have reached a particular state. The kernel elements progress from state to state as your project progresses over its lifetime. Please do not read “waterfall” into the idea of states – modern software development relies on building a little at a time. Measuring progress is essential to all software endeavors regardless of method. Thus you will get these benefits as well:
– You will be able to plan your work based on your chosen method described on top of the kernel. This comes from the fact that it is your method, which represents what your team actually does. It is not just a description of what someone thinks you should do.
– You will be able to assess the progress of your work more objectively based on the kernel element states and checklists.
The states of the kernel provide a Sat-Nav for software endeavors. By Sat-Nav we mean a system that helps everyone understand where she is and where she is going.
– You will be able to communicate more effectively with your teammates and stakeholders because you will all use a commonly understood and well-defined terminology coming from the kernel.
– You will get standard measurement and reporting because everyone will understand and use the kernel and its well-defined terminology.
– You will, thanks to the kernel, be able to clearly identify when you are really done with what you are doing.
Referring back to the zigzag story of software, the problem isn’t that we haven’t made progress. It isn’t that UML, CMMI and XP are wrong. What is wrong is that over the years as progress has been made we have failed to build our new ideas on a kernel that allows the developer to see precisely what is new, and what isn’t. You should be able to keep what works, and replace what doesn’t work with new and better practices.
Ultimately Semat’s kernel means that you, as a developer, will be able to grow your competency year by year, rather than feeling you are always relearning the same thing over and over when each new idea comes along. This will allow you to confidently move from one team to another or one company to another without worrying that your level of professionalism has been jeopardized just because you are changing jobs. You will no longer feel that you are starting all over just because a new methodology has come along. You will achieve your goal of working better, faster, and being happier, and nothing will ever again be able to take that away from you.