“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.
religion. that’s all it is. You rarely have people that say “well I think Spring would usually be the right approach, but for this I think we should roll the IoC ourselves” or the opposite.
Good post.
This sounds familiar…
Well articulated Mike.
Pingback: Tweets that mention Software Confidence » Software development is deeply personal -- Topsy.com
Very true. I agree that the preference of tools and technologies is not an issue, or it shouldn’t be. However, I do disagree that the solution for this is to hire people that “fit” the team, people that like the same tools as everybody else in the team. This is a mistake, in my opinion. I believe that a great software team can only be made of developers not with the same skills and likes, but with developers with an open mind to try and use not only the technologies and tooling that they like and know, developers who see value in learning and trying out different solutions to the same problem.
@Ricardo , nobody is an “empty vessel”. They shouldn’t be. If a developer tried three projects using agile, and three projects using waterfall, I would expect them to have a preference, and I would hope it would be a passionate preference. For me, I refuse to work in the waterfall way any more, because I don’t believe in it. My mind is closed. I am religious about it. I am happy to say that waterfall sucks. And I consider that conviction a strength. In _the right team_.
Thats my point. The point seems clear when it comes to a process issue like agile versus waterfall. But it also applies to tech. Would your mind be open enough to use BASIC on your next project? Or would you tell the team to go jump in a lake? When it comes to more fine grained decisions like Spring versus non-Spring, it becomes a matter of degree rather than absolutes.
@JaeRae , saying thats it religion is correct. Saying its “only” religion misses the point. Religion is rampant in software development. I have no problem with that. Any religious belief is centered around whats most fundamental, inviolable, precious to the holder. By definition its not objective. I also have no problem with that. We’re not objective beings. We think we are, and in software development, we especially like to think we are 🙂 But we’re not. We’re emotional beings. And its in the emotional part of our makeup that we find the good, “juicy” stuff of life – happiness, love, joy.
Discarding whats most precious to another with the word “only” is not a skillful way to deal with the reality of religious stances in software. Better to be honest about what “faith” you belong to as a developer, tolerate other faiths and expect that yours is tolerated in turn, and then set about finding an environment thats aligned with your faith, peaceful in the knowledge that you know yourself.
@mikeh erm… we’re still talking about software yeah?
😀
Mike,
I understand the sentiment you are trying to express but I can’t help feel you are being niave about human nature and the commercial reality of software development.
Naive to think that an organisation can deal with multiple, opposing viewpoints in one software stack with no issues. Sure, go find a company that says it doesn’t like Spring (good luck with that) but the reality is that even if they are in different teams, there will be issues.
Like it or not but the industry is coalescing around a few frameworks. 90% of java dev jobs will say Spring/Hibernate. Why is this a good thing? It means employers can hire people with skills that are relevant and useful. It means I have useful skills that allow me to go from job to job and understand a large part of their apps since it is using a common framework. And don’t forget that Spring is as popular as it is because it is actually very good.
I’ve been involved in these ‘wars’ you mention. The people saying they disliked Spring/Maven usually say so from a point of not really knowing it or understanding how to use it effectively. I have yet to hear any major negatives against Spring that would mean I would reconsider using it.
The anemic model debate is different and that i think is fine since its more about style/philosophy. These debates are actually useful as they feed into a design of a system that needs to be agreed and their is no clear right or wrong answer.
Bottom line, if you are working for a company paying you money, and you choose not to use Spring when the app meets the Spring sweet spot, you are doing them a disservice. You are going to write code that does not need to be written and that’s a terrible waste.
@Rakesh – Hiring people because they’ve had experience of frameworks believing them to be skillful is what I would call naive. In my experience people who build apps using various frameworks, bring components into a system that may not be required, but do so because it’s ‘easy’.
The clearest example I can think of is pushing data into a database, even though it can be sourced from another system. I’ve seen many examples of data duplication in organizations justified by ‘trust’ issues (we don’t trust they’re data so we’ll store it ourselves).
I also believe that the riskiest/hardest part of a system to develop/understand is not usually the wiring or infrastructure, but the domain itself. I don’t think any experience of a framework will help in being able to express that clearly. That’s why the paired interviews we use focus on building a domain model – not a webapp or messaging system.
In the meantime I’ll continue to get jobs sorting out problems where development teams have gone framework heavy and forgotten about building any kind of sensible system.