Excellence as a Habit

I'm a big fan of quality. It's not that hard to understand that the user visible quality of the software is a necessity. If the customer is constantly disappointed, (s)he won't be a happy customer. And probably quite soon not a customer at all. But the visible quality is not all. Most of the time it's just the tip of the iceberg.

With software also the internal quality matters. How well your interfaces have been defined, how long/short are your routines and how much coupling there are between modules. If you know what you are doing (and you are the one who wrote that code) you might be able to navigate efficiently in a bit hairier spaghetti. But for the other non-swamp guide developers it can be much harder. Yesterday's code will be tomorrow's legacy. Keep that in mind.

But writing good quality code requires another kind of quality also. Quality in operations. Into some extent I believe this equals having skill and discipline. Again, I'm raising up the need for craftsmanship. For software development with multiple programmers and teams quality in operations includes also commonly agreed coding standards.

I have always found it much easier to define rules than to actually get people to follow those (although I'm usually working more in the implementation side than in the definition). People either forget, they haven't cared in the first place or simply haven't even been informed about the existence of the rules to begin with. So, there's value in both crafting the rules and in making people understand the value of the rules. Many times the rules are enforced by different actors than their creator, which is fine. Different people have different strengths. And finally: there's value in reminding people about the rules.

Systematic built-in quality in operations requires someone to take good care of the big picture. Practicing wishful thinking is not enough, someone also needs to see the evidence that agreed things really happen. Quality systems and audits are a practical way to see if the organization really plays by the rules it has set for itself. Some see them as heavy or bureaucratic, but frankly I think those people usually lack some self-discipline. If you play by the rules then someone watching over isn't hindering your progress. And if the rules suck, please help improve them instead of whining!

And it's also all so natural and fitting for Agile ways of working. Working software should be the sole measure of progress. And for example in Scrum it is shown at the end of the Sprint. Talk and PowerPoints are cheap, demonstrating new functionality rocks!

Instead of sometimes succeeding and most of the time being unpredictable, make excellence a habit. Learn the rules, break the rules, be the rule: Shu-Ha-Ri. And apply the same principle on all levels of the organization. Self-discipline is needed in the Development teams but also in the management. Dare not to expect something from the people working for you that you are not willing to do yourself. If you want people to walk the extra mile, be prepared to walk in the front.