Keeping it in one’s head

A friend of mine recommended this text on why programmers work at night. Entertaining but still true.

But the blog post referenced  another interesting text written by Paul Graham about the necessity of holding a program in one’s head to be an outstanding programmer. I couldn’t agree more with that he says. I also agree with the corollaries that it is detrimental to treat developers as interchangeable parts in an organisation.

But what got me thinking was the fact that an architect must keep an entire system in the head. Where the programmer has the code as something tangible to base this mental model upon the architect has at best an abstract model and at worst only her own internal representation.
So for an architecture to be successful it both seems to be necessary that there is somebody who has the ability to internalise and reason about an entire system, and that the mental representation is possible to grasp in it’s entirety with (at least) one single mind. There are probably a lot of systems out there that fulfils neither….

More on-line lectures on software architecture

I was discussing with one of my colleagues at the department if there were any introductory or summary presentations on-line about software architecture. I have already listed some on-line lectures about software archtiecture in the blog, but a quick search revelad some interesting ones:

• An Introduction to Software Architecture and the Risk-Centric Model by George Fairbanks. George is a an excellent lecturer and has written one of the best books available on software architecture. If you have the oportunity to discuss with him, take it. Too bad the sound is so bad in this video clip.
• Conscious Software Development: Architecture with Jeff Mckenna. Why not look through all parts in the series while you are at it?
• Software Architecture Document by Philippe Back. I don't know who this guy is, but he manages to convey a lot of essentials in 12 minutes
• SEI has a number of webinars related to software architecture. Unfortunately I can't get them to play on my computer, maybe you can?
• Out and About: Software Architecture with Simon Brown. A short clip with a view on what a developer needs to do to be an architect.
• Considering a Software Architect Career by Marc Ferrentino. A very short clip on what skills you need if becoming an architect.

Set-based architecture

I listened to a presentation from Durward K. Sobek II about set-based concurrent engineering, which is a development paradigm(?) from lean development (more precisely from Toyota Product Development System).

The original principle, as I understand it, is that a designer should work with a set of design proposals towards manufacturing and in the dialogue between what is desirable (form engineering) to what is possible (from manufacturing) iteratively narrow it down to a single design. He concluded the presentation with how one would start with this in the small and the advice was to present two designs instead of a single one the next time

It made me thinking about how an architecture is “presented” to the stakeholders, especially the developers. would it be possible to present two architecture proposals to developers and let them identify the constraints from their perspective in narrowing it down to a single, agreed, architecture.

The angry programmer?

My wife thinks I should start another blog named "Ulriks programming nightmares". Or maybe just add another topic of this blog where I mention examples of programmed systems that aren't good. Or to be more precise, where the programmer was too lazy to do a good job, which really gets me going. Unfortunately I get upset when I see it among the students which is a bit harsh, they are here to learn after all.
The examples I have seen so far is everything from the logic of the elevators at the university to how the booking system of SJ places people at a train. Seriously, if there are 3 reserved seats in a wagon, why must two of them be next to each other?
Enough ranting, but is this a good idea to expand the topic of the blog with? Coming to think of it, there must already be sites like that out there. If not there should be, it is always more educational to learn from bad examples than good.

Documentation

When it comes to documentation I am firm believer in the quote of Antoine de Saint-Exupery:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

As I see it there are a few main purposes of producing documentation:

To convey understanding - This shows my quite liberal view of documentation since I consider drawings on a white board or a napkin to be documentation. But I also consider this to be one of the most important purposes of documenting things. From a designer’s viewpoint these “documents” are vital in going from an inner vision to an operational image that can be shared by others. Common examples of documentation conveying understanding in large organisations are presentations given at various meetings. These documents can be saved for posterity, but the ability to convey understanding is much smaller for those who weren’t there. On the other hand are written documents one of the most efficient means through history to build on knowledge of others which you never had the opportunity to meet.

To formalise agreements – If there is a business agreement between two organisations it is almost inevitable not to have a more formal document detailing the technical content of the agreement, the specification. many organisations, including my own, also use documents to formalise the agreement between internal teams. Your mileage may vary how efficient this is in various organisation.

To preserve information – The human memory is not infallible. Documentation is a great support to minimise the decay that is inevitable when only relying on the human mind. Software is also about maintenance and any body who has been given the responsibility to update legacy code that is undocumented know how difficult it is (this scenario includes the purpose of understanding as well)

I don’t buy “the code is the documentation” at all. The code by itself does not fulfil any of the purposes above.

I have recently worked in a project which solely relied on Trac to capture all information relevant to the project (except finances). I am positively surprised how much you can achieve with so little formal documentation in combination with having everything in the same place available for everybody in the project. I will try to do a more formal evaluation according to the purposes above when the project is near it’s end.

When to decide?

I have recently experienced several occasions where people want to decide things as early as possible in a project. This seems to be based on previous experiences that this was difficult in the last project and we want to eliminate things to worry about late in the project since there will be new things to worry about then anyway. So why not solve the major problems you are aware about anyway?

I think this kind of thinking is detrimental for the success of the project, especially if the decision influences the architecture (Grady Booch said something like "the architectural decisions are those costly to change").
If one looks at the reason the problems came up in the first place it is usually things like the implications (especially technical) of the decisions was not fully understood, the requirements were not suitable, or my personal nightmare that my team will not suffer any consequences whatever the outcome so why not decide this now...

If one has superficial understanding of the consequences or if the requirements are unstable it is a better strategy to postpone the decision as late as possible, and also delegate it to those who are most affected/concerned. But this means you and your organisation is comfortable with living with uncertainty. Which may be very difficult depending on the culture or the organisation. For example if all of your project revolves around a stage-gate process (very common in the automotive industry) it really does not fly well to say "let's postpone this decision for another 6 months and make progress with what we can".

It may sound I ampreaching the agility gospel, but that is not the case. I have full understanding that once you have made an architectural decision you don't want to change it. I just want to argue for the heuristic that you should not decide something because you can, postpone it to when you have make it.
And as a consequence I really dislike when you have to decide things just to feed the process, especially if the process is very slow to change.

WICSA 2011

I was at WICSA last week. I am a lousy trendspotter, but here is what I have seen as “trends” so far:

There seems to be several efforts, especially on the tool side, that focuses on capturing and navigating architectural information. Is this a sign that architecture information is getting bigger and bigger and is distributed among different sources/artefacts? I thought one of the tangible deliverables from an architect was a comprehensive documentation/model/wiki/whatever with architecture information. As a contrast there wa a tutorial the last day by George Fairbanks on writing a 1-page architecture document. I would say this was a highlight of the conference, to bad most people had gone home by then.

In general it seems architects are more aware of the need to adopt to agile development. I don’t think there is any contradiction, contrary I believe that it is necessary for agile developers to be more aware of “architectural thinking” and what benefits there is of having an explicitly defined architecture. But I do agree that often architecture is the same as Big Upfront Design. At the panel debate I understood better the historical background; many of the originators of the agile manifesto were active developers already in the late eighties and nineties when a lot of focus where on software design. people who started as developers in the last decade don’t have that background and think that the last years focus on process is all that is necessary for developing good software.

There was some discussions  on architecture-based testing (this is a good strategy to define a new research area, combine two or more buzzwords), but it was confusing. some people seemed to mean an architecture where it was easy to verify the quality attributes it was designed to achieve. others seemed to mean an architecture for a systems that was easy to test for testers. I like the latter better, and hope there will emerge more patterns for this than the general patterns of encapsulation etc.

Compared to the last WICSA in 2009 I think the acceptance rate was much higher, above 40%. I think this could be one explanation to why some papers had a rather weak scientific methodology. One other thing I did not like at all were some studies based on industrial practice where the results were too polished. if you present a case study you should include all the small (and big) problems that occur in real settings, otherwise the cases are not of more interest than textbook examples.

Reference architecture, what is it?

I am at WICSA 2011 and the words “reference architecture” come up now and then in discussions. I am not sure I like the definition in Wikipedia, I think relies too much that you already have knowledge or experience of a reference architecture.
One simile (parable?) would be to a building code, a set or rules that underlie the actual architecture and construction of a house. The architect is free to build any type of house, as long as the code is adhered to.
But I like to use cooking as an example. A recipe is like an architecture, when you actually cooks the recipe and serve it is the implementation of software. You need to do certain things that are implementation specific, like tasting to see if the amount of salt suits your taste etc, and maybe you need to double all the ingredients to fit your  dinner party.
Julia Child writes in her book Mastering the Art of French Cooking that there are 6 principal ways to make a sauce, one being an emulsion of melted butter with egg yolks, which is common the common method for béarnaise, hollandaise and choron sauces. The type of emulsion is similar to a pattern while the three different recipes are designs.
For a restaurant; a product line architecture would be the menu they have based on the ingredients they stock, for example chicken could be used in more than one dish.
So what is a reference architecture for a restaurant? It would be the “rules” that guides and controls what is possible or desirable. It could be for example driven by the business domain, e.g. it should focus on French or Hunan cuisine. Woking as a “development method” would not be relevant in the former, but certainly in the latter.
Or it could be driven what is technically possible, e.g if the kitchen has no deep fryer it is impossible to for example make french fries.
Or there could be other restrictions, such a desire to only use locally produced ingredients.
Maybe I went to far with this simile (parable)?

Architectural views in practice

My research is not really focused on identifying the “best” architectural views for in-vehicle software. But as a side effect to the studies I am presently doing I got to think about three views that could actually make a difference in how well large projects succeeds (or fails). I have thought about the need of addiitonal views, but cannot think of an immediate need of more.

Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.

The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.

The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.

What is a "good" architecture?

Hopefully you recognise it when you see it...

I believe every system has an architecture, documented or not, and intended or not. So I think it is reasonable to discuss if the architecture of a system is good or not, and that the question if the architecture description is good is a different, but related question.

So what criteria could you use to establish if an architecture is good? Is it suitable for it's purpose is a more precise question? But this probably differs depending on the stakeholder, a system could be very nice and intuitive for the user, but very difficult to develop and maintain for the developers. In the rest of this blog post I will writing about goodness from a developer perspective (including the architect, if one is involved).

I think there are different levels of how well the architecture suits it's purpose to guide and control the implementation.

The ideal level is where the developer understands the architecture and following the architecture is the obvious way to implement something. Doing it differently is seen as more difficult and less elegant.

The next level is where the developer understands the architecture, is able to follow it on her own and can evaluate if the implementation follows the architecture or not. The developer also understands the "debt" that would occur if she deviates from the architecture, for example in terms of compromising some quality attributes. At both this and the previous level the developer can contribute to the design of the architecture itself, and an appointed architect doing the design may not always be necessary.

The developer may need continuous support from the architect to be able to understand the architecture when working. This is very common and requires more work and puts limits on the the ratio between the number of architects and developers in large projects.

The worst level is where the developer cannot understand the architecture and the only one that can determine if the implementation follows the architecture is the architect by reviews. This is very work intensive on the part of the architect. The architect is also viewed as a police that interferes with the developers rather than supporting them.

I have worked at all this four levels in various projects, and I think that you need to be on the upper two if you talk about a good architecture from a developer perspective. I also think that if you want to be truly agile in a self-organising team it is at the two top levels you nee to be.

You tend to favour the solutions you are familliar with...

When I talk to students about the role of the architect I always make a point of the architect must know when not to use a particular solution/pattern/style (the old "Kill your darlings"). Regardless of this I have seen examples when an entire class thinks that a 3-tier architecture is the best solution in a project because they took a course on databases the previous semester.
Likewise, when I talked about component-based architectures in a lecture and gave examples based on AUTOSAR, a lot of students thought that components was the thing, even if it complicated the solution for the developers and the benefits with components was not really relevant in the student  project.

This is not surprising since I am talking about students with limited experience to various problems encountered when developing real systems. But I also think this is a problem for professional developers as well, including myself. We tend to stick to what we know and don't reflect if what we know actually makes things worse than better.

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.