Culture is the new Process

27 Jul, 2009

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.

Newest Most Voted
Inline Feedbacks
View all comments
Bart Guijt
12 years ago

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.

Machiel Groeneveld
Machiel Groeneveld
12 years ago

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.

Wilfred Springer
12 years ago

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

Vincent Oostindie
Vincent Oostindie
12 years ago

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.

Explore related posts