I am amazed, yet again, that people try to force others to comply to a process, standard, or whatever. The traditional justification is to ” have governance otherwise everything will fall apart”. Surely, we have learned enough from spectacular failures that governance that does not give people an opportunity to exercise self discipline. When you give a person a chance to develop personal discipline, then forced compliance is unnecessary. With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you. It breeds an attitude of “the system failed me and it’s not my fault”.
This discipline I am talking about is a personal attitude to everything. Some things may be the discipline to
- not check in code that is broken
- fix your own or someone else’s broken code
- find options for looming failure
- be accountable when you’ve accepted responsibility
- admit error when you make a bad judgement
- commit to learn in the face of ignorance
- share because you just should anyway
Of course, I am being deliberately idealistic. But wouldn’t it be really nice if everyone just accepted discipline as something that needs to be developed personally. Imagine it for a moment … so many XP values and principles seem a lot easier to adopt. Just imagine it.
A forced compliance style of governance is a lot about trying to compensate for lack of trust and admitting that we are more likely to fail than succeed. On the other hand, discipline is not pain, suffering and anguish. It’s only sadistic if you implement discipline for nothing.
In ubuntu coding, discipline is a necessary quality.
You need self discipline in order to write good quality code.The project with the most detailed defined and enforced CheckStyle templates that I have come across at a client, is also the project where there is the most serious code quality issues, even though all the code adheres to the CheckStyle templates…
@HermanExactly! Because of the forced compliance to CheckStyle, you do the bare minimum to get a “clean” build but that style of governance blocks the opportunity for accepting the higher responsibility of writing better code.
Nice illustration. I like it a lot!
Hi Aslam,your examples of self discipline, like “not check in code that is broken” is a rule that, even if automatically enforced, would have no impact in your daily operation as diligent developer.
Not all compliance is bad. The rule above, if enforced, could help in a team as traffic lights help cars moving in a crossroad.
Frankly, it is hard to just rely to self-disciplined common sense when most of our industry is nonsensical (giving plenty of Dilbert material at every corner).
I think that the real problem lies in how standards and guidelines are conceived and maintained within an organization, however.
Once written, all too often these rules become the indisputable and immutable law. They may just as well be written in stone.
I recently learned a lesson from the continuous improvement in Toyota (with the understanding that software development is different from manufacturing, so take everything with grain of salt), which roughly says (i’m translating from my memory, not Japanese :D):
“A standard/rule/guideline is our understanding of the best way to do things right know. The moment it is written, it is there to be challenged and will be replaced as soon as better way is found.”
This may or may not apply in software development since rules are rarely context free and software has a lot of variability. In other words, a prescriptive law that takes in account all the possible variations would be complex or impossible to write, so, (hint-hint) if you are “mature enough”, you would rather follow principles 😉
[…] second is a post by Aslam Khan entitled Forced compliance is an obstruction to discipline. I respect him a lot for his forceful call for self-discipline in development, and I don’t […]