Guys, give me a little credit here, please. I am not talking about getting push back from developers in instances where you approach them with vague requests for features that don’t have a usage case. I am not talking about asking for features that are in the application already. (Step 1: peruse the helpfile/manual. Step 2: Ask on the forums. Step 3: e-mail dev and ask if feature exists.)
Let’s put some concrete examples on the table here.
Example 1) So I have a point-of-sales system that is trying hard to evolve into a “manage all the things” kind of application. CRM, ERP, inventory management, accounting, etc. Our company has been using it for ~20 years, and are one of the largest deployments. We have paid for features in the past, driving functionality changes that were long overdue.
We pay our bills on time, we pay extra when we have a feature request. We have a dedicated on-site body just to deal with this application, he knows the ins and outs, he knows the developers, he knows enough about databases, programming and systems administration to properly convey “what we want to do” into the appropriate dialect fo nerd.
For business reasons, we changed out payment provider. The extant payment provider was costing us a great deal of money, and wouldn’t allow for many advanced features like online payment integration, etc. This was a long process that took the company months and tens of thousands of dollars.
A year later, we approached the developer about the possibility of integrating the point-of-sales system with that payment provider. We had never done payments directly from within the software before, but were hoping to begin such. We offered a Big Bag Of Money, provided a gigantic pile of API links, and even put them in touch with the geeks from the payment provider who were eager and willing to work with the POS devs to get this done.
The POS devs flatly refused. “We integrate with [the payment provider we binned a year ago.] If you want to use a payment provider from inside of our software, use them. We don’t care why you don’t like them, change your business around because we have zero intention of ever providing support for another payment provider.”
I was *floored*. I brought it back to my CEO who then escalated this within the dev’s company. No dice: the response was “adapt to us, we will not add this feature for you.”
Sot he Big Bag Of Money is going into a pot that will hopefully soon allow us to ditch this application, and move our POS/accounting/etc. package to that provided by a better developer. (And no, the developer didn’t come back to us with “give me more money.” Money wasn’t the issue. They just weren’t going to do it, no matter what.)
Example 2) An industry specific application was developed with a very narrow usage case in mind. Essentially: it was coded for the desktop environment of the developer in question, with the idea that end users would always be single entities. The database and its attendant front end were single-user, the netcode so bad that nothing you could ever do would cause the thing to read files over the network faster than ~2Mbit.
Almost immediately, people with more than one body that had to use this program ran into problems. Multiple people needed to be able to access the database from multiple PCs. Businesses larger than “the one man shop” needed to be able to make use of division of labour such that one body could be dedicated to order tracking, one to reordering one to database input, etc.
The developer was offered a Big Bag Of Money. The dev was given concrete, specific requirements, including links to APIs, relevant libraries (and the licensing requirements of each,) they were given specific usage cases and everything that I as a developer myself could ever have asked for to “do the job right.”
The developer’s response – and I kid you not – was “change your business practices.” The developer said that he just wasn’t going to support that kind of environment. If you had more work than one person could handle, simply divide it in two. Each person with a completely isolated, dedicated instance on a dedicated box.
Individual A would be responsible for records on system A, and individual B would be responsible for records on system B. If you wanted to get hold of information contained in A, then you would have to talk to the individual responsible. They would do absolutely everything regarding records in that database.
Absolutely, incomprehensibly, world-endingly INSANE.
That sort of ethos wasn’t acceptable in the 90s, let alone in today’s massively interconnected world! But, it is quite literally the only piece of software that does anything remotely like it, so the developer gets to do whatever they want.
What did I – the dirty network admin – do? I set up a virtual server with a dozen VMs, put an instance inside each of them, then created a middleware website that tracked which VM contained information on which record. I then ensured that anyone in my client’s organization could RDP into those VMs in order to look up/change info. It wasn’t pretty, but he end result was a multi-user usage environment.
The developer was *NOT AMUSED*. Again, this – like most instances – wasn’t a matter of “not offering enough money.” The developers simply won’t budge, no matter what is offered. In this case, there were multiple companies willing to pool money and resources to Make This Happen. Money WOULD BE FOUND if that were the only issue: without this software, the job simply couldn’t be done.
In the end, this group of companies put their money towards hiring a pile of their own developers and have not only written a new application that does everything $stubborn_developer’s app did, but very nearly has met all the feature requests of the group of sponsoring companies.
So stepping back from the hypotheticals and the “well, users and their specifications are never good” and all the developer horror stories, here are a pair of concrete examples of why devs have gotten under my skin for my entire career. I have more. Many more.
I have done development involving scope creep. I have gotten requests for features that already exist. What I don’t get is a developer denying a feature request that has a solid usage case and is legitimately backed by a Big Bag Of Money. Developers who say “alter your business practices to suit our software” are, IMHO, the worst of the worst that IT has to offer.
They are right up there with a network admin who flat out states “it cannot be the network” and doesn’t even check.
There are good devs, I am sure of it. The guys at Plex are a beautiful example of developers with the perfect attitude. But they are, in my personal experience, rare. I recognize that my personal experience does not necessarily reflect the real world – I haven’t experienced all of it, have I? – thus why I am trying to overcome my prejudices rather than caving in to them.
I am sure you all have horror stories of your own that have caused you to become prejudiced in one way or another. Have you never found it hard to look past those frustrations? Am I alone in having to work to overcome the sum of my past bad experiences with $class_of_IT_geek? The often divisive nature of inter-disciplinary rivalries in IT would seem to suggest otherwise…