Dealing with Software Religious Arguments and Architectural Zealotry
Sponsored By
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
Hosting By
This topic hits a little close to home when we onboard some new developers, so chiming in. As both a developer and sysadmin at Stack Overflow, I help coordinate our tech stack and keep everything running smooth. The sysadmin side gives me more perspective than the developer side ever did on the platform issue. In our history we have ventured into platforms outside our norm and have regretted it pretty hard - but not from a position of zealotry. We have also adopted new platforms along the way (elasticsearch, redis, go, etc.). I have a dev pitching a good use case for F# now, and I think it'll be a great addition.
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.
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.
In my experience Enterprise Zealotry can be painful.
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.
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.
In general I try to avoid those types of dilemmas by sticking to a strict set of technologies. However, at times it is true that the Zealotry can emerge when attempting to make decisions.
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.
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.
An easy mistake the Zealot often make is Dunning-Kruger effects. This is hard to avoid particular you believe yourself is one of experts in your area. Some developers like "waste" their time on other technology which can expose yourself for some great concept. For example, as a .net developer you can try go, erlang etc. No matter how good the technology is, it always has limitation. You may write thousands of lines to overcome this however it may just few lines for others. We're lucky as a developer in the current world. Programming now is much easy job. However, we're also unlucky, we face a fast changing world need us spend a lot of time to catch up what's the next. However, if you stay open, you can learn more concept and usually these things do not change that fast. A technology company no longer become success because how good their technology is, usually it has been decided how good the community accept their technology. Every company has their own community/customers. If developer think themselves just a customer, then the requirement is need from a opensource project or a technology company is really about the service you supplied. Then why you crazy with bad service?
I'm trying really, really hard to be an atheist, and to proportion my belief to the amount and quality of the evidence.
I believe that demonstrating a consistent history of being committed to improvement, humility, and an appreciation of the other person goes a long way. Authentic humility and appreciation for others cannot be faked, which is what makes it so hard.
I regularly read Scott's blog, but this is one of the worst pieces from Scott.
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.
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.
Tech zealots often overlook business and practical considerations in their choices. I once worked in Japan and a colleague was always harping on about dumping the PCs and getting Macs (in 1990s) because these were better for Japanese (true, at the time). No consideration of the cost and disruption to the company for fairly minor benefits
You didn't even mention tabs vs spaces. Loser!
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.
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.
Make sure the discussion is about achieving the same goal (contributes to company vision and mission, project deliverables). Often these discussions never end because persons defend standpoints for different goals. It's pointless to defend that an apple has the best apple flavor (which is true) if you need to make pear juice
In they end they are all tools. And the tools must fit the job at hand.
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 ;)
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 totally agree. Everyone has their own opinion on things. I've had long meetings talking about C# style and standards.
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 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 personally call these holy wars, for the same reasons - everything thinks they are right and in the end everyone loses.
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
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
I once tried to convert an entire team of Cobol programmers to Smalltalk in the early 90's.
That was fun.
That was fun.
There are many ways to achieve something and you have to find the way that is best for you. You choose what's best for you and the quality of the result depends on you mainly and not on the tools.
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.
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.
in general, a software guy judges technologies based on his own technical experience path (technology X joys & technology Y pains), which inverted his choise criterion's priorities :
#Scalability, #Granularity,#Portability, #Performance, #Openness, #LowLevel, #NewAgeTech, #criterion1, #criterion2 etc...
#Scalability, #Granularity,#Portability, #Performance, #Openness, #LowLevel, #NewAgeTech, #criterion1, #criterion2 etc...
What hurts is when your church (Microsoft) kills your religion (Silverlight) and proposes new theology (HTML5/CSS3/JS) promising to base a religion on it.
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.
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.
> 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
That's always the first thing I notice about the religious - how open to celebrating different points of view they are!
That's always the first thing I notice about the religious - how open to celebrating different points of view they are!
Never let a "guru" tell you what to use. How often have we heard that the only way to survive is to use the new "JavaScript Framework 2000-Plus-Gold-Edition" which nobody remembers the day after? Those who are obsessed by a specific technology should learn to say "I'm using 'JavaScript Framework 2000-Plus-Gold-Edition' - it worked great for my application; maybe you want to give it a try, it might work for yours too.". It sometimes almost feels like back in the days where we fought about Amiga vs. Atari ST...
(...where it was obvious that the Amiga was better! ;-))
(...where it was obvious that the Amiga was better! ;-))
To be fair - if all you infidels would just use C# we wouldn't be in this mess!
;-)
;-)
How very appropriate that this post should show up in my feed yesterday.
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 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.
Ahhh.... The intersection of technology and dev teams. When working with people (and yes, believe it or not, devs are people too), it's probably best to think of devs as people first and devs second. Zealots, with their investment in being "right" in their devotion, can be resistant to other approaches. Making zealots "wrong" or trying to sway them frequently isn't the quickest and best way to move ahead in the endeavor.
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.
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 echo Unfrozen Caveman Developer's point of view. I've given up trying to improve software development because most of my coworkers don't understand it, and when I try to explain they just grunt and say "global variables are easier" and we should stop arguing because there is no one right way to write software.
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!)
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!)
Just do it my way and no one gets hurt ;)
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.
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.
@Rehan Saeed: "Everyone has to adapt to it, nobody 'wins'."
Have you tried Ctrl-K Ctrl-D?
Nobody has to adapt. Everybody "wins".
Have you tried Ctrl-K Ctrl-D?
Nobody has to adapt. Everybody "wins".
Hear, hear. And you can make great apps with Web Forms and VB.NET as well
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.
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.
For many developers, the hierarchy is:
(If you don't believe me, just look at Linux.)
For business, the hierarchy should go like this:
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.
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.
Oh, Scott!
You've fed so many intolerant trolls with this post. Just look at Jan and the likes of him.
You've fed so many intolerant trolls with this post. Just look at Jan and the likes of him.
We still use classic asp. We had to write our own unit testing framework, figure out how to integrate that with Jenkins, and write com interop around our database and logging and memcached .net objects. But at least asp never changed under us :-P The big motivation to make a concerted effort to get rid of it is that Application Dynamics doesn't work with it.
@Nick Craver, have you heard of edge.js? It lets node and clr run in a single process together. Could ease your logging issue
@Nick Craver, have you heard of edge.js? It lets node and clr run in a single process together. Could ease your logging issue
Zealots in Programming Languages or Framework are quite straight forward bring back to reason: As there is not yet any perfect Language or Framework, the only possible rational answer is that each has it's strengths and weakness due to the fact that have been developed making many (probably too many) compromises.
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>
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>
When there are nazi DBAs then you use their stored procedures and shut your mouth!
The important thing to remember is that many people (especially developers) have a large amount of subconscious knowledge which they have difficulty explaining. If someone is really enthusiastic about a technology but can't quite explain why, they probably do have really good reasons, but they can't put it into words. Often, over years, you come to conclusions about technologies with hundreds of reasons, and the human brain is very good at trimming out the useless knowledge ("How we reached that conclusion") and storing the minimum ("The conclusion itself").
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.
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.
I try to be rigorous about not being a zealot myself. About the only things that still get me going are trying to capture all the requirements up front and anti-vaxxers. Both send me into a bit of rage mode.
It becomes especially fun when a group who really knows little about Technology X wants to exert influence. Say, for example, an Enterprise Architecture team who tells a Delivery team to use Technology X not because it is the right answer, but because we as an organization have invested $12.5m in it. So it gets built and deployed, it doesn't scale or is difficult to deploy, doesn't support some key requirement or worse.
But, then, that is an extreme thing that never happens in the real world, right?
But, then, that is an extreme thing that never happens in the real world, right?
How do I weather the storm of religious zeal? Mostly, I sit and grumble at my cubicle, writing stuff in newer technologies that improves my own ability to work, even if the team doesn't adopt it. In other words, I try to let my work speak for itself. If something I've done is worth adoption, then I let that be my motive. If it isn't, then I let it fester, or let it continue to help me and me alone, making little improvements and tinkering all the way.
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.
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.
Sometimes it may be due to the inability of the zealot to learn new ways of thinking, structuring a solution, different syntax, and it may also be a sign of 'ineptness'.
Anyways, it's definitely not a good sign in a manager/candidate/programmer.
Anyways, it's definitely not a good sign in a manager/candidate/programmer.
Software architecture is almost never about the technology itself. It's about the existing culture (is it an engineering firm or just get-it-done-by-any-means-necessary), current and future staff capabilities (availability of senior developers), current technologies within the company, cost associated with any changes (or non-changes (sticking with an old framework no one understands)), and gaining consensus.
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.
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.
This post is brown belt. Here's the black belt master secret...ready...wait for it....
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.
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 struggle is that I am a zealot! It is just against Java.
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.
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.
Black belt insight #2:
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.
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.
As someone who made the mistake of being zealot for far longer than I care to admit, I can say that often (or at least in my case) it comes down to fear. Until recently, I was convinced that .NET and accompanying technologies were the only viable choices for enterprise solutions because... I was afraid of what I didn't know. As a result, it was easy to default to "Blah blah technology is the worst because blah blah unfounded statement".
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?
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 always believe technology is for getting things done. So choose the technology which makes sense for you and you have expertise in that particular technology or you team has expertise in it. I know that there are other factors also. But this is a just starting point.
I've recently made the jump to a solutions architect and I found this post very interesting.
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.
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.
Well said, Scott. I'm a .net developer during the day but at nights I play with Ruby, Python, and the new shining javascript library. Learning about other programming languages allows to be open to start new projects and being open to new opportunities.
Very interesting. I was thinking about this the other day, although my thoughts were pretty much based on the concept of software tribes. To me it seems that us "programmers" tend to tribalise around technology stacks. i.e. .net Tribe, Java Tribe, PHP Tribe , Ruby Tribe.
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?
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?
Very good point, as usual.
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 ..
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 ..
You argument is correct except You can't find a level A programmer who prefers to code in .NET to anything (JAVA, Ruby, Python, NodeJS, Go, Scala, PHP, ...) for any project. trying to solve a problem with .NET or any other Windows Solution is like trying to learn to dance while wearing a body cast:
Last sentence is quote from How to become a Hacker
Last sentence is quote from How to become a Hacker
@Mani: "trying to solve a problem with .NET or any other Windows Solution is like trying to learn to dance while wearing a body cast"
Are you being intentionally ironic - considering the subject of the blog post - or are you really this silly?
Are you being intentionally ironic - considering the subject of the blog post - or are you really this silly?
@Mani: and the proper quote is: "Trying to learn to hack on a Microsoft Windows machine or under any other closed-source system is like trying to learn to dance while wearing a body cast."
How embarrassing for you. :-)
How embarrassing for you. :-)
Sometimes fanatical zealotry is baked into the platform. For example, if you need to do something totally normal - say, look at the source code for your operating system (Windows) - you're facing an insane cult that actually has the power to use real-world coercion to block you from doing that. Seriously, they can _call the police to prevent you from seeing or distributing the source._ Shocking, but true in many countries.
Working with the full Microsoft stack for the last 10 years, I was pushed into the Node.js world in my last job, and that introduced me to the open-source community. It was such a contrasting experience to work day to day with people of a completely different mindset.
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?
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.