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).

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….