Every time, when developers argue about some coding or project management rules, they bring up a lot of cases when these rules simply fail. In my opinion, this can be a very dangerous thing.
Our jobs as developers is to code scenarios and think about all the possible outcomes of our algorithms. We want to know precisely when an algorithm fails and we want to be able to recover from all failures. This is good when you write computer programs, but is really bad when you try to establish rules that must be followed by humans. You see, humans, unlike computers, are not really good with conditionals. Following lots of rules with lots of branching is very exhausting and almost impossible for us. We handle really well consistency, linearity. When trying to establish a rule, don’t try to find all the places where that rule does not fit, because you will end up making all your rules around exceptional cases. This is bad! Exceptional cases are called exceptional because they do not occur often and solving them requires a hell of a lot more work. If you establish rules based on the exceptional cases you will end up treating almost every case exceptionally. This means lots of rules and more work to do. I think that a better approach is to make rules only for the usual cases, and leave exceptional cases alone. For example when you say: “SOLID is wrong because in the X case it won’t work, so we don’t use it”. I think it is better to actually start the other way around: “SOLID works in 80% of cases, if I blindly follow the SOLID principles I end up with 80% consistent, testable, modular code and 20% crappy code. If the code is too crappy, I will do a custom implementation, for that 20% and that’s it”. See the difference? In the second scenario you end up with a rule that will make your life easier in 80% of cases. It doesn’t matter that it is not perfect, we don’t care about exceptional cases, those are exceptional anyways.
Similarly, when trying to incorporate agility in the development process, some teams simply say: “We can’t do Kanban because there is always a chance that our manager will interrupt our task. In our company this can’t be done”. In other words, let’s make our life miserable all the time just because there is a chance that our manager will interrupt us from time to time. I don’t like this mentality. I think that we can make our workflows more developer friendly most of the times and when interruption occurs, we deal with it.