|
Welcome Crappy Code |
At
ACCU
2009 I gave a keynote with the title "Welcome Crappy Code - The
Death of Code Quality".
In gave this keynote, because due to my experience in my business life (which is mainly driven by projects in large and distributed systems or system landscapes) we have a problem with code quality. No, the lack of code quality is not my problem (it is a problem, but it is nothing new). My problem is the way we deal with the lack of code quality. And this has to do with the answer to the question whether we can win the fight against bad code quality.
Guess for the moment that bad code quality is normal if not natural (a least in these days a lack of quality is natural in every business). Of course, we have two ways to deal with this problem: Fight for better quality and dealing with bad code quality. I am not against fighting for good quality (and I claim that I do it constantly in my business). But the question is whether we are able to change this world into something, where somebody will pay for code quality again. From a global point of view, I don't think so. I don't think we can hold on a world of marketing guys selling and promising things we don't have time and money for. I don't think we can stop controllers telling business people to take the cheaper programmer, outsource to a cheaper country, or fire people if it is not obvious why we need them.
So, when I say "Welcome Crappy Code", my point is not to force crappy code. My point is simply to face the reality. But, yes, you can consider my position as a view of resignation.
There is an interesting analogy, which we had recently in our business: After fighting for stable requirements for several years we finally learned to accept that requirements always change. So, in ten years we might laugh about those who fight for good code quality as we laugh now about those that still think that requirements (should) never change.
During the keynote, I gave some supplementary examples why and how the situation will become worse and worse. Due to globalization the complexity will raise (switching from system development to system landscape maintenance), while we have less and less time to realize things. Note that he most important problem is not that people are not willing to provide quality, the most important problem is that the average programmer will not be able to understand what he/she does (which is not necessarily his/her fault). Controllers always find out how to raise pressure against teams, projects, and systems so that we save as much time and money as possible. And they don't care for sustainability. Code quality is an investment into a better future, for which we need time and money we usually don't get. Only after a disaster we can expect to get at least some resources to improve the situation again a bit.
Note that Bob Martin ("Uncle Bob") gave an opening keynote at ACCU at the same day, when I gave my keynote in the afternoon there. In his keynote Bob Martin tried to focus more on the quality in our business and had the idea to force a new movement to bring craftmenship back into development. One of his suggestion was to start to say NO, when you as a good developer should deliver some code with a lack of quality. My answer to this point was simple: Controllers would fire such a guy. The sad reality is that controllers an marketing guys rule the world. Period. End of discussion.
Now, the question is what consequences it has when we accept that code quality is always bad. First, let me say that I don't have a complete answer to this question. For the moment I am trying toforce to think abut our value system as developers. But I had some suggestions that are open for discussion:
In the talk, I gave some examples what this means in practice and why this might help. But this is only the beginning and I am happy to discuss possible consequences with other people. My major point for the moment is that I suggest to think seriously about what it means to accept the current situation that code quality is bad, which has a lot to do with the fact that experts are a minority. This might help us to avoid wasted resources and learning it the hard way.
Finally, here are some BLOGs discussion the keynote and the whole topic: