Dealing with Software Religious Arguments and Architectural Zealotry
Warning: Excessive use of Capitals for Emphasis ahead.
A friend of mine left his job to start a medical startup and has been in the middle of a Fight Over The Tech Stack. The current challenge is very bifurcated...very polarized. It's old vs. new, enterprise vs. startup, closed vs. open source, reliable vs. untested. There doesn't seem to be any middle ground.
Sometimes fights like these start with a Zealot.
Zealot: a person who is fanatical and uncompromising in pursuit of their religious, political, or other ideals.
Not all, don't get mad yet, but sometimes. Sometimes a Technical Religious Zealot is on your team - or runs your team - and they can't make objective decisions about a particular piece of technology.
"Don't use Microsoft, it killed my Pappy! Rails? Please, that won't scale. Node? Maybe if you're 17 that'll work! The only real way to write right software is with Technology X."
The language may not be this overt, but the essence is that Software can only be built This Way.
Here's the thing. Lean in. There's lots of ways to build software. Lots of successful ways. In fact, Success is a great metric.
But there's a lot of crappy Java apps, there's a lot of crappy C# apps, and there's lot of crappy Technology X apps.
Enthusiasm for a technology is understandable, especially if you've had previous success. I've worked in C++, Pascal, node.js, Java, and C#, myself. I've had great success with all of them, but I'm currently most excited about .NET and C#. I'm an enthusiast, to be clear. I've also told people who have hired me for projects that .NET wasn't the right tech for their problem.
Be excited about your technical religion, but also not only respect others' technical religion, celebrate their successes and learn from them as they may inform your own architectures. Every religious can learn from others, and the same is true in software.
Beware the Zealots. Software is a place for measurement, for experience, for research, and for thoughtful and enthusiastic discussion. You or the Zealot may ultimately disagree with the team decision but you should disagree and commit. A good Chief Architect can pull all these diverse architectural conversations and business requirements into a reasonable (and likely hybrid) stack that will serve the company for years to come.
Dear Reader, how do you deal with Technology Decisions that turn into Religious Arguments? Sound off in the comments.
SOCIAL: Hey folks, please do follow me on Facebook https://fb.me/scott.hanselman or Twitter! https://twitter.com/shanselman
* Photo "Enthusiasm Rainbow Gel" by Raquel Baranow used under CC BY 2.0
Sponsor: Big thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls. Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
We have written internal apps in node.js and later ported them to C#, for several platform-based reasons. For example: exception logging we have centralized with StackExchange.Exceptional, profiling we have with MiniProfiler, SQL insane perf we have with Dapper, and in general SQL Server AG support we just have robust support for on the .Net platform.
To support node.js (our real-world example) I need to either setup a separate service to catch exceptions (we had a tiny REST service) or maintain a separate tech stack for node.js and update them lock/sync with schema changes, etc. MiniProfiler we'd just have to port (this happened). For SQL perf we just have to deal with whatever drivers are out there (we did improve them and upstream), or support another data store entirely. SQL Server AG support was just a non-starter at the time since Microsoft doesn't exactly implement TDS correctly and node.js crashed when we failed over nodes.
That's some of the major the tech bits, which do matter, but there are more important things. I have at my disposal one of the best .Net developer and debugging teams that exists...and I'm throwing all of that experience away by shifting platforms.
Can it still be worth it? Yes, absolutely. But it needs to be worth it.
We're not loyalists here. The moment something better comes along for any piece of our architecture we'll jump ship. Times change. Information will change. Decisions can and should change too.
Use the tech you use because it makes the most sense (often that includes: what are you good at?). There are legitimate reasons not to move platforms, but that doesn't justify zealotry - the reasons for not moving are just that. When reasons to move outweigh those: move, and have fun doing it.
There's a genuine argument to not be on the bleeding age of technology when you're looking for something stable, but recently I was aghast to hear a Solutions Architect refer to REST as too new to be used on a project. I had to bite my tongue unfortunately.
Ultimately you have a few choices.
1. See if you can compromise. Build a relationship here. You'll win some and loose some arguments.
2. Have an evidence based approach. "Technology X sucks! Prove it!" I worked with a developer who refused to use ORMs because he insisted they were too slow. I asked him to prove performance issues. He never did. We've been using ORMs on all our systems for 5 years now.
3. Move on. Not an easy decision but sometimes it happens.
One of these that I have seen and a few times been part of is the comparison between using an arduino and a raspberry pi. While both devices are very adaptable and awesome, somehow the discussion always seems to degrade into a comparison of what is possible with c++ versus python. At which point there are many tangents it seems, IDE's come in to play, as well as scripted versus compiled, and even it seems a Microsoft versus Google aspect can arise due to the integrated use of pi with Android and C++ being a Microsoft technology.
I think dealing with the large amount of available tangents is best accomplished by acknowledging the core advantages of the topic as opposed to getting too far down the rabbit hole. I like your point about recognizing success, because in this example, there are many places to point to as successes for both arduino and raspberry pi; unfortunately those can be overlooked when people become to set in their belief of which is best.
All technology has its niche, and the best way to give a nod to one or another is to simply evaluate how well that technology fits into the niche at hand. One problem with attempting to do that though is real life constraints. There are many teams whose zeal is related to an unwillingness to change versions. Some legacy systems come to mind, especially in c# where I have seen examples of teams who were not allowed to upgrade far enough to use LINQ. Sometimes, in order to present a good argument in these cases, a lot of evidence is required, and that aspect of dealing with these situations can be very complicated in large systems.
tldr; I try to stick to a comparison of advantages, and try to be prepared to offer examples which highlight those advantages.
It's great that Scott used the word "religion" in this context, because it is exactly the right word for what he means. Interestingly, in a surprising way.
"Enthusiasm for a technology is understandable" ... "Be excited about your technical religion, but also respect others' technical religion"
First, religion (the actual religion) is exactly the last thing to be respected. We should respect each other's culture, privacy, each other as a person and a human being, each other's reasoning, but definitely not the religion. Religion is irrational belief in things that would otherwise be silly. Sorry, no respect for your belief in an invisible man who listens to your prayers.
Now, Scott says that "Enthusiasm for a technology" is like a religion and should be respected purely on the grounds of religion; new technology should be respected just because somebody is enthusiastic about it. Sorry, it should not.
Of course, that works also the other way around. If somebody is trying to solve a real problem and it happens to be needing a new technology, if some senior developer / team lead is religious and his religion is "no new technology", then of course his religion should not be respected.
Introducing a new technology always has a cost. Enthusiasts trying to introduce the new technology better have a good answer to the question what real problem their technology solves.
Unfortunately, I've seen way more religious technology enthusiasts than religious senior developers / team leads believing in no new technology. Interestingly, religious junior team member who believes in "no new technology" is rare, and his religion is harmless.
I think that (as with religion) a lot of these things can be linked to personality. There are people who like new stuff just because it's new, others who prefer to avoid unnecessary changes. You can guess which one won't be suggesting you switch to technology X for the next project.
Similarly, some people are more 'throw it at the wall and see what sticks', whereas others need to be sure everything will work before starting.
In our team, we have both, which sometimes makes working together complicated but generally we manage to muddle through. You can satisfy the 'ooh shiny!' people by letting them use the new technology for side projects, and assign the 'code-first' people to hack out spikes to reassure the 'pimping my plan' people.
But you can hammer in screws and work wood with a screwdriver and sometimes if you have one screw or a small hole to make then you do just that.
If you have 6000 screws then you probably want a power tool.
As with any choice in our field you have to look at the impact of any choice you make and how often your choice will be impacted. Have a couple records to record a day, any type of data storage will do. Have 3,000,000 transaction a second then you may want to be more considerate.
Now if you meet a zealot and it's not hard core, you may want to let it slide. Need 3M transactions (or large memory footprint or latency or problem X) then you probably want to prototype and test.
That will probably fail if product X does not work.
But you will also have to look at how legacy something will become. A throw away app for a couple of years can probably stand a throw away niffty little open source framethingy.
But if you are creating (or upgrading) a core application for lets say a bank then you may need to consider COBOL ;)
I now advocate StyleCop and wrote Stop the Brace Wars, Use StyleCop. It's the quick way to short-cut these discussions. Everyone has to adapt to it, nobody 'wins'.
I fight these by asking for POC's (Proof of concepts) to be built with the current technology and the new technology. With a comparison of the technologies in question, applied to a situation in our environment, we were able to make a list of positive and negative that apply to our work environment. In this way we are always open to new technologies, but the developer has to take initiative and prove their technology.
It was using POC's like this we made some difficult decisions to replace JQuery with AngularJS, replace ASP.NET forms with asp.Net MVC, etc. Some of the changes were hard, but we don't regret any
That was fun.
If you compare the choice for technology with the "choice" of religion, then this is completely wrong. Religion results in nothing good as soon as religion is used to get to a result. If you have a religious believe in the technology you use, then stop programming and start doing something else.
#Scalability, #Granularity,#Portability, #Performance, #Openness, #LowLevel, #NewAgeTech, #criterion1, #criterion2 etc...
I also like enlightening the Java Zealots that they no longer worship the warm and comforting SUN, as it has been replace by an money hungry ORACLE.
That's always the first thing I notice about the religious - how open to celebrating different points of view they are!
(...where it was obvious that the Amiga was better! ;-))
;-)
In previous jobs in my youth, I was the one people thought of as the religious zealot, trying very hard to convince my co-workers to try test-driven development, dependency injection, avoiding global variables; you know, the really incendiary stuff. But it all ended in heated discussion and yielded nothing. Then when I joined my current team a year and a half ago, I decided to just bite my tongue. I had found a good gig working from home. The architect sounded confident in his architecture. Why make waves? I did a small presentation showing how we might unit test our code, helped set up a continuous integration build that ran all the unit tests in our project, spoke up once or twice about the dangers of global static state, and then held my peace. Maybe I was beating this TDD drum too hard. These singletons don't look too bad.
A year and a half later, with about 3% of our code covered in automated tests (mostly written by me when I find something easy enough to test), six months of fixing bugs, a product delivered late with fewer features and performance issues, and whole days wasted putting out fires, I am consumed with doubts about whether I should have fought harder at the beginning for what my instinct told me was right.
Maybe being a zealot depends partly on where you stand in relation to what the zealot believes. Maybe the zealot really knows what he's talking about and is just really bad at persuading others. At what point does avoiding the proof make the other person the zealot?
I guess I'm just getting too old to be working on projects that make the same mistakes over and over again.
In my experience, it often works best to give the zealot the space to stumble. If you don't give yourself or your teammates the space to "fail", you're also robbing them of the space to "learn". Sometimes, yielding is in fact the fastest way to move ahead. It's also helpful to explore what leads to the fervent devotion of the zealot. Sometimes I discover features of the technology that I hadn't fully appreciated.
And, -gasp!-, I may not have the "only" right answer. If I allow the project to be road blocked by divergent perspectives and opinions, then the project is a failure and so are all the players.
I'd say the real problem are the Expert Beginners. They pretend not to be Zealots, while blindly and loudly rejecting every new idea, because we've been doing global variables for 40 years now and it's never been a problem.(well except for all those unintended bugs you can't easily troubleshoot, but that's job security!)
Any technology has a life span and they all die sometime except for Cobol and I think it was probably due to a vampire bite back in the 50's.
Be a technologist first. Save the dogma for your favorite belief system.
Have you tried Ctrl-K Ctrl-D?
Nobody has to adapt. Everybody "wins".
And 3, 2, 1 ... cue the usual bunch of zealots that seem to be following me around ...
Thank you Scott, for I've been reiterating the very same message for over a year now to many fellow programmers.
Uses the latest cool new technology
Fast
Works
Maintainable
Reliable
(If you don't believe me, just look at Linux.)
For business, the hierarchy should go like this:
Works
Reliable
Maintainable
Fast
Uses the latest cool new technology
Almost inevitably, business software doesn't align with business goals, because too many developer priorities get in the way. When deciding on technology for business, be sure to look at the latter list.
You've fed so many intolerant trolls with this post. Just look at Jan and the likes of him.
@Nick Craver, have you heard of edge.js? It lets node and clr run in a single process together. Could ease your logging issue
If anyone does not understand his "Perfect" Language is just the product of compromises taken by its the developers as every other, a few weeks hacking directly in ASSEMBLER - where the only compromises will be his- will surely help him put perspective the relative value of each Language and abandon his Zealotry.
P.S. I am sure that with today massive cloud computing power we could potentially be much closer to the perfect "Language and Compiler" if we had enough computer scientists devoted to developing it and the right incentives. Maybe it's baton for a company like Alphabet.xyz to pursue.</ol>
A recent example: I recently was trying to explain why playing video games remotely via streaming video will never take off, because I was convinced by a smart employee from Valve about it, but I can't remember his reasoning. All I can remember is that I was very convinced at the time. Luckily in this case I am aware of my bad memory, and can remember roughly how I came to this conclusion, but this is often not the case.
Similarly if you listen to 20 talks about a technology and most of them are positive and you come away excited, it's unlikely you're going to remember all 20 talks and everything they covered, you're just going to be excited about that technology in an indescribale way.
But, then, that is an extreme thing that never happens in the real world, right?
I work for a company that still uses CVS (on a Win2k box), Struts 1, FTP deployments, no spec, no unit tests, and no other frameworks for Web development. It's creaky, but we "don't have the time" to rewrite everything, and I understand that it'd take a tremendous amount of effort. So I'm whittling away, writing Selenium-driven integration tests for the changes I make, teaching myself Git and Ruby, and coming up with ways to automate our lengthy deployment process.
The only way to counter religious zeal is with cold, hard facts and staunch evidence to the contrary, and to hope and pray that your efforts convince someone to look back on their zeal in a more critical light. Alternatively, steal away their followers and leave them with nothing left to stand on.
Anyways, it's definitely not a good sign in a manager/candidate/programmer.
But someone eventually gets to pick the direction...if you're that person, don't be an ass about it. Work through concerns and try to be diplomatic about things. If you're not that person, remember you can learn to hone your skills in any environment and managing your emotions is one of those skills.
FOLLOW THE MONEY.
You CAN'T pay your bills with .cs, .js, or .* files!
You CAN pay your bills with the MONEY worth of those .* files which you created.
I've just liberated you. Now you're free to live life like a normal person, and think deeply about things that actually matter.
My impression is that it is bloated (lots of code for little result), difficult to deal with (using tools related to Java), and lacks nice language features.
If someone of offered a job and said I would be working in Java I would probably pass.
Java seems to be extremely popular, so I wonder what it would take to overturn my zealotry. First I would have to learn it better... But my experience so far has been negative.
You are NOT smarter than everyone else. If your tool or technique of choice is not as popular as it "should" be, it is NOT because everyone else is stupid. You are NOT the only developer passionate about being more productive and valuable. Smart people looked at your favorite tool or technique, it was weighed, measured, and found wanting for their problems.
This means that even if you are right about what you are doing, you have made a conscious choice to focus on using a specific tool which is best suited to solve a specific problem. Your career risk and reward will therefore be tied to that specific problem. That can be very lucrative sometimes, but more often not.
Choose wisely.
Recently after seeing Microsoft move towards open source software and exploring it more myself, I've made the realization that there really isn't that much differentiation out there, just different flavors of solving similar issues. What's so scary about that?
I am required to choose the best technology to solve a specific business problem as well as the many associated non-functional requirements, however, I am constrained by several factors that influence my decision. We don't have deep pockets, the developers only have experience in a particular technology stack and we are heavily constrained on time.
I need to be pragmatic. I have to weight on up all these factors and choose the best solution that solves the business problem and delivers the project on-time.
We choose a PJAX ASP.NET MVC approach because our developers are already experienced with .NET and that we already have licences for VS etc, but this wasn't our first choice, we simply did't have the time to re-train everyone and I needed to make a pragmatic decision. Saying that, I am very enthusiastic about the Microsoft C# + ASP.NET stack and am very confident we can deliver a world class solution. It's about providing a successful, cost effective solution that delivers the business needs.
If the architect is a zealot as described and fails to do this then I believe it will all end in tears, and likely over budget and very late.
All tribes are allowed to have some common familiarities .i.e. We can all use Jquery, Subversion, Git and other similar utilities, but the big exception is that we all have to hate what the other tribes do with those tools.
The .net tribes have to hate mac and linux, the java guys have to be cool with mac, linux and tolerate windows. and so on. There does seem to be some really bizaar ground rules.
I for one consider myself to be a new statesman, I don't particularly belong steadfast in any one tribe, and frequently change operating systems and primary dev languages, because quite frankly I get bored, and love learning new things.
I don't think anyone project necessarily needs to stick with any one tech stack. Sure there is concept if we have one tech stack then we only need to employ one type of Code Emitting Unit, but really software products can become better products by incorportaing cross polination ideas from different spectrums.
I tend to want to leave projects or companies when I start hearing the phrases "windows is the best choice of operating system because of ..........." or "Linux is better suited because ......."
My personal view is that modern software solutions need to OS or technology stack independent. Thats my 2c , anybody got change?
Myself is a bit openminded and don't mind trying new techs. But new techs always take a bit longer to get used to, but on the other hand one could be an expert on like one or two techs only or be good/very good on several techs, but do not have the deeper knowledge in them as an expert.
I think the goal of the product you create also matters of course and who will maintain it .. yada yada ..
Last sentence is quote from How to become a Hacker
Are you being intentionally ironic - considering the subject of the blog post - or are you really this silly?
How embarrassing for you. :-)
It also helped me look at things objectively, and helped me understand how to better pick the right tools for the job.
While I was dealing with a lot of "Microsoft-haters" this post actually inspired me to not let it bother me any longer. I decided to move on and actually wrote my own blog post about looking at Node.js from an objective perspective without being suckered into the zealous hype:
Is Server-Side Javascript the Flavor of the Month?
Comments are closed.
Keep asking questions and deep dive what solution will fit the requirements best.
Question all assumptions that do not pass the sniff test or appear biased (only X can do that! Oh really?)
Eventually they will meltdown or they will quiet down. Either way, keep moving toward an appropriate resolution.