This morning I saw a tweet from Simon Brown that that triggered some odd memories. The tweet was:

simonbrown
And, of course, we no longer live in a world where architects create a “logical view” that developers should go and implement … somehow … twitter.com/simonbrown/sta…
24/10/16 10:50

I remember how the architecture role was described in such terms. Where e's role was to dictate how it should work so the developers could assemble. What they forgot to ask them self was probably what view the developers were suppose to work on? Was that the irrational solution to the logical view the architect had delivered?

When turning the "logical view" on it's head like this it is not very logical. I know it wasn't supposed to be so. But language has a tendency to work it's way into our minds. It forms our way of thinking of things and eventually our way to deal with them. Regardless if it's rational or not. When I saw that tweet this morning it became apparent where at least some of the misconception around software architecture comes from. The way we describe the "logical view" just being a symptom of a deeper problem.

I think it comes down to the idea that we should create things using a top down structure. Using the control structures we are used to. Management wants some kind of software. They'll get the architect to design it, to create the "logical view". Only then can they trust it to the developers. They are probably not even aware that most of the unknowns and risks are in the hands of the developers.

But we know software don't work like that. I actually think most of us also know that nothing else does either. It's a flawed view on humanity that makes us think good work can be done top down. It becomes especially apparent in complex situations such as software development and research. But I don't think it works well anywhere. The rational way to go about getting good work done is bottom up. Letting everyone involved feel responsible and have the mandate to do what changes they think are necessary to get the job done.

Oh well, enough of the rant. And thanks Simon for reminding me of the idiocy in some of the software architecture jargon.

Last time we held an Øresund Software Craftsmanship Group meet-up was probably in December 2015. Now, closing in on a year since the last meet-up, it's perhaps time to say something about why I haven't organised any more.

To run a user group like ØSCG can be very rewarding. But it also takes a lot of time and energy. There's a whole host of things that has to be done for each event. Planing topics, finding speakers, preparing content, market it amongst other things. Then you've got to attending it as the host and sometimes the speaker or facilitator. So even with the fantastic help of FooCafe who takes care of the ground servis it eats up a lot of time.

I had to take that time and energy from somewhere. So my family got to carry the cost. After running ØSCG for a couple of years it became very clear to me that that was not a price I was prepared to pay. This was also something my children had been clearly pointing out to me had I only listened. In that context I felt that what I gained in return did not even come close to what was payed.

But I did not want ØSCG to die. It was an important forum where we as programmers could learn the craft. A craft I find lacking much to often when I go to work. It is really sad that I could not find people who could step up and take the lead in in the community after me. And even though I did get help this was not nearly enough for me to keep it going.

However, I don't think ØSCG is dead yet. I think it's in hibernation. Waiting for someone to come and wake it from it's slumber. Someone with the energy, passion and time needed. It may be me if I can convince my employer to make the investment needed. Or it can be you. If you are interested to start the effort up again I'd be more then happy to help you get started. I will most likely also be involved as long as I don't have to be the lead. So the brand, and the community, is there should you feel the calling.

Last, but not least, would it not have been for Louis Hansen, Pavel Rozenblioum and Mathias Beckius ØSCG would not have carried on for a couple of years. It would have died much sooner. And it would not have been as much fun as it was. Thank you for your help and passion.

So sleep well ØSCG, until spring comes for you and some passionate soles wakes you from your hibernation.

I've been experimenting with my recipe of the classic whiskey sour. When I started making them I followed the class, using only Angostura bitters. This makes a really nice cocktail but kind of lacks something in my opinion. I later found the fantastic bitter Peychaud's which marries fantastically with bourbon. Adding some of this, about three dashes, to your sour will lift it a level. It will also add a really nice colour to your cocktail.

Last summer I had the opportunity to add two new bitters to my collection, Boker's and Ornico. Each will give your sour a new dimension. Do keep in mind, I'm not removing any, just adding more. So now I tend to mix them with three, Angostura, Peychaud's and wither Boker's or Ornico.

The other day I found out that the Swedish off-licens chain, which have monopoly on selling alcoholic dries in Sweden, have  stated to sell a cocktail bitter. One of the real downsides to live in Sweden when you enjoy making cocktails at home is that it's impossible to get hold  of bitters. Now they have stated to sell a bitter called Seehuusen's Bitters. It has flavours of coffee and chocolate. It also mixes really well with a sour. So the lates Whiskey sour to be made in my bar is:

2 shots Jm Beam Bourbon
1 shot fresh lemon juice
1/2 shot simple syrup
1/2 egg white
3 dashes Angostura bitters
3 dashes Peychaud's bitters
3 dashes Seehuusen's bitters

Shake all ingredients with ice. Pour into ice-filled old fashion glass.

Enjoy!

In early July this summer me and my family visited BELLE Epoque in Malmö. I asked the staff for a good apéritif to start the meal (which was nice). They served me a variation on a cocktail they had picked up at the bar Tjoget, in Stockholm. The cocktail is called Milano and here is BELLE Epoque's recipe:

5cl Aperol
3cl Blood Grape
1.5cl Coffee syrup (this coffee syrup is made with one part strong coffee and one part sugar)
Top up with tonic - make sure to make it a good tonic.

Mix all ingredients but the tonic in an ice filled wine glass. Top up with tonic. Garnish with blood grape peal.

I found this cocktail very refreshing. The balance between sweet, juicy blood grape and coffee is really nice.

The Milano
The Milano cocktail, at my bar in the kitchen

There was a conversation around software quality over at the Software Craftsmanship slack team. It's an interesting subject but it often becomes confusing. Some of the questions that comes up are: What is software quality and how can we measure it? I'll try to add my twopence to the topic here, and perhaps make it slightly less confusing.

Lets start with a definition and then go from there. Oxfords English Dictionary has this to say on the subject:

The standard of something as measured against other things of a similar kind; the degree of excellence of something

To make sense of that definition we need to understand the context. What "something" is and what "other things of a similar kind" is.  To me this is pretty simple. The only person that can define what "something" is are the users of the software. In an enterprise system this is the enterprise user. In a API library it's the programmer using it. In the case of an end user application, such as a word processor or a game, it's the end user. And they will naturally measure this against other similar products or against their perception of how other similar things should work.

So my definition of software quality is:

The standard of said software as the end user of this software perceives it, measured against other similar software or the end users perception of how other similar software should work.

This makes my measure of quality rather narrow. I'm actually only interested in how my software is perceived by the users. This is also how I receive the measuring points needed to define what quality in my solution is. Therefor such tools as code analysers and test coverage is only important as long as the feedback from them helps me guarantee that the end user receives high quality.

So now what we are left with is understanding what the end user values as quality. As we start out, trying a new idea on the market, quality for the user may well be speed. It's certainly what we need to know if we should continue. To achieve this we create a PoC (Prof of Concept). This is often not a very well designed piece of software. It may well be something we will throw away a week after release. It's is as little as is possible to receive the feedback we need. If the users likes to use it we know it provided them with quality. Now we need to sustain and improve this quality.

As we continue to stabilise and improve our product we need to ensure that the user does not experience a regression in quality. Then they may well leave us for a competitor. To achieve this we need to ensure we have well tested and well crafted code. Here all the tools we can use to detect if our code is up to the high standard we need are of great help. Tools such as static code analysers, test coverage and so forth. Practices such as code reviews and pairing. The definition of quality is till the same however. Only the measures differs.

With this kind of definition I think it's easier to justify and measure what quality is. Keeping it this way makes it easier for all involved to relate to quality. And quality often comes up in conversations when we talk about the software we work with. Most commonly people try to refer to code quality and has a perception that well crafted clean code is what we always must strive for to achieve software quality. Clean code is important in many contexts. But not always. Sometimes speed is what we need. Short term speed and throw away code. It is, as always a matter of trade offs.