Software quality is a business decision


A recent twitter conversation I had with Ron Jeffries regarding quality in software development spurred me to write this post. Thanks for the inspiration, Ron.

I believe that quality in software development is predominantly a business decision. For clarification purposes;
(1) I use the word ‘business’ here largely to mean an organisation’s management team, and
(2) I use the word ‘decision’ because in my mind software quality requires “the act of or need for making up one’s mind”.

Firstly, how is quality in software development defined? The answer to this question is not as simple as one might think. Of the various definitions out there, the following words of Mr Jerry Weinberg in this post resonate with me and the way I perceive the meaning of software quality:-
“A definition of quality is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another.”
And further:-
“Crosby’s definition: “Quality is meeting requirements.” Unless your requirements come directly from heaven (as some developers seem to think), a more precise statement would be:- “Quality is meeting some person’s requirements.” For each different person, the same product will generally have different “quality””.

If software quality is not rudimentary to define, how can we actually achieve it? To me, this is a fascinating question and I’m quite certain people have differing opinions on it. However, below is a brief discussion on what I think we may need in order to produce software that meets our overall users’ requirements, ie. software of high quality.

A skilled workforce. People want to master things from sports to music to the latest cool new version of their favourite programming language. Developers want to write good clean code. We need to enable them to do so. At the very least we should probably try and get out of their way while they attempt to master something themselves.

Motivated people. Hopefully we all agree that the days of believing knowledge workers are motivated by material things and/or monetary rewards are long gone, so specifically; we need people that are intrinsically motivated by a strong sense of purpose. What were the forces at play that brought people together to write software like Firefox, Linux and the Apache Web Server in their spare time? We should make deliberate attempts to harness the power of these forces and purpose is key.

Self organisation. Boundaries in self organisation are important but people should generally be afforded the opportunity to organise themselves around a piece of work. If we already have highly skilled and motivated people, we shouldn’t dictate how they need to go about doing their work either. Nurturing an environment that promotes autonomy and a sense of agency is a great way to keep people engaged, too.

Theory Y management. People are not inherently lazy and they don’t need to be put under undue pressure to perform their jobs. Measuring people against targets, periodically reviewing their performance, dangling incentive scheme carrots in front of them and putting them in their little job profile boxes are management tools that are way past their bedtime. None of this malarkey helps to improve the effectiveness of our organisations. We should also acknowledge that our organisations are networks of interconnected human beings and that they are complex systems. Let’s think in terms of synergy and drop those stubborn command and control mindsets.

How regularly are product development teams overly constrained in their technology or design and architectural choices? How regularly do poorly structured organisations (ie. silo’d or divisionalized) impact on quality due to eg. frequent handovers being required? How regularly are product development teams forced to use predefined methods, methodologies or processes? How regularly are knowledge workers subjected to theory X mindsets and management tools that are highly effective at rendering people ineffective? How many organisations release software on quality as opposed to on schedule?

In order to produce software of high quality the business must create an environment that supports and enables it. It’s a mindset. It’s a culture.

Writing good clean code is extremely important, but it’s not half the story.

Quality is a business decision.

Thanks for reading,

Further reading:-
The Cynefin framework (see section on software quality).

Posted in Software Quality | Tagged , , , , , , , , , , , , | Leave a comment

The Cynefin Framework

The Cynefin Framework

I’m going to be honest with you; when I first started learning about Cynefin I struggled a bit to relate the theory to practice.  In fact I sometimes wondered how I could use the framework.  Fortunately I continued learning about Cynefin because the relationship between the theory and it’s application in practice is quite clear to me now.  This does not make me an expert on Cynefin and I am very much on a journey of discovery and learning.  My hope with this post is to present Cynefin to you in a demystified and somewhat practical way.

Let’s examine some of the theory first.

What does the word ”Cynefin” mean?

The word “Cynefin”, pronounced ki-neh-vin, is a Welsh word that cannot be directly translated into English.  However, it is commonly translated as ‘habitat’ or ‘place’ and means a place of multiple belongings.  We are all rooted in many different pasts which profoundly influence who we are, but of which we are only partially aware. ie. geographic, tribal, religious, cultural, etc.

 Origins of Cynefin

Cynefin was first developed by Dave Snowden in 1999 in the context of knowledge management and organisational strategy.  By 2002, it had developed to include complex adaptive systems theory.  It was further developed and elaborated with Cynthia Kurtz as part of their work with the IBM Institute of Knowledge Management, and by Mary Boone to extend the model to Leadership.   It appeared as the cover feature in the Harvard Business Review in 2007 in the context of leadership.

What is Cynefin?


Cynefin is a decision framework that recognises the causal differences that exist between different types of systems, proposing new approaches to decision making in complex social environments.  Cynefin is also a sense-making model, not a categorisation model.  In a categorisation model, the framework precedes the data.  This is good for exploitation but not exploration.  In a sense-making model the data precedes the framework, making it good for exploration.

The 3 basic types of systems involved in Cynefin are; ordered, complex and chaotic.  Ordered systems are divided into 2; simple and complicated.  There are 5 domains in total; Simple, Complicated, Complex, Chaotic and Disorder (in the middle of the image above).

Before we move on to describe the various domains, I hope that the two sentances below will help you understand why Cynefin can be so beneficial for us:-
We need to think differently about different problems.  There is no one size fits all approach and the actions you take depend on which domain you are in.

1.   The Simple Domain

In the simple domain we are in an ordered system where the relationship between cause and effect exists, is predictable in advance and is self evident or obvious to any reasonable person.

We apply best practises and the approach is to:-


Sense                  – See what’s coming in
Categorise        – Make it fit predetermined categories
Respond            – Decide what to do

Eg.  A clerk in a banking institution calculating compound interest.  Best practise is applied in terms of predefined formulae and given an input the results are always the same.

2.   The Complicated Domain

In the complicated domain we have an ordered system where there is a right answer and where a relationship does exist between cause and effect, however, the answer is not self-evident and requires analysis and/or the application of expert knowledge.  There can be several different ways of doing things in this domain, with the right expertise.

We apply good practise and the approach is to:-


Sense                    – See what’s coming in
Analyse               – Investigate or analyse, using expert knowledge
Respond              – Decide what to do

Eg.  Anything that can be solved with professional training or external consulting services, like the need to develop software in a specific language (ie. C# or Java).

3.   The Complex Domain

In the complex domain we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable.  Here, we need to create safe to fail experiments and not attempt to create fail safe design.  We cannot solve complex problems with best or good practices alone.  While conducting safe to fail experiments, we must dampen the parts that fail and amplify the parts that succeed.  It is prudent to have an amplification and dampening strategy in advance.  In this domain we get emergent order and practice that is often unique.

Emergent practice, behaviour or order results and the approach is to:-


Probe                   – Experimental input
Sense                    – Failures or successes
Respond              – Decide what to do ie. amplify or dampen

Eg.  Most types of innovation.  Professional training or best practices are replaced with probing different approaches and ideas, sensing the results/feedback to see what works and what doesn’t, and responding appropriately (by amplifying and dampening our probes).

4.   The Chaotic Domain

In the chaotic domain no cause and effect relationship can be determined.  We have to stabilise the position very quickly!

We discover novel practice and the approach is to:-


Act                       – Attempt to stabilise
Sense                  – Failures or successes
Respond            – Decide what to do next

Eg.  A medical emergency situation.

Note:  It is possible for a problem to fall into more than one domain simultaneously.  I will show an example of this at the end of the post.

5.   The  Domain of Disorder

This domain includes the state of not knowing what type of causality exists or what space you are in.  The problem here is that we interpret and assess the situation we are in based on our personal preference for action, reverting to our own comfort zones.

For the sake of completeness

Transitions can occur from the Simple to the Chaotic domains.  Here you ‘fall over the edge’ and any recovery is extremely expensive.  For this reason, we should attempt to manage things in the complicated and complex domains.

Using Cynefin

Cynefin has been used for analysing policymaking within the George W Bush administration and the impact of religion in that process, the nature of response to bioterrorism, as well as aspects of measurement in the British National Health Services.  It’s also been used for the retrospective study of emergency situations and to study the interaction between civilians and the military during disaster control.

 That’s all great – you might be thinking – but how can I use it?

Consider this: – if you spend 2-3 years in a process based bureaucratic role, you’ll tend to see all problems as failure of process.  If you’re an expert in a particular field, you’ll tend to see any problem as a failure to give you the necessary time or resources to do your expert analysis.  We therefore have a natural tendency to categorise problems based on our own knowledge, skills and previous experiences.

Let’s take the subject of software quality as an example.

You might be forgiven for thinking that by applying best practice techniques such as BDD, TDD, Pair Programming, Code Analysis (cyclomatic complexity, etc), Automated Integration Testing, Automated Regression Testing, that you will be able build a near bug free software product.   However, what if for example, your business logic is contained in your database layer’s code in stored procedures?  If you could unit test the stored procedures would you still need your 90+% unit test coverage in your application code?  Would you still need as many automated integration tests? Or would you even perhaps decide to put even more effort into the automated integration testing and not unit testing?  Software quality has elements in all the Cynefin domains.  There are best practices and good practices that should make use of.  However, in context of the discussion here; in my opinion, the complex parts require us to create safe to fail experiments, trying different approaches, measuring their results, and then dampening or amplifying elements of your experiments along the way to see what works best in your context.


When you’re next faced with a problem, question your immediate problem solving approach.  See if the problem can indeed be tackled with best or good practice or whether you need to do a little probing, sensing and responding.  Finally, we probably all agree that the incremental delivery of software with frequent short feedback loops is the approach we should use; releasing small bits of high value software, receiving feedback, reflecting, adapting, and repeating.  Does this not sound complex to you? 🙂

Posted in Systems | Tagged , , , , , , , , , | Leave a comment

For happy people and improved performance, drop the incentive schemes


Numerous reports from well known organisations such as Gallup, suggest that employee engagement levels are as low as 30%. It saddens me to think that 7 out of 10 of my friends and family do not, to put it simply, enjoy their jobs. There is surely little doubt that many of today’s management and leadership principles and practices need to change to get us out of this mess. Well known management ‘gurus’, such as Dr W E Deming, have been speaking about this need for management change for decades. Between 1979 and 1982, for example, Ford incurred billion in losses. Deming, who was recruited to help them, questioned the company’s culture and the way the managers operated, saying that 85% of all problems in developing better cars was due to managements actions. By 1986, Ford had become the most profitable American auto company and for the first time since the 1920s, it’s earnings had exceeded that of their arch rivals, General Motors.

In this blog post I’d like to focus on one damaging yet extremely common management practice. It can be highlighted by one short sentence:-

“Do this and you’ll get that”.

Yes, incentive or bonus schemes.


Many studies in social psychology have shown that people who expect rewards do not even perform as well as those who expect nothing. In terms of changes in attitudes or behaviors, rewards offer only temporary compliance and certainly no long lasting changes. In fact, rewards and punishment are really two sides of the same coin, with rewards being just as manipulative. How different is being told what will happen to you if you do X, from being told what you’ll receive for doing Y? People feel punished if they don’t get the reward they were hoping for, too.


Collaboration will not emerge and if it was ever in existence, it will be killed. One of the main culprits for this is competition between your people. Team work is required but unfortunately, it will largely cease to exist when faced with the resulting competition.


To put an end to low productivity, management needs to ask themselves questions and study what the causes are. Incentive plans squash this by not answering and/or ignoring the answers to these questions.

Experimentation and learning

People will not want to take risks. People will not want to experiment. If we don’t experiment, how will we learn and grow ourselves and our knowledge and understanding of our world of work? The irony too is that a number of organisations start off by taking risks only to stop once they’re large and established.

Undermine our love for work

What can be more motivating than loving what you do? The answer is probably, nothing. When rewards erode intrinsic motivation (and they will) people have no reason to work other than for rewards. This creates a need for the self same incentive schemes and so an awful self for-filling prophecy will exist.

A quick word on metrics.

Here are a few examples of commonly used metrics that are often linked to individual performance appraisal systems and incentive schemes:-
– Call centre agents: the time taken to answer an incoming phone call.
– IT Support Service technicians: the number of support tickets closed and the time taken to close them.
– Software Development teams: a team’s velocity or the number of bugs logged by a tester.

John Seddon, a well known British occupational psychologist, author and speaker says; “Targets and all other arbitrary measures create a de facto purpose, making your entire system worse. When you incentivize behavior you always get less of the behaviors that you actually need.”

Using our examples above, the following is likely to occur:-
– The folks in the call centre will end existing phone calls prematurely in order to quickly answer new phone calls, providing a sub-standard service.
– Some folks in the IT support team will scavenge their team’s list of support tickets for the ones that are easy to solve; in order to increase their numbers of closed tickets. They will favour ‘quick and dirty’ support over a slightly longer yet far greater support experience for their customers. Teamwork, collaboration and mutual learning will all but vanish.
– The folks in the software development team are likely to rush their development and testing in order to inflate their velocities. If their velocities are calculated using estimates, they could intentionally increase their estimates too, in order to inflate the figures. The testers will log bugs for every issue they find, even spelling mistakes, wasting huge amounts of time.

I’m sure you’ll agree that none of these behaviours are desirable.


I am a large advocate of systems thinking. Dr W E Deming‘s “95% rule” states that about 95% of the performance of an organisation and its people is governed by the system within which the work happens and not by the individuals themselves. Dr Deming also wrote about “7 Deadly Diseases” relating to management practices. In 3rd place are personal review systems or evaluation of performance.

For years, people like Alfie Kohn and more recently Daniel Pink, have said that we must pay people well enough and then help them forget about money. Money does not motivate people involved in knowledge work. What motivates these people are things like working with a strong and common shared purpose, like the mastering of an art or skill, and like being able to work in an autonomous fashion.

Why do we continue with this archaic method when all the research and experience available to us says it is controlling and dysfunctional? Maybe for the same reasons so many other dysfunctional management practices still exist – reasons that continue to elude many of us…….

To end off, a quote from Alfie Kohn; “Reward systems are great. They work really well for training your family pet.”

Posted in Management & Leadership | Tagged , , , , , , , , , , , , , | 2 Comments

Recruitment Dysfunctions

I have something to admit.  The more I think about the recruitment of software developers, the more I believe that almost everything about it is full of nasty dysfunctions.

Let’s talk about three of the common and key parts; CVs, tests or assessments, and interviews.


Imagine a world where the information relating to a candidates’ qualifications, talents, skills, achievements, and even likes and dislikes are filtered by keyword matching (sometimes computerised).  And, where it’s almost impossible to filter great candidates from average ones.  And, where a candidates’ chances are tossed out of the window because they haven’t had X number of years programming experience in XYZ language.  Or, where a candidates’ chances are reduced to zero because they’ve had too much experience in too many languages and environments (how good can s/he be if they’ve programmed in 15 languages over 5 years, right?!).  Or, where a candidates’ chances are all but dashed because s/he rates themselves a 2 out of 5 for being able to program in C#.

This world is ours, I’m afraid.

What does a CV tell you about a person’s ability to learn new skills?  Or their ability to inspire and motivate peers?  Or their ability to adapt inside complex teamwork based environments?

Fail # 1 = CVs.

Next steps

If the candidate survives this initial debacle, quite regularly the next step involves assessments or tests in something the employer deems useful.  Usually, similar to CV filtering, this step involves an extremely narrow focus.  So, the lucky candidate takes your Java, C++, C#, .NET, DB2, SQL Server assessment.   What if s/he googled for common online test questions and studied 100s of results before taking your test?  Anyway, moving on.  If the person fails (whatever that means), their application gets thrown out.  What if the person is an extremely talented individual, but s/he doesn’t have the excessively narrow specialism you think you require? Would you rather help someone learn the syntactic sugar of your programming language of choice for 2 weeks, or have an ‘expert’ come in and hate every minute of their new job?  What do your tests and assessments do to determine a person’s levels of flexibility, their ability to cope under the real-world pressure of deadlines, ascertain their team work ethics or their ability to learn new skills and solve complex problems, to adapt in complex social systems, etc?

Fail # 2 = tests and assessments.


Ask a few sneaky questions to test behavioural patterns and responses, fire away with good technical questions, make them design something to assess their problem solving and design skills; while generally trying to make sure the candidate feels like they’re under some form of pressure while you’re at it. Oh, and don’t forget to ask them what their strengths and weaknesses are or where they want to be in 5 years time.
Sounds familiar, doesn’t it?

How do we know any of the behavioural responses are based on truths?  How do you know that the person isn’t lying (or just cleverly responding) when they say that they’re “….quite stubborn and can really sink my teeth into something, not wanting to let go” when asked for their weaknesses? (that’s not a weakness, is it?  Who knows).  And, how well received would a response like “I want to be your bosses boss” be to the 5 year question?

Other factors that often come into play, mostly with negative connotations are; poor physical appearance, not being able to “sell yourself”, lacking some-or-other-level of interpersonal skills, not reacting to attempts at humour, or not being confident enough.  What do these really have to do with someone being effective at his/her software development job?

Software Development is not about writing 1000s of lines of code (not anymore, at least).  The technical and behavioral toolsets required to build enterprise-sized software applications that add real value for your customers, in complex team oriented environments with prevailing cultures and mindsets, far exceeds a narrow specialism and a few ‘good’ perceived behavior traits.

Fail # 3 = Interviews.


I don’t have the answers with regards to a great recruitment or interview process.  I do however believe that today’s common recruitment process is ineffective or ‘hit and miss’ at best.

To end off, I’m going to open up a potential can of worms.  If one considers the role that the system (usually, your organisation) within which we work has on the performance of an organisation, department, team, or person – things get even trickier with regards to recruitment.  The great management guru William Edwards Deming ‘s 95% rule states that about 95% of a person’s performance is based on the system and not on the individual her/himself.  The Marshall Model of Organisational Evolution explains how the effectiveness of any knowledge-work organisation is a direct function of the collective mindset of the people working in the organisation.

A bad system will always defeat a good person.  And, assuming you’re trying to improve your organisation’s effectiveness by improving the system, why would one not want to employ someone with the mindset to help you get there, irrespective of their current narrowly focused technical skills and/or fake or unconfirmed behavioral characteristics?

Till next time.  Thanks for staying.


P.S  This post is work-in-progress. Hopefully some feedback helps me to improve it.

Posted in General | Tagged , , , , , , , , , , , , , , , | 3 Comments

Collaborative Workspaces

So, here it is – my first ever blog post!

To ease myself into the world of blogging, I thought I would start off relatively simply (for want of a better word).

[This is a work-in-progress: Hopefully, feedback helps me to improve this post]


In the world of software development, I’m certain (and I hope) we all agree that communication and collaboration are two key ingredients. In fact, I once read a quote that said: “Developing software is a communication problem”. It’s probably not too far wrong either, in my opinion.

In order for collaboration to happen fairly easily, consideration needs to be given to the more common activities the teams and people will need to conduct and the situations they will need to deal with. I also like to think of impediments in workspaces as any other team impediments. After all, would you rather your people spend time writing code or trying to find a free meeting room to collaborate over a design idea?

It’s important that the people are involved in the design of their own workspaces, and that management supports the creation of this collaborative style environment. This will create a sense of shared responsibility and engagement and these gains will certainly outweigh the cost of their involvement.


Based on my experience and observations, some examples of common workspace obstacles include but are not limited to:-

  • creating meeting invitations
  • time spent searching for free meeting rooms
  • inadequate space for visualisation of work (commonly using whiteboards)
  • inadequate space for shared drawing/modelling
  • difficulty in performing shared code review sessions
  • difficulty in performing shared design/modeling sessions
  • insufficient facilities for demos
  • insufficient facilities and space for individual team meetings
  • high disturbance and noise levels (usually from open plan offices)


Here are some suggestions for how to remove these obstacles and to create a workspace that can improve morale, promote collaboration and increase productivity:-


Teams should be contained in dedicated areas, with walls or partitions. Some research shows that teams in open plan offices are far less productive than teams in quieter dedicated areas (circa 100%). One of the reasons for this is that although communication levels can be high, typically the type of communication taking place adds little or no value to the work being done.
Advantage(s): Minimises noise disturbance and creates focus.

Small meeting rooms

A small quiet space within each team area for quick meetings, or, small rooms nearby that are dedicated to the teams.
Advantage(s): Minimises waiting.

Space for whiteboards

Needs to be significant. The walls or partitions can provide this space.
Advantage(s): Provides needed facilities, minimises waiting, reduces frustration.


Good for assisting in the sharing and communication of information. Best if each team has their own projector, with the walls or partitions providing space for the projecting of the images.
Advantage(s): Provides needed facilities, minimises waiting, reduces frustration.


Everyone needs some privacy from time to time to make phone calls, etc. Mini conference rooms or private cubicles will provide for this.
Advantage(s): Feeling respected, minimise long walks away from team areas.

Convenience items

Commonly used devices such as fax machines and printers must be easily accessible and quickly available. Also, items such as sticky notes, prestik, black tape, whiteboard markers and erasers, should also be readily available.
Advantage(s): Minimises waiting, reduces frustration.

Creative Spaces

There is no need for a dull and depressing workspace. Ideally, colours and other aspects should be used that can help to support creativity.
Advantage(s): Support creativity, improve morale and create sense of pride in workspace.

Well, there you have it. That’s my take on some of the ways to create a collaborative workspace for your teams. Hopefully, you find this information useful and derive some benefit from it.

Any comments or feedback on this post would be very welcome.

Blog post no.1……….tick. 🙂

Ciao for now


Posted in Workspaces | Tagged , , , , , | Leave a comment