Last week I accompanied one of my sales colleagues on a meeting with a prospect. My company provides software application development and integration tools and the sales meeting was with the IT team of an insurance company. The agenda for the meeting was a presentation and demonstration of our low-code RAD (Rapid Application Development) product, followed by a question and answer session.
The presentation was lively with questions from the team and we were able to meet their many ad hoc requests during the demo. I thought we were close to deciding on the specs for a proof of concept and getting a new customer on board.
However, I was quite surprised by the discussion that followed after the demonstration. While some developers welcomed the idea of letting a RAD tool take care of JavaScript and device/browser/database specific ‘plumbing code’, other developers objected strongly and behaved as if we had insulted them.
For example, one developer mentioned that he “didn’t need” a RAD tool, the reason being that he was experienced in coding several languages. Another developer said that he “didn’t like giving away control” to a RAD tool and that no tool could ever meet the refinement of hand-coding. Someone else kept coming up with unusual “requirements” that game developers may need, but that were not relevant to any business application.
I was puzzled. These developers have accepted as their primary mission (we assume/hope) to use technology to help their business users become more agile and productive. Yet, they cannot accept that technology can also help to improve their own agility and productivity.
CFOs don’t mind letting a system do the calculations and predictions. Analysts don’t mind using intelligent tools to mine and analyze data. Pilots don’t mind flying a plane on auto-pilot where appropriate. Doctors don’t mind using computer technology for diagnosis or even during surgery. So, why can some developers not accept that part of their code creation/maintenance efforts, especially the mundane tedious parts, can be automated with a RAD tool?
After the meeting I talked with the team’s development manager and she explained she often feels she has two groups within her team. One is very focused on business outcomes, while the other is more focused on technology. She said that most of the RAD objections came from the second group. She summed up their reasons as follows:
- Coding in new languages and technologies is actually exciting for many developers and they are proud of the code they have developed. They may feel that a RAD tool takes the fun and excitement out of coding.
- It’s hard to accept, especially for experienced web developers, that the JavaScript, CSS, JSON and other skills that took them such an effort to acquire, are not the big career differentiators they thought they would be.
- In the old days, the typical IT career path was from junior developer, to senior developer, to business analyst to head of the IT team or CIO. Along the way you received management training and acquired in depth knowledge about your employer’s industry and business. Now-a-days, IT professionals often opt for a more technical career path. In that case, a long list of languages and technologies looks better on your CV.
We agreed that those reasons do not serve any business benefit, but at least for today there wasn’t much we could do.
So, after that somewhat frustrating meeting, I drove home in my geared car, because driving an automatic car is “not really driving”. Next I decided that the best way to relax and forget about the meeting was to make a pizza from absolutely scratch. Not just the topping, “that would be cheating”, but the whole thing. Who can beat that!
