Column

Be pragmatic, not dogmatic!

JoachimArrasz
cogs

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!

Author
JoachimArrasz
Joachim is a software and system architect at Synyx GmbH & Co. KG and leads the project CodeClinic. Joachim likes to blog and you can find him on Twitter @arrasz.
Comments
comments powered by Disqus