Be pragmatic, not dogmatic!
Joachim Arrasz discusses why developers ought to be more pragmatic than dogmatic, using a Spring scenario
Dogmatism as well as pragmatism is often used as an excuse for certain bad habits within software development. In this column we would like to present several examples for both within software development and hopefully we can create an exciting discussion about it!
The basis for this article has developed over many years through discussions with developers, senior developers and software architects – or wannabes. But also people in suits should be part of the discussion too. I am going to pick up on topics that should make some managers who are involved in the things I mention feel vindicated. Let me surprise you…
But I also found opposite experiences of developers not in a management role, who don’t moan when there’s a problem and just get their hands dirty. They plug those holes without complaining, insisting on titles or rights and remuneration for their efforts. They just get on with it. If those developers are also lazy, they totally fulfil my ideal! In my opinion laziness is the best condition for being pragmatic, as long as it results in thinking about the automation of repetitive processes. Of course, the quality should of course not be compromised by the developers’ laziness.
By the way, it is important to consider everything I write is my personal opinion. Discussions are more than welcome and I guess the topics provide enough material! And if someone feels targeted – please know that everything is fictitious and any similarities are therefore purely coincidental…
“Best Tool for a Problem” versus “If you only have a hammer, every problem is a nail…”
Let’s move on to the first fictional hypothetical scenario. I met a developer who was cursing and swearing while he was working on a Spring configuration. He was working on a project which was so far based completely on the Spring technology stack. One should actually think: “Awesome, finally it works 100% according to the framework.” Any Spring-experienced developer should now be able to find his way around any problems and work faster within the project.
Yet, the cursing developer couldn´t find a simple enough solution for his current problem. Spring did not provide him a simple solution – which is admittedly rather uncommon. He asked a colleague who was in charge of the architecture for advice and suggested a solution that was able to function with only some lines of additional code based completely on the JDK which was used in this project.
But the architect in charge insisted that the solution be undertaken “in an orderly fashion” via Spring, because if it does not follow the schema, the project’s maintainability would be jeopardized, which in turn could compromise the whole thing. Furthermore it could be possible that the same problem will occur again.
I actually think that the architect was right. But after analysing the problem and discussing it with the collegue, I realized that obeying the architectural guidelines was not the best decision in this case. (I am not going to elaborate on the specific problem since it is rather a methodical than a technical one.) Following the guidelines would result in a very complicated configuration, which would really be hard to maintain, and would cause much more trouble. In this case, it seemed to be disadvantageous to follow the architectonical standard.
My opinion to this dilemma
Following certain schemes and patterns dogmatically is only partly effective. One should always have an open ear for suggested alternatives. Good architects always listen more to their teammates rather than to their gut instincts, anyway. If the alternative includes taking new libraries into consideration, it would be beneficial to check if they could be integrated with the existing ones. That could in fact be a better solution.
In this case, the suggested solution was to use the Java-Standard-API. So in my opinion that would not have been a problem at all, since Spring itself does nothing else than wrapping this API and making it available in a easy to consume way. If in some cases this wrapping reveals to be not very useful (yes, that happens), one should forget the standard and find a pragmatic solution.
The argument “the same problem could occur again – so stick to the standard” is a real showstopper. I have heard that argument too often and I must say, I am tired of it. The day, the reusability comes into the picture, it will still be possible to start the refactoring and to invest additional time.
Otherwise the code would be superfluous, the code base will be polluted and the maintenance will become complicated. Until then, the code should be as simple as possible which means that in my opinion the Java-standard-API-solution would be the best at this time. It does not demotivate the developer and does not prevent later refactorings.
Do you agree with Joachim? Give us your thoughts!