The Code Generation Dilemma

The Code Generation Dilemma

“That’s great, but what do you generate?”

We hear this a lot at LANSA from prospects.  Companies are scared to death to move to something which doesn’t generate C#, or PHP, or even RPG.  Here’s the problem: they’re looking in the wrong direction.  I’ve seen advertisements for ‘low-code’ development environments. One vendor even espoused that “10 lines of code generates 10,000 lines of C#.”  On its merits alone, that claim seems pretty impressive.  Generating an application that fast would have most CIOs drooling at the prospect.  What these vendors don’t want you to think about is this: once it’s live, YOU HAVE 10,000 LINES OF C# TO MAINTAIN.  That’s right, 10,000 lines of code you didn’t write, that is probably completely unstructured, that I guarantee will be undocumented and that will be sticking you behind a massive 8-ball of maintenance.  You need to look past the initial claim to see the total cost of ownership in purchasing a tool to help you build applications.

When looking into the total cost of ownership, the total software development lifecycle (SDLC) is what’s important.  If initial development of new applications is 10% of the SDLC, the last thing you should worry about is how long it’ll take to develop an application.  The primary worry is what happens when you need to change the application.  It doesn’t matter how much time you saved putting the application together if you need to spend three to five times the amount of time and money maintaining it.

Think from end to beginning

What you should be asking: how much code do I need to maintain once the application is live in production?  Are different skills required to maintain the application after development?  If the answers are, “a whole bunch more code” and “many, many different scripting languages” what exactly did you achieve?  You deployed an application out the door quickly (which is good), but now you have two choices.  One is to hire a separate team to maintain, debug, and enhance the application you wrote.  The other is to continually re-write the existing application as new needs arise from the user community.  Both open Pandora’s box of either escalated IT costs and/or application generation errors.  You won’t win.

Users don’t care about technology

That’s right, the users don’t care.  I could care less what language www.amazon.com is written in.  All users care about is if the application is easy to use and when they want something new, it’s easy to enhance.  It’s easy to follow what’s trendy, but times move, trends die and IT can be left holding the bag.  Find a tool for your staff that makes the SDLC, the ENTIRE SDLC, easy.  Find a tool which operates on the same level with development and maintenance.  If you write 10 lines of code, you should only be asked to maintain 10 lines of code.  The tools are out there.  You just need to buck a few trends.  The users won’t care.  When you find the right tool, smiles will abound.  You’ll be lowering total IT spend which makes finance happy.  You’ll have fewer people to hire to maintain the application, making HR happy.  The new applications will be quick to change, making the users happy.  A perfect fit.  How often can you please three sets of people in one day?

Grant Smith

Author: Grant Smith

Grant is the Director of Sales, Tools and Solutions for LANSA Americas. He has over 20 years of experience in the technology marketplace both in the US and abroad − working with hundreds of companies to assist them in gaining real business value from their software investments. Grant has spoken at numerous industry events such as COMMON, COMMON Europe, DevCon, and other user groups across the country.

Leave a Reply

Your email address will not be published. Required fields are marked *