Handling Objections

Often times developers get set in their ways. We like our “norm” and don’t like to change things up all that often. Don’t get me wrong, many of us — perhaps most of us spend time with the “framework of the month” but usually wind up falling back into our platform of choice. I remember when I was fed up with all the various frameworks within the Java world and someone showed me CodeIgniter for PHP. I jumped ship as soon as I could and for the longest time nobody could sell me on anything else. I’d tried rails, and grails, and while those were “fun and new” I was just not as productive or enamored with what they supplied me. From there, someone showed me Django and though it took quite a while for me to gain an appreciation for it, I eventually crossed over. The frameworks were all similar enough in concept to keep me learning at a good pace and eventually it became my framework of choice.

Recently I was a “fly on the wall” during a conversation regarding the introduction of the Salesforce platform to a team of largely Java/Grails developers & while the voice in the room was playing devil’s advocate, he was simply spot on regarding some of the objections that his developers were going to throw at him. As I sat and listened intently (as I’ve been down that road before) I started to think of how I may respond to some of the objections.

  1. I don’t want to be locked into a frameworks way of doing things: lets be honest, there is not a single person on the planet that is part of a Java project that isn’t currently submitting to some framework’s way of doing things. You’re likely using Spring, JSF, Hibernate, etc. You’re doing things the frameworks way already, you’re actual objection is:  “This is new and I’m not used to/don’t want to learn something new.” The beauty here is that if you’re comparing it to Java — the languages are extremely similar and the front end templating is definitely nothing new if your used to jsp tags, JSF, etc. There is no lock-in here that you aren’t already experiencing. When you use a framework you’re accepting its way of doing things. This is no different than what you’re already doing, its just a different “lock.”
  2. Licensing costs — we currently have none: While this is true if you’re not in the .Net world, you likely don’t have licensing costs but you have server upkeep costs. Whether you colocate, outsource entirely, or have your own server room, there is quite a bit of cost built into maintaining your installations, configuring your app servers, locking down the security, applying patches, etc. And lets not forget how much “fun” it is troubleshooting JBoss stacktraces, load balancing your database servers etc. If you’re a server guy, great — you lasted a heck of alot longer than I did, but if you’re DevOps (by force) wouldn’t it be nice to focus less on the Ops and more on the Dev?  While I’ve not run any numbers, I’d bet that once you figure in maintenance of your servers, the licensing isn’t as bad as you’d think. (Lets talk High Availablity, redundancy, failover, disaster recovery another time…*ouch*)
  3. I like to build my front ends from the ground up: So do many people, and many still do. I still haven’t fully submitted myself to Visualforce and often times layout pages with standard HTML. I use JS libraries, stylesheets, the same tools that straight up HTML5 guys are using. The Salesforce platform allows all of this — and guess what? I’ve still managed to learn a thing or two outside of the platform.
  4. We already have a system in place that works for us: That’s great news, but should that force your company into doing things the same way even if given evidence of perhaps a better way of doing things? Shouldn’t you at least want your company to attempt to improve? It may very well be that your way is better, but a company that doesn’t at least explore other avenues in a quest for improvement is doing itself — and its employees — a huge disservice.

In the end we developers are a finicky bunch. We like what we like and many times we can’t really tell you why, or when we do — our arguments seem purely emotional and not always logical. As a developer, I’m trying to keep an open mind about things, and I’d like to think I’m fairly good at that most of the time. After all, I left Django and decided to learn the Salesforce platform. Yea, sure there are things I really miss about Django, but if I went back to Django, I’d miss things from Salesforce. Its about learning, the experience in trying new things. If you’re argument is that you don’t want to be pigeonholed into another framework but then only offer up your “goto solution” — aren’t you already pigeonholed? #FoodForThought

 

:wq!