What is an acceptabel level of quality?

When writing software, the question sometimes arise, ”What’s good enough code” and how you can define code quality.

For a non software developer, these levels may not that easy to understand, so therefore I would like to make a more visual description of acceptable quality, using film as an example.

In filmmaking there are three aspects of quality: i.e, story, acting and production value, e.g. a more technical quality. 

I would like compare software quality to technical quality, as even the most elegant written piece of software is worthless if it doesn’t solve a customer problem. Same with film, a good technical quality is not enough if story and acting is bad.

In order for a recorded clip to be usable, it has to follow these eight basic rules:

  • Coverage: All scenes with at least one shot per scen 
  • Composition: Basic composition rules; one-third, diagonal etc. 
  • Movement: Stable camera movements, no camera shake or rapid zoom in/out  
  • Focus: Main subject in focus 
  • Exposure: Correct exposure for the main subject 
  • White balance: Correct color balance for main subject in indoor/outdoor environments 
  • Sound: Clear dialogue without disturbing sound from environment 
  • Sync: Image and sound in sync and no drift during clips

The challenge for the crew is to deliver consistent footage that reach this level, with pressure to deliverer on time and with Murphys Law always present. To achieve this, you need skilled people working together, but this is not different from a software development team. 

But what about a few simple rules for software development, that work for different languages?

Custom software development blues

There are two main challenges with customer software development, compared to using package based software.

The first one is how to be ready in time, on budget and with the fulfilment of requirements. This is especially true when you develop a system that would replace something existing. 

The other is more long term and how to build a bespoke solution that could be maintained over the years. If it’s a bigger investment and core business, you will need to develop a solution that there for many years.

On the other and, package based solution with to much customer based code inside is also very cumbersome to maintain, so as a decision maker you are between a rock and a hard place.

Short term goals

When starting a software development project, you need to assure that you cover most of the requirements, both functional and non-functional, in the planning phase. I have seen a lot of examples where the initial estimates were a small fraction of the total cost. Therefore, as a project manager, you have to ask how the lead developer have assured that they don’t miss any requirements. 

Long term goals

In order to fullfil the long term goals of maintainability and compatibility of your software, you need to have some development guidelines in place. They should assure that; the code is readable; not to long units of code; not to complex code and have re-usable part of code instead of copied blocks of code. 

There are other guidelines for assuring quality in software, so these above are just an example.

These guidelines must be enforced from the beginning of the project, otherwise the technical debt will soon be to high. If running an agile project, these guidelines must also be part of each sprint, otherwise they will be forgotten.

Watch more

For more inspiration, watch the videos ”Like buying a horse” and "Fix it with duct tejp" at Architecture Corner on Youtube.

Will GDPR hit your small business?

I'm an employed consultant, bu I also have a side business in Sweden were I'm a sole owner of a film production company. This is the reason why I have to solve how to handle GPPR for myself, and not only for larger clients.

What I found out recently is that the knowledge about GDPR in smaller companies is more or less non-existent, and some of the industry associations are neither so well informed of the consequences of the new legislation.

As a small business owner, it's your responsibility as well as the CEO of a larger company, if you collect sensitive personal data. 

To solve my own issues with GDPR, I take an enterprise architecture approach, and define four different business use-cases as a starting point for the preparations. The question is how you should act after GDPR is in place in May 2018 in each of these for cases?  

FX-00347-0142 (medium).jpg

The four different business use cases are 

  • Street photography
  • Wedding photography
  • Child photography
  • Film production

What I have to do is find out how legislation impacts my workflow and storage of personal information in each case. Does it sound familiar?

Business use-case for street photographer

You have a professional business, and have a large number of photographs taken at a Pride festival in Stockholm (a public place). When people can be identified and Pride is about sexual orientation and opinions about this, I think the images can be considered as sensitive personal data.

Business use-case for wedding photography

You are a professional photographer and a year ago you had a mission to photograph a wedding.

Now the groom comes and says he wants all the pictures from the wedding, and refers to the right to transfer personal data in GDPR.

Two days later comes a very upset bride who talks that they are in divorce and she wants all the pictures from the wedding to be erased, with the right to be forgotten in GDPR.

Business use-case for an employed professional photographer

You are photographing mothers and children as a hobby, and your are invoicing through a company that pays your salary.

One day, you will receive an email from someone who tells you that he copied your entire image archive in a security breach at your home, and threatens to publish all images online if you do not pay a random. He also sent some pictures of minors you’ve taken to show that you that he is serious.

Business use-case as a film producer

You own a production company that produces a feature film. You have both employed and hired self-employed persons from several Nordic countries.

Now, the financiers of the movie want to find out how to make sure you follow GDPR, in order not to get some unpleasant surprises that can delay or increase cost for the movie, and in the worst case prevent distribution of the movie.

Bad software kills


Bad software development habits are like smoking cigarettes. 

The biggest challange for the organisation is to understand that those habits are as leathal to IT as smoking is to your lungs.

Your companys IT-systems will get a massive technical dept, and it will be to late to save them, if you don’t take action now.

Lack of disease insight make ad-hoc programming without design comparable to smoking a parties. You feel good and having a joyful evening. Eventually you cough a little in the morning the day after, but nothing serious.

Today, in many organisations, the health awerness for IT systems, are like the public knowledge of dangers of smoking in the fifthties. A time when smoking was glamourous.

 In order to avoid technical debt building up like tar in your lungs, you have to be aware and understand that bad software kills IT-systems. Not today, but slowly over time.

For an architect, in a organisation with lack of disease insight, the first step is to build up an awareness of the problem together with the major stakeholders.