Culture is the new Process

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.
Simplicity
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.