IT team meeting about implementing a RAD tool

Are software developers themselves resisting automation?

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!


LANSA Hybrid Low-Code solutions are fast to deploy and easy to maintain delivering outstanding value for any application development project. Ready to get started?




Recommended Posts

3 Comments

  1. I think there is also the issue of future work… search the job boards for LANSA jobs. Once you have used LANSA for 5+ years and your html/css/JavaScript skills are outdated, who will hire you, and what will your salary be now that you need time to “catch up”?

    • Hi Steve, thanks for comments.

      Recruitment officers at end-user companies should prefer to hire IT professionals who can show achievements that prove they have the experience in using technology to make the company more efficient and profitable.

      Example section from a CV of IT professional A:
      • “Spearheaded the implementation of a Rapid Application Development platform, which is now serving as the framework for the company’s next generation of web application development (producing the underlying JavaScript, CSS, JSON and C+)
      • “Worked together with users to design, develop and implement a Web-based xxx solution that improved the yyy rate by 25% and reduced error rate by zz %. I was responsible for both the server-side and client side functionality. The solution was deployed across multiple device-types and browsers and delivered in xxx man-hours, well within time and budget.

      Example section from a CV of IT professional B
      • 11+ years experience frontend development in HTML5, Ajax, CSS3, jQuery, Javascript, AngularJS, and NodeJS. 3+ years SQL Server and .NET
      • Development, testing and deployment of web/hybrid applications on various mobile devices.
      • Worked closely with QA Team to fix UI & Design Issues & Cross browser Website testing.

      Person B is most likely competing with thousands of developers from Tata, Wipro and other outsourcing companies.
      Person A shows a sought after combination of IT skills and business understanding and should likely receive a better salary.

      Do we maybe have to educate the recruiters?.

  2. As always, there are alternative view. Here’s one!

    Take a look at the progression of programming languages : 3GL -> 4GL -> RAD -> Low-Code. 4GLs were in vogue in the 80s and 90s. RAD tools came of age in the early 2000s and still have a large faithful following today. Low-Code application generators evolved from RAD tools and became mainstream around 2013.

    The ‘languages’ that you list, HTML, CSS and JavaScript, are 3GL scripting tools at best. These tools, when used to ‘hand-crank’ web applications, are used by IT departments whose focus is not on delivering more applications to the business in less time for less money. 3GLs never came with that promise.

    When the focus of any IT department is to make the business more competitive and to beat the digital disrupters at their own game, then the use of 3GLs will have already been superseded by 4GLs, RAD tools and Low-Code application generators.

    There are 100s of RAD and Low-Code tools in use by thousands of organisations today. The skills required to master any of these modern tools is relatively the same – once the move is made away from the archaic 3GL mindset.

    LANSA is one such Low-Code application generator. Having mastered skills in modern day LANSA, you just increase your opportunities to soar with the eagles rather than hanging with the turkeys.


Comments are closed for this article!