Is software engineering immature?

Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:

"Software engineering is gravely hampered today by immature practices."

If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of  Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:

"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."

So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?

Recurring architectural decisions

A lot of academic (and industrial) research is looking at architectural decisions. One of the ideas pursued is that by capturing and managing this type of information it can be reused. I guess in practice it means that if you need to make a similar decision in the future you can look at what you decided the last time. I myself also saw this as an appealing idea. But today it struck me that we really don't have recurring decisions when we work as architects at Volvo. I think that if we had there would no be any need of an architect at all.

What we do have is a long succession of architectural decisions, each with a new set of prerequisites. The task as an architect is to be able to extrapolate from what has been done previously and still maintain some sort of conceptual integrity. To preserve the "feel" or "vision" of the architecture while still fulfilling necessary functional and quality requirements (including cost) and operate within the constraints given by for example our organisation and what is available/possible form suppliers.

Architectural modelling

To have a more formal definition of what I mean when talking about modelling an architecture (summarised from to IEEE 1471):

An architectural description is organized into one or more views.
A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view.

I am not against using models to represent architectural views, but there are some fallacies that often seem to happen when using various modelling approaches in architecture descriptions.

• The purpose of the architecture model is unclear (in 1471-terminology: It is not obvious what concerns the model addresses). UML is especially problematic since it provides notation that can be used for so many purposes. Read John Daniels paper Modeling with a Sense of Purpose as an introduction.
• Everything is modelled to the same level of detail. Not everything is equally important to know. For some parts of the system it is important for the architecture (and realisation of qualities) to know the details, for other parts it is not.
• Every part of the system must be represented in the architecture, for example if every class must be traceable from some element in the architecture. This could even be a rule of the architecture, "if it is not explicitly allowed it is forbidden". This reeks very much of waterfall mindset with the architects doing much of the design before any developers get involved. I think it is presumptuous  of the architects to claim to know everything that needs to be implemented.
• Modelling tools always demands a precision in notation, which is not always desirable when sketching an architecture. You cannot model "sort of a class", or "could be a function" when using a tool, which is possible on a whiteboard or a napkin. In a tool it has to be a class, a function or a package, not something in-between.

Architecture for small systems?

It is Friday afternoon and I'm allowed to have some wild ideas...

After a long e-mail conversation with one student of appropriate architectural styles to use in a project course I realised that his ending comment is spot on:

I think the course and it's literature are focused on large systems and seeing that we are new to this, especially with a new language in parallel, its difficult to not apply what we learn during the course.

In my opinion the patterns covered in the book left me half way with the idea that most architectures could fit into a pattern, within its own right.

I have been too blind when I teach, and not even my professional experience helped me to identify the problem:

Most (all) literature about architecture teaches solutions for big systems.

Is there a niche for information on how to architect small systems? Small in the sense of not having millions lines of code, or a large development team, or a long project. I know that the agile manifesto states that that one of twelve important principles are

The best architectures, requirements, and designs emerge from self-organizing teams.

But do a google search on "agile architecture emerge" and see what comes up, a lot of interesting reading that suggest that the issue is not that simple.

A lot of software systems are small, from a bittorrent client (the student project) to the software in the door control unit in a car, to a mobile app. And yet they would all benefit of having some though about what they must meet for non-functional needs that is addressed by a (simple) architecture. Should I write a book on architecting small systems? So that a team member is better prepared when he or she participates in a small project where the architecture "emerges"? You don't need to be an architect to benefit from doing thinking at an architectural "level".

Quality attribute scenarios

Defining a quality attribute, a.k.a. non-functional requirement, is not easy. I know since i did that for a new platform at Volvo. When the verification and validation group comes back and says that it is not possible to verify this as a requirement I can only assume that I did not do a good enough job. But I have to agree with what George Fairbanks wrote in his blog:

Before you get too excited, you should know it’s easier to write these for quantitatively measurable qualities (e.g., throughput, latency) and harder for softer qualities (e.g., modifiability, usability).

There are two recent books that have a more agile approach to architecting: Lean Software Architecture by Coplien and Bjørnvig, and George Fairbanks' Just Enough Software Architecture: A Risk-Driven Approach. Unfortunately the latter isn't available in any Swedish internet bookstore, but as soon as I get hold of them I will post a review, as I have reviewed other books on software architecture.

How attractive it is to work as a software architect...

A colleague sent me this link from CNN Money about how attractive it is to work as a software architect. Go figure...

Hidden leaves

Philippe Kruchten wrote a very entertaining interpretation of Tao Te Ching from the perspective of an software architect. But besides being entertaining it has some very good insights into the nature of an architect, like the following:

The architect doesn't talk, she acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!"

Personally I'm more familiar with Japanese texts (more than 20 years of budo training) so I thought of interpreting the Hagakure with the same perspective (you can find a translation to English of the original text here).

Among the maxims on the architect's wall there was this one: "Matters of great concern should be treated lightly." A senior developer commented "Matters of small concern should be treated seriously." In one's project there should not be more than two or three matters of what one could call great concern. If these are deliberated upon during ordinary times, they can be understood. Thinking about things previously and then handling them lightly when the time comes is what this is all about. To face a problem and solve it lightly is difficult if you are not prepared beforehand , and there will always be uncertainty in hitting your mark. However, if the foundation is laid previously, you can think of the saying, "Matters of great concern should be treated lightly," as your own basis for action. (1st chapter, p. 33)

According to a senior developer, even a poor programmer will become substantial in the art of writing code if he studies by imitating a good model and puts forth effort. An architect should become substantial too, if he takes a good architect as his model. (1st chapter, p. 40)

The proper manner of architecting is nothing other than not being careless, but in this way one's design will be sluggish and stiff. One should go beyond this and depart from the norm. This principle applies to all things. (1st chapter, p. 48).

In carefully scrutinising the projects of the past, we find that there are many different opinions about them, and that there are some things that are quite unclear. It is better to regard such things as unknowable. An architect once said, "As for the things we don't understand, there are ways of understanding them. Furthermore, there are some things we understand just naturally, and again some that we can't understand no matter how hard we try. This is interesting."
This is very profound. It is natural that one cannot understand deep and hidden things. Those things that are easily understood are rather shallow. (1st chapter, p. 69)

Software quality attributes

I got the following e-mail from a student after discussing definitions and frameworks of quality attributes:

Hello,

It seems there are 2 main groups of ISO standards dealing with software quality:

1. a 4 part ISO 9126 standard (QA considered are reliability, usability, efficiency, maintainability, portability AND, actually, functionality)
2. second generation of ISO software quality standards referred to as SQuaRE (Software product Quality Requirements and Evaluation): ISO/IEC 25000:2005, ISO/IEC TR 25021:2007 and ISO/IEC TR 25060:2010.

I couldn't find any free copies of these standards, so we can't really use them.

Anyway, it would be interesting to get during the lectures some additional information about different quality attributes models out there (early McCall and Boehm models, FURPS, ISO models etc.).

I replied with this:

You are correct. You can't access the ISO standards (without paying).

• For a very soft introduction to quality attributes, read this: http://www.stellman-greene.com/2009/10/03/using-nonfunctional-requirements/
• An in-depth analysis of a few quality attributes are available at http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm
• For a definition of terminology I suggest IEEE std 610.12, bit this covers much(!) more than just quality attributes. It is available at http://ieeexplore.ieee.org/
• You can also read what the PhD students at Blekinge Technical University wrote down in a course about software quality: http://www.bth.se/tek/besq.nsf/pages/017bd879b7c9165dc12570680047aae2!OpenDocument
• And as usual, wikipedia is a good introduction, look at "software quality" or "FURPS" for example.

I think it will be a little too much to go into detail about different quality frameworks in this course, above they dedicated an entire course at PhD level to the subject.

Hope this helps,

Ulrik

Why I don't like formal methods...

I know the title of this port is a bit controversial and with it I alienate a lot of researchers, even at my own department. But I will try to clarify my arguments and hope that someone can prove them to be wrong.

• To be more precise; it is not the formal methods in itself I dislike, but the prominence they seem to have at prestigious software engineering conferences. I think it is not at all in proportion to how well-used formal methods are among professional development.
• Formal methods are really attractive from a researchers perspective. You can use concepts as theorem, proof and deduction and other nice things. But nice is not the same as relevant.
• Even though I have heard about formal methods as one of the enablers to establish software engineering as a "real" engineering discipline for almost ten years I still don't think they are nearer being well-established now than then.
• Some claim that you can never be sure of the software unless you can prove properties about it, and I agree that presently formal methods are the only technique that promises to do so. But there is a lot of successful software out there which have not been proven.
• Specifications that fulfil the requirement of being interpreted formally are hard to write. Compare it to learn a new programming language and be proficient enough to use it without any side effects.
• I don't know if formal methods scale well. It is one thing to use it on a nice prototype system with 30 entities developed in your lab. It is another thing to use it on a system with 500 entities, many of these with quite varying quality in requirements and code.
• I still don't know of any that uses formal methods for real; i.e. as part of the normal way in products shipped to customers in business intent on making money. Not in one-shot attempts, pilot projects or by non-profit organisations.
  A search on google skolar of industrial+software+formal+methods list papers from the 90s as the top results. And these seem more to be arguments against what I claim above rather than actual reports of usage. I really would welcome examples.

Tacit knowledge

At the ECSA conference there was a lot of talk about tacit knowledge and the importance of tacit knowledge when architecting systems.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.

Concurrent architecture

To continue my thoughts about the programming language Erlang and especially how an architecture for a system implemented in Erlang would look like...

Joe Armstrong's PhD Thesis provides a very good understanding of the basic principles of Erlang. I think that some of the mechanism in the language makes several pattens in Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects unnecessary.

I think it would be quite useful to describe the architecture in views. I think the "standard" 4+1 views could be used quite easy for a system implemented in Erlang as well.
However it may not be the logical view that the other views are derived from, rather I would think that the process view would be the basic view. Kruchten has an underlying assumption that the logical view is object-oriented. This is obviously not relevant for a system implemented in Erlang so a different notion of the logical view is necessary.

Joe Armstrong strongly suggest a hierarchy of processes. A problem domain model could be a good way to identify the top-level processes, e.g. the PDM classes could be the initial processes and the asynchronous interaction will be implemented as messages, since reality is asynchronous. I need to try this in practice though...

More books on architecture

I previously wrote about some textbooks about software architecture. I have have since received three more books.

The first, Software Architecture: Foundations, Theory, and Practice, I disregarded fairly quickly. I think it is too verbose (712 pages!). I could not find the brevity and clarity I think a good textbook should have to should support understanding instead of overwhelming the reader with facts.

I have not had the time to read through The Art of Software Architecture: Design Methods and Techniques yet, it arrived today in the mail.

Software Architecture and Design Illuminated covers a number of different types or styles of architectures, and does so in a manner familiar to the students at SE & M (i.e. in UML models and in Java code examples). It takes a completely different approach to quality attributes compared to Software Architecture in Practice (SAiP), it is structured according to different architectural designs and explains what they are good and bad at. So rather by learning by reason about concepts if focuses on learning by examples. This means that the coverage of quality attributes and tactics is not as comprehensive as in SAiP, for example attributes and tactics related to embedded systems are lacking in comparison since there are few examples of those in the book.
However since the course presently is structured according to theory and not examples of different types of architectures it would require more update of the course compared to the other texts.
The book also has some on-line material for instructors which I have not yet been evaluated.
Summary: Good book which I think presently is the best undergraduate book out there. I like the example-based approach, but it might just be appealing to me because of the fresh approach to an already familiar subject.

On variants...

During my research I gained some inside information into how various automotive manufacturers work. One very interesting observation is to see how different companies approach variants.

I know of two high-end companies having as a general architectural strategy not to have variants of systems or ECUs. Note that the electrical system as a whole may me different due to e.g. feature content, but if the system has a body control module there only exist one variant of that module both in development and manufacturing. To my understanding they are only using the optional variant in F. Bachmann and L. Bass, "Managing variability in software architectures," SIGSOFT Software Engineering Notes, vol. 26, 2001, pp. 126-132, and not any of the other types.

Personally I think that this is very beneficial for a company, both from an engineering and from a manufacturing perspective, even if it seems wasteful not to cost-optimise an ECU.

But this strategy is probably not for everyone. There are some common characteristics between these two companies:

• The are both high-end brands and have customers that can afford to buy the best.
• They are not mass producers, only in the order of 100k vehicles per year. This means that development costs are not negligible to article cost, even if they are smaller.
• Tailoring to the customer needs is an important business strategy.
• The have unusually high ROI compared to the average for the automotive industry. Being successful is another way of describing it.

And no, Volvo Cars is not one of the two companies...

The question is how you "dare" to go for such an architectural strategy if you are not already doing it? I think developing a business case to show that you would earn more $$$ with such a strategy would be extremely difficult.

Fallacies towards lean architecting

If architecting is seen as an effort on which you can spend more or less resources with a better or worse result I wonder how you identify the trade-off where you get the "most bang for the buck"?

I think this is a fundamental question to ask if one discusses architecture from a lean perspective. To use the standard lean criteria, to eliminate everything that does not contribute to end-customer value, disregards several important (?) quality attributes of an software architecture. One could argue that a product line approach benefits the end-customer, but to be honest I think it is the developing (creating?) organisation that reaps the main part of any benefits.

What are some fallacies that would detract from the most efficient architecture? A personal list would be something like this:

• Completeness of the architecture - To aim for an architecture that describes 100% of the system at some abstraction level is not efficient. I don't think I need to detail this argument besides Pareto's law.


• Formality - Strictness in describing the views may hinder the stakeholders' understanding of their concerns. To much effort on defining and/or understanding modelling rules is not efficient.


• Detail - An architecture is a top level design, and I would put an emphasis here on top-level. It should not bother with details best left to other tasks (and stakeholders)


• Traceability - To require traceability to all requirements that affect the design of an architecture and traceability from all requirements resulting from architectural decisions is not efficient. On the other hand to have no traceability is not efficient either.
  There should be enough to convince the stakeholders that vital concerns have been addressed. So it basically is the stakeholders that define the necessary level. Note that very rigorous stakeholder may completely big down an architect with demands on traceability...

I would like to expand these thoughts in a more rigorous way, enough to present at some workshop, or at least have more discussions with researchers and practitioners. I'm still waiting for the book by Coplien and Bjørnvig.

Some more thoughts on agility and architecture

This is a quote from Grady Booch's blog:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

One interpretation I can make of this quote is that it seems to be an inherent contradiction in aiming for agility in the design decisions that constitutes the architecture. Architecture is those decision that you don't want to change since it is costly to do so (in $$$, man hours or lead-time). But this is not the same as making those decisions up-front.
Maybe a lean approach is what benefits agile development the most:

...an architect should make as few decisions as possible, deferring the rest until later in the lifecycle.

Tyree and Akermann in IEEE Software 22(2), 2005, pp. 19-27.

SEI has a webinar 22 April about Agile Development & Software Architecture. Maybe that can shed some more lights on how to reconcile architecture and agility. To bad they are broadcasting it at such an awkward time for us in Europe.

Is software a product of creativity? Or?

I think the phrase "development process", or rather the concept of development as a process has become a paradigm in software. A google search on software development process results in 724 000 000 hits!

The view of creating software is done through a "development process" is so established, at least in the software industry, that no-one seem to question if this is a valid view on how to design stuff. This regardless if one talks about waterfall, spiral, agile or lean.

Since I am not a native English speaker it could be a lack understanding the connotation of the words, but I'll try to explain what I mean.

First, software is developed. No-one talks about a software creation process. To me development is more akin to refinement, exploitation or progress. I think software is created, it is one of the very few intellectual pursuits besides the arts where something is created from nothing.

Second, the development (or creation) is done through a process, something which in an engineering perspective means that by combining the right inputs and having the right circumstances, a desired output is achieved. And the process is repeatable as long as the inputs and circumstances are the same. I don't think anyone disagrees when I say that not two software projects are alike, regardless how similar one tries to keep the process.

So the question is how should we view software creation? I think it would be helpful to see it as a creative endeavour similar to what a writer does. There is usually some idea of what the end result should be, but that may or may not be very detailed when starting to make sentences. Some write in a very linear fashion, starting with the first chapter. Some start with an outline which gets more and more refined until it actually is the full text. Some writers are very disciplined and can write for 8 hours day, some can just write when they are inspired. And everybody has heard about "writer's block"...

If software is not developed in a process, but seen as a work of creativity I think efforts should be to make the people writing software as creative as possible (and therefore also productive). Maybe this can be used as a "lean" principle on how to manage a software project.

Is an archtiecture description always necessary?

I wrote in an earlier post about the importance of being able to write in a concise manner, based on the assumption that key issue for an architecture description is to convey an common understanding of the architecture (more on the validity of that assumption later in the blog).

What would happen if that line of thought is taken to it's extreme, i.e. nothing is written down about the architecture? How would one reach a degree of understanding among the team members? And especially a common understanding? Does it even need to be common?

Answering these questions could easily expand to an entire literature review of organisational learning and I'll try to avoid that. But an architecture description is a way to convert the tacit or internal knowledge (of the architects?) to explicit knowledge which in turn other stakeholders can internalise again. The question is of this transfer of knowledge can be spread through the organisation by other means?
I certainly think so, the same way I learned about electrical system in vehicles "on the job" rather than learning from books, but this requires working side by side on a recurring (daily?) basis. Feasible if the team is co-located in the same room, but it does not really scale if the desks are to far apart. One architect and 15 other developers is not a problem. One architect and 200 other developers is a problem.
I have a gut feel that this is related to how well agile practices scale to big projects...

After reading this post I realised I made an assumption that the architect is the main person having the knowledge about the architecture. Of course this must not always be the case. One alternative is the committe architectures I wrote about earlier, but there of course must exist other alternatives...

Committe architectures

I have observed that sometimes an architecture tends to get defined by a committee of all stakeholders (or representatives for them) rather than an architecture team. This in itself may not be bad but there are some things that seems to happen when this is the case:
First the architecture tends to be defined by a set of separate decisions that solves separate problems the stakeholders have. There is no overall vision of what the architecture should be. A lack of what Frederick P. Brooks call conceptual integrity.
Second the balancing of quality attributes seem to be an average of everything. The architecture is not really good on anything (maintainability comes to mind). On the other hand no quality attribute seems to be totally forgotten or neglected.
Third the description of the architecture is done at low level, e.g. a design or implementation level because this is what a majority of stakeholders are used to in doing their usual work.

Object-oriented programming in C

In the automotive industry C is the totally dominating programming language. I guess this is because of the limited resources in automotive-specific CPUs but also because of tradition among programmers, if you have a program that is proven by use you don't rewrite that just because there is some new language around.
And to be honest, it still is hard to beat C if you want real-time properties and a garbage collection that don't risk overflowing memory.

But if you want to keep C but write programs in a more object-oriented style how do you do? It is not as hard as one would think.
Here are some web pages which give some useful tips. Note that they are not always compatible!

• Phil's guide to object-oriented ANSI C
• Object-oriented programming in C by Paul Field
• Object-oriented programming in ANSI- C by Axel-Tobias Schreiner

I have reviewed code for several ECUs used in Volvo cars, and none have used an object-oriented style. The reason I bring up object-oriented programming in C in this blog is that it simplifies the implementation of many patterns, the subject is not really new...

Documenting and Presenting Architectures

Some interesting blog posts (and other links) about documenting and presenting architectures:

Architecture Documentation: Courage to Fly in the Face of Convention
Top Ten Tips for Presenting Architecture Information
All about IEEE 1471

A notice that puts my blog on a Swedish geographical blog map: Jag har placerat min blogg på Lindholmen på bloggkartan.se!