Is software engineering research relevant?

I try do be a software engineering researcher. If I scrutinise myself I am an engineer, not a researcher, and a systems engineer on top of that (but with a clear focus on software-intensive systems).

While trying to finish my thesis I often question if I investigate relevant problems from an industrial perspective, which I believe is the only valid perspective in software engineering, everything else is just playing around. Since software development is a completely artificial activity there are not natural phenomena to study, everything is the result of human activity (and ingenuity).

After attending my latest conference, which had a mix of industrial presenters (probably not peer reviewed) and academic presenters (peer-reviewed, of which I was one) I discussed with a colleague. The conclusion we reached was that the academic researchers had a lot of substance in their presentations, but lacked relevance, while the industry presenters had relevant topics, but lacked substance. The latter seemed in many cases more like a sales pitch.
I have also heard in panel debates at other conferences that software research are diverging from industry needs. This is serious! But what is the problem? Are researchers really addressing the wrong thing (I have already complained about formal methods research)? Or is the step from a published research paper to implement it beyond a simplified academic setting too large for practitioners to take? Or are there so many conflicting research "results" that it is impossible to draw any conclusions as a practitioner beyond personal heuristics? In structural mechanics there are the laws of physics that constrain what is working or not, in software there is no clear boundary like that.
Personally I believe it is the gap, it is just not possible for practitioners to grasp how the results are relevant in their context since research is trying to be as general as possible, i.e. trying to cover as many contexts as possible and in the end not being relevant for any context. Resarch results only valid in a specific context (e.g. a deep case study) are considered second-rate by the research community and often does not pass through the eye of the needle.
There are many different views on the relevance, for example read this report on the future of software engineering research.

What can be copyrighted?

Since taking the course on Ethics and Intellectual Property at Chalmers I have become increasinlgy interested in how copyright and patent laws affect software development. United States of America have different patent laws compared to western Europe, usually more obliging of what can be patented, but the legal rulings in the former concern also software used in the latter.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.

Watch an interesting film about the american patent system and software patents: Patent absurdity.

Where does a good S/W design come from

One of the 12 principles behind the agile manifesto says

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

I have seen cases where I think some teams interpret this as good architecture emerges by itself as long as you follow good practices, e.g. XP, TDD, Scrum, etc. Caveat: I haven’t asked them…
This does not happen in reality. I have experienced colleagues who calls this a “manifested architecture” (every system has an architecture, deliberate or not), in a quite derogatory manner. The common problem with a manifested architecture is that it may fulfil all functional requirements (user stories, features, use cases, …) but does not really support any key quality attributes.
Good design, at all levels, are based on a vision of what the system should be, in terms of functionality/properties and structure. In a self-organised team this is hopefully a shared vision. You can appoint a single person to capture and disseminate this vision (commonly known as an architect), or you can use other principles to define and share the vision. The latter is my positive interpretation of the agile principle above. But you don't hope it happens without concious effort and don't do anything about it...
So how do you learn good design? The best (only) way to do this is to look at other good designs, with as much detail as available. This provides the “type of context dependent knowledge that research on learning shows to be necessary to allow people to develop from rule-based beginners to virtuoso experts”. (Bent Flyvbjerg)

Is there any use of the V-model?

I’m at the 13th International Conference on Agile Software Development in Malmö Sweden. As usual when I listen to presentations these tend to trigger new liner of thoughts instead of pondering the details of what was said. I guess this is a flaw in how I internalise knowledge from others.
Not surprising, nobody here mentioned the V-model. Too bad,since I think it is one of the most important metaphors regarding software (and system) development there is. But it is also on of the metaphors that have been used in ways which are completely inappropriate.
My “condensed understanding” of the strengths of the V-model is this:
It defines a set of activities on the left side of the V with associated artefacts aimed at exploring the problem and detailing the solution down to the actual product (the code!). The important part is that these design activities have corresponding activities of verification & validation on the right hand side of the V, in a one-to-one relationship between the design and V&V activity. The number of levels is individual, but usually about 3-5, including code is reasonable.
Where it goes wrong is when the V is laid out in time as a template for progress of a project. This may make sense if you are designing for manufacturing-heavy products, but is useless for software, the time between understanding the problem (top-left part of the V) and where you verify that your understanding is correct is just way too long to be competitive. This is definitely not news for software developers, and is a key point in agile software development (but probably phrased differently).
But it seems to me that in order to optimise the efficiency and speed there is a tendency to downplay the activities above the point of the V ( the working code). Big-upfront-design is seen as such a bad thing that it ends up in no design at all, there is a direct jump between formulating the problem (e.g. user stories) and start coding.
I believe that in an agile project all activities in a V must be executed in each sprint in order to claim to be “truly agile”. Each sprint means a better understanding the problem, a better design to solve it, and a better implementation in the code. Of course all of these are verified and validated. That does not say that these activates are equally large, or the size of the V is the same in alls sprints, but if you leave out the conscious architecture in the sprints you don’t learn to do better in the next sprints.
You should design the activities in the V to provide the maximum added value with respect to the spent effort, which obviously depends on thousands of context-specific factors), but saying they are irrelevant is only reasonable for the simplest of systems, where you have a definition of the problem and code.
Personally I rather define the result of the activities, i.e.the artefacts, and let the teams decide themselves on how to populate them. I know blog readers may cry about excessive documentation, but what I am talking about is the necessity to externalise  information necessary to share between developers, and teams, and to preserve this information over time, something which code never can do.
Long rant, and I’m not even close the exhausting my thoughts on the subject….

Concrete vs. abstract and detail vs. overview...

There often seems to be confusion about two concepts relevant to representing design information, including models.
First there is the scale of abstract versus concrete. Second there is the concept of overview versus details.

If one looks at how a design progresses over time, regardless if one follows a waterfall or agile process, one moves both from abstract to concrete and from overview to details, but they are not the same thing. And I think that agile and waterfall puts different emphasis on on to make these transisions, and where to start and end (topic for another blog post!)


Going from overview to details is simple, the more you know about the problem and the solution the more information is added. think of going from a sketch where you only elaborated on the key classes to understand the system to a class diagam with all classes that are implemented. Using a map as analogy; you increase the scale to see more details, the coastline gets more details, or you see all roads and not only the big ones.

Going from abstract to concrete is also about adding details, and I think that is where the confusion begins. But the details that are added are not of the same type as in the more abstract representation. Here it could be adding all attributes of classes or ports to components. You don't get this information by adding more classes or structure components. In the map analogy it would mean adding indvidual houses on a map which previously only had roads, lakes and forests. It is a new type of information which you cannot deduct (transform) from the more abstract representation.

Testing

I have to admit that I know too little about software testing in practice to be a well-rounded software developer. That does not mean that I am adverse to testing, on the contrary I think that many architecture focus on properties discernible by the end user and not the developers where testers are a key developer role.
So I am curios if there are any patterns on how to design a testable architecture.

I enjoy the blog thoughts from the test eye, which also has a blog roll if you want to explore further test blogs.
I also stumbled across a very good powerpoint summary about testing in industrial settings from Lappeenranta University of Technology.

Quality starts with me

Outside the main dining hall at Volvo Cars R&D headquarters there is some information about ongoing quality work under the heading "Quality starts with me". A quick google search shows this sentence is not something unique to Volvo Cars, but it got me thinking.
To start with: For software (or any product I guess) quality can be seen from to viewpoints:

1. Free from defects
2. Appropriate according to the needs of the user

In many cases one obviously wants to achieve both these objectives, but the actions to reach them vary. Bad case is when one uses an action/method/principle that supports the first objective while believing it is the second one.
Let's say that I review a software specification if all requirements are SMART requirements (insert alternative acronym if desired). Does this support quality of type 1 or 2 above?

When it comes to reviewing or auditing I think it can be applied towards both objectives above, but it requires a lot more of the reviewer if it is the second objective that is the goal of the audit.

Writing user stories

The blog is updated very seldom nowadays. It is not because I have lost interst, it is just that I write scientific articles with an unprecedented speed in parallel with doing improvement work at Volvo.

I just wanted to put in a reminder of how you define a user story (e.g. for use in a Scrum backlog), shamelessly stolen from a presentation by Dean Leffingwell:

As a <role>
I can <activity>
So that <business value>

"As a Gmail user, I can select and highlight a conversation for further action"

Lean in retailing

Gekås Ullared is the biggest retail store in Sweden, with a turnover of 3.4 billion SEK (about $450 million USD). They are renowned for their low prices, though their business idea is to facilitate a shopping experience (i.e. the customers shall feel they made a great deal). Note that they only have a single store in the middle of nowhere with 1100 employees, I'm not talking about a chain of stores here.

I think Gekås is one of the businesses in Sweden with the most lean mindset. I have no idea if they have studied a lot of Japanese companies (or Wal-Mart), but they embody a lot of key lean elements in their business:

• The experience as a customer is that everything flows, virtually no visible bottlenecks. There can be a line getting into the store, but inside you are amazed at smoothness of everything.
• The company want to fully control key activities, like supplies and when to restock each shelf. Therefore restocking is done by company employees and to by suppliers.
• The employees are encouraged to spend as much time among the customers as possible. Stocks are refilled during daytime and inventory is till done by browsing the shelves and taking notes with pen and paper to allow the employees to get a feel for the running of the store.
• Key figures of sales, comparisons to previous years, number of customers presently inside the store etc. is automatically extracted form IT systems and available to all personnel in real-time.
• The CEO has in several interviews said that a goal is that every day a hundred things should be improved by 1%, and that they don't aim to improve one thing 100%.
• The employees are empowered to a very high degree. And they are really trying to help the customers (no, their salary does not depend on how much they personally sell).
• Most of the changes in the daily running of things seem to come from employees.
• The CEO spends at least 1 hour a day among the customers in the store to understand the running of the business.
• Every investment is weighted against how much money it can save for the customers.
• They focus only at retaining their existing customers (they don't advertise at all!). New customers are only by word of mouth.
• Even though economists suggest they could retail their products for a higher price they are adamant in keeping overhead to a minimum. "When our purchasers make a deal it shall benefit our customers."

The items above are conclusions based on personal visits, information from their web page, youtube clips with the CEO (in Swedish) and a report from University of Borås (also in Swedish).

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.

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.