you know the way powerful people in movies say “Leave Us” when they want to be alone with somebody they want to give a right good talking too. I want to do that in my next meeting. To somebody talking shite, or being treasonous in some other way. Following the offending statement, I’d go all quiet, fix them with a steely stare and, in a deep and steady voice, say “Leave Us”, keeping the stare going, while the others scuffle out, backwards. Now we’re alone. I imagine the room dimly lit, by candlelight or burning torch ideally, but I suppose the dimmer switch will have to do. Health and Safety. I’d arrange the lighting further so only one side of my face is visible, the other in shadow, eye sockets deepened, maybe a bit of stubble. Nobody messes with somebody framed like that. I suppose at this stage it would be appropriate for me to tut-tut ominously, stand up and step slowly the long way around the table (still in half-shadow) stopping behind the seat of my wide-eyed subject. And pause. Unsheath my company pen, fix it purposefully across their throat, lean in and whisper menacingly…well, whatever it is I want to be clear about. “You WILL come for extra hours on Monday” or “I KNOW you took the last of my pink post-it notes.”, it depends. And now, another episode of Game of Thrones. Leave Us!

I got a moment of clarity today on why I am generally against things like maven and spring.

Our project used to be assembled using a massive Builder class. It was maybe a thousand lines long, certain methods had to be called before other methods, to make sure the relevant objects were created in a proper sequence, and it was hard to follow. Spring advocates asserted that this abomination would be solved by going the Spring route.

Around the same time, our build was becoming unmanageable. Specifically the number of dependencies was getting too large, and too complex to understand. We had jars shared across projects, and ran into divergent needs. Maven advocates asserted that this abomination would be solved by going the maven route.

Both situations have something in common. In the first, the Builder abomination was telling us “your app is too complex, split it up, or simplify it”. In the second, the awful build script with all the dependencies was saying the same thing – “your app is too complex, split it up, or simplify it”.

In both cases we experienced pain, we knew something was hurting. But rather than listen to the pain and try to understand what it was saying to us, we chose to medicate the pain away using tools.

Maven kinda seems to help with dependency management, with declarative and transitive dependencies, but now we have a 50MB WAR file. It contains libraries totally unrelated to what we are doing – like jfreechart and we chart nothing – that come in transitively and are never used. Few people on the team know this, or seem to care. Mentioning that we have such a fat app is met with a shoulder shrug. We prefer to keep away from the pain.

Similarly, now that we’re on Spring, there is no single horrible Builder class that you swear at every time you have to change it. Instead there are many smaller xml files, and autowiring and annotations that make the wire-up happen. The organisation has invested in an artefact repository with people looking after it etc. All these smaller parts and activities seem to feel less painful. But I think the sum of pain is at least the same, the complexity is at least the same. But it all has the seductive quality of being less in our face.

So as I sat there today for several minutes watching maven download jars, I realised I want the pain that its shielding me from back in my face. Don’t medicate me away from pain with these abstractions. In the human body pain is feedback calling attention to something that needs to be fixed. The wise response is to pay attention, not to medicate. So this is why I am against maven and spring and the like. They attempt to cover over things that I want direct contact with, things that I want to feel, things that give me feedback. If my app is hard to configure, I want the feedback. If my app is a 50MB war with a ton of dependencies, I want the feedback.

So I’d prefer to strip these things out and get more down to the metal. It would be painful, certainly, but I’d welcome that. The app would be the better for it.

“I think we should use Spring.”
“Over my dead body…”

“Maven is the only way to go.”
“Maven makes me want to hurt people…”

“I think we should have simple data objects and put all the logic in services.”
“No way, Eric Evans is a god and you need to read his bible…”

I’ve seen, heard and been involved in too many of these “discussions” recently. They’re wars really. I’ve not seen one come to a satisfying close. At best the warring parties walk away from each other without coming to blows, grumbling about how stupid is the other, and go on with whatever approach they happen to prefer anyway – the “right” way.

The damage from these kind of wars can be contained if they are across teams, but when they are between team members it can destroy the team. If half the team wants Spring, and the other half don’t, it can make for some very awkward pairing, “code wars”, terrible morale, and impaired productivity. And a loss of that very precious life experience – happiness.

For a long time this bothered me a lot, and I banged my head trying to find a solution. Surely there is some way “we can all just get along”? Well, recently I’ve stopped. I saw that there’s no point. There is no solution. Because there is no problem. Some people like Windows, some like Linux, some like OS X. Is there a solution to this? No, because its not even a problem. Its a blessing. A Linux die-hard could be a Linux die-hard for life, and good luck to them. Some people prefer BMW, some swear by Mercedes Benz, others by Skoda. Some people are Hindu, some are Protestant, others Muslim. Good luck to the lot of them.

Therefore, coming back to software development, its more important, in my mind, to be honest about a team’s tooling and development culture, and to hire members that fit.  If a team is all about Spring, there is no point hiring a developer who openly states that they hate it. If a team is all about domain driven design, there is no point hiring a developer that states that separating data objects and service objects is the only way to go.

And for you as an individual developer, you need to be honest with yourself and with others about what your instincts are, and find teams in which you’re a fit, rather than an annoyance. And if you do hate Spring (presumably with reason), be honest enough to say it. Have the courage of your convictions. There can be a fear accompanying this kind of personal honesty that makes you think “damn, if I say I hate Spring, maybe I won’t get this job I’m interviewing for. Or maybe they will think I am close-minded.” Well maybe you won’t get the job and maybe they will think you’re close-minded. As long as you know your reasons for hating Spring, then you can rest assured that you have made a personal, informed choice. As for not getting the job, well – phew! – you’ve saved yourself and the interviewing company much unhappiness, and you stand a chance of finding a team on which you’ll flourish.

One qualification that is essential to add, and which keeps open the door to development and learning, is this: any individual or team that finds themselves aligned to a particular approach must still be open to listening respectfully to advocates of other approaches, and maybe even being friends with them 🙂 Keep questioning and reading and studying and talking to people and trying things out, and stay honest with yourself, because at the end of the way, maturing as a software developer is never about becoming finally right, but by becoming increasingly less wrong.