Culture is the new Process

Erwin van der Koogh

Over the years I have seen many attempts to increase software quality. Most of our clients try to increase software quality by introducing a quality process. It usually involves a combination of strict coding guidelines, code reviews, checklists, acceptance criteria based on things like PMD, Checkstyle and Findbugs and audits by external parties amongst others.
But what struck me a couple of weeks ago is that we, as Xebia, have little extensive formal quality process. That is, while we have do have a lot of best practices and we test and measure quality a lot, we never have to resort to 'enforcing' quality.

There are no mandatory code reviews, no coding guidelines and while I know there are some PMD, Checkstyle and Findbugs configuration files in the Maven repository somewhere, but I seriously doubt that all our projects make us of them. Yet when our software is audited by external auditors we receive marks like "There are no recommendations on how to improve the maintainability and reliability.." and "The strongest point of the system is that it does not contain any weak points. The systems scored great or excellent on all points.".
I have seen exactly the same thing at one of our customer about a year ago while I was doing a security audit. The code was clear, extremely easy to understand and we had literally only 1 unimportant finding, where normally we have tens of important ones. They had no process to speak off to make sure that that happened, it just happened.
At my previous employer we also had very little in the way of process and still managed to deliver high quality software. How is this all possible?

All these environments have a couple things in common in no particular order.

  • They have experienced and passionate teams and especially team leaders.
  • There is a very strong focus on keeping things simple and getting results.
  • The entire organization has an culture of excellence.
  • An open culture.

I will discuss those points one by one:

Experienced teams and team leaders

Xebia has very strict recruiting requirements and as part of the recruitment procedure, besides the usual interview, we have assignments where candidates can (and must) show they have experience in the field. At my previous employer and my customer there were Gertjan van Oosten and Andre Kampert, easily some of the best team leads I have come across in my career. These people not only know the rules to writing good software, but also when to break them. All those people are passionate about creating quality working software.


But maybe the most important thing that happened in all the environments is a very strict focus on keeping things simple and getting results. However do not confuse simplicity with using simple code. The best example on how not to do it came from an application I had to quickly fix a couple of bugs in. The most complex construct in the entire application was a case statement with 4 cases and a default. However there were methods with 6 deep nested if statements. Some complexity, in this case in the form of polymorphism for example, would have gone a long way to make the application more simple.
The focus on results makes sure the application never strays too far away from working code. If we have something working now and we have to have something working in one week, we better make sure it keeps working in between as well.

Culture of excellence

This one is very visible within Xebia, but also in the other organizations. One of our core values in Quality without Compromise. While that is of course utopian, it does mean that if we ever make a compromise on quality, we have at least thought about it very carefully. It also means I do not have to defend each and every decision to project managers or line managers. If I can do something dirty in 2 hours and do it properly in a day, I can easily say it is going to take a day. We do things right or we do not do them at all.

Open culture

Software quality is never black and white. There is a great deal of grey. What these environments have is a culture in which it is ok to discuss quality. No single person 'owns' a single piece of code and the entire thing is a team effort. A discussion about the quality of the code that someone had written is perceived as a way to improve both the code and the person having written the code.

So to sum it all up, if you are having code quality issue you should contemplate throwing out all quality procedures, hire a passionate, experienced team lead, keep a focus on simple, working code, and give your team the assurance that while it is ok to make mistakes, it is not ok to take shortcuts and not to do things properly.

Comments (6)

  1. Bart Guijt - Reply

    July 27, 2009 at 10:25 am

    You're on to something here - I like that!

    A process is worth *nothing* if your team is a bunch of individuals, or if the team lacks leadership, or no talent is on the team.

  2. Machiel Groeneveld - Reply

    July 27, 2009 at 12:38 pm

    You write: "as Xebia, have next to no quality process." This is totally untrue. You probably think of a process as something on paper, or documented with strict formal steps to take (which then everyone ignores).

    However, at Xebia there is indeed a process. It starts with individuals interacting heavily on a problem (step 1), testers testing the solution (step 2), some more individuals doing some more interacting based on found problems (step 3 to 12) etc. Just because our process is based on context-sensitive information and individual judgement, doesn't mean there is no process. In fact, most project at Xebia follow the exact same high-interaction process. The cool part is that we don't even have to document it to make it repeatable 🙂 CMMI's wet dream.

    What most companies fail to realise is that a process has nothing to do with paper documents. It has everything to do with what people "Actually Do"-tm. At Xebia we value doing things well over doing things by the book. In the end our approach reaps much better results and that's the only thing that matters.

  3. Erwin van der Koogh - Reply

    July 27, 2009 at 1:02 pm

    That is exactly what I meant by culture Machiel!
    Maybe it would have been clearer if I had said: "At Xebia have very little formal process. ", but let's not split hairs here. 😉

    You say that our process is repeatable, which indeed it seems when you look at our history. But I am not so sure it is replicate-able. What I would like to be able to do is go to other organizations and explain them how to do exactly what we did and get the same results. I do not think that we can do that just yet.
    My current thinking is that our process as you describe it stems from our culture. In this case our culture of excellence and quality.

    The next question is how can we get this culture embedded into other organizations as a substitute for the more formal quality processes our customers have. Which is what the post is about.

  4. Wilfred Springer - Reply

    July 27, 2009 at 3:08 pm

    I like it. It sounds much better than the reverse ("Process is the new Culture"), so it must be true. In fact, since a lot of the popular software out there is actually about building communities, and essentially establishing a shared culture, you might as well say culture is shaping the new culture. I am not sure what that means, but it sounds great. (Does that fit Conway's law, in loosely defined sense?)

  5. Vincent Oostindie - Reply

    August 2, 2009 at 9:58 pm

    You say: "What I would like to be able to do is go to other organizations and explain them how to do exactly what we did and get the same results"

    I think that's the wrong goose you're chasing.

    Don't try to explain the process to your customer. That won't work. Instead: go to your customer and execute the process.

    Leading by example is what you should be doing. Only then you practice what you preach.

    In my opinion this is also the answer to your question on how you can get your 'culture' embedded in other organizations: by actually doing it.

    Sure that's easier said than done, but still I think that's the way to go.

  6. Erwin van der Koogh - Reply

    August 2, 2009 at 10:36 pm


    What I meant by "explaining how to do what we did and the get the results" I meant explaining *what* needs to be done. I completely agree that the only way
    *how* to get that done is with leading by example.

    I am under no impression that talking to a bunch of people is going to convince them of anything, let alone change their way of thinking and culture. But being able to explain how we got our results, it might be a little bit easier to get the opportunity/permission/time at our customers to make that lasting change properly.

Add a Comment