Generating Code is the Only Viable Path Forward

No, AI Can’t Generate Code

Introduction

Normally we talk about healthcare and/or health insurance in this weekly article, but today is going to be a little different.  Today we are going to detail why just about every development shop on the planet is designing and building software incorrectly and what you should be doing instead.  We will use the usual problem/solution format to show how this process should be accomplished and why.  We will show that the way we build software is the only way to deliver consistent, secure, maintainable, performant applications.

The Problem

Software development is quite a bit more complex than designing and building a car.  If you think about all the parts that have to be designed and built on your car, you start to get an idea of what building software takes.

Schema Design

Databases are a bit of a problem for most developers.  Almost everyone comes out of a procedural code background and really has no idea about set based programming.  Here is an example comparing and contrasting set-based v. procedural coding.  This (lack of) experience puts the designer at a real disadvantage.  Most databases I have seen in my career look like spreadsheets and have little to no normalization.  Here is a discussion about normalization and the normal forms.  Discussions about procedure v. set based and the forms of normalization are beyond the scope of this article, but feel free to look at the sites linked above.

The point of the discussion above is that the database isn’t everything.  It is the only thing.  If an application were a house, the database would be the foundation, the framing, roof and shingles, and the electrical.  Everything else is either plumbing or aesthetic.  Without a valid database design nothing else matters.

This is one of the things that AI can not give you because it doesn’t solve problems, it mimics solutions it has found on the internet.  These are solutions that didn’t work or they wouldn't be given away for free.

Architecture

You may think that this is something that you might have seen Frank Lloyd Wright do, but it applies to software development too.  Architecture is the art of putting the right code in the right place to separate concerns and avoid code duplication.   It is harder than it sounds.  In the “solutions” section we will discuss the way we design the generic application so that we are halfway done on the first day of development.

This is another thing AI can not do for the same reasons above.  Most of the examples on the internet that AI has been trained on detail architecture in pictures, not code.  AI can’t make the leap from a picture to code.  

Security

Security has to be designed in from the beginning.  You can’t tack on security after the fact, ask anyone who has had a data breach or ransomware attack.  Security has to be done the same way, in the same place, every time as part of the application architecture.  See architecture discussed previously.

Herding the Cats that are Developers

Deepak is smarter than you.  If you ask him he will tell you.  If you tell him to do something that he doesn't agree with, he will do it his way.   Here lies madness.  Your developers are looking at being productive and getting out of the office early on a Friday.  What they are not looking at is security, maintainability and fault tolerance.  We know this because we have to have testers to make sure what they do actually works.  If that weren’t true, we wouldn't need testers.

I can hear you saying “MY developers wouldn't do that.”  Yes, yes they would and have, you just didn’t know about it.  I read the code that they type.

Development Environment Selection

This might have gone under “herding cats,” but I think it deserves its own section.  Your developers, or the developers of the company you hired to do whatever, want to use the latest and greatest of everything.  That’s great, if they are going to be around forever to maintain the code they write, but they aren’t.  So they are forcing you to identify and hire guys that know whatever tech “stack” some goofy open source guy picks, and that is an egregious case of the tail wagging the dog.  

Licensing

One of your guys finds a widget that he needs to do whatever it is that he thinks he needs to do.  Maybe it is a datagrid of some kind, those seem to be popular, if incorrect, choices.  So he downloads it and uses it and in 6 months your deployed and stable application blows up because s/he had a trial version.  Or the vendor decided they need to get paid for what they do.  The nerve!

Open Source

You can’t use open source.  Open source is free and worth every penny.  Open source also means that the code is available to anyone that wants to download it.  It also means that the code is community supported.  There could be thousands of developers. All it takes is one of those thousands to check in a back door and now your Open Source based application has a backdoor too.

JavaScript is an abomination before man and God and should be eradicated from the zeitgeist.  Its time has passed and that passing was a long time ago, right after it ousted Steve Balmer as CEO of Microsoft.  If JavaScript is dead then all the frameworks that depend on it should be dead too.  Did you ever wonder why Google provides MIT licensing for Angular?   They don’t license any of their other proprietary software.  

Maintainability

This goes along with Architecture. You have to separate concerns in your code, that is separate the business logic from the database code from the retrieval system, from the interfaces from the pretty parts.  If you put the same code in the same place, every time, then you know where to look when something goes wrong.

Artificial Intelligence

It is impossible to use AI to write code.  Before you say “But I have DONE it,” no you haven’t.  You may have used AI to provide a point solution like “how to deploy to a container.”  That is a point solution that is just as likely wrong as right, but you didn’t do anything like create a deployable application with AI.  

Don’t use it.  Don’t argue.

Documenting Architecture is difficult at the very least.  Mostly there are pictures that represent dependencies and layers and calls back and forth.  AI can’t and never will be able to associate these pictures with code.  It doesn't understand.  It doesn’t understand anything.  It spits out tokens representing parts of words that are statistically most likely to be next.  That is it.  So it can’t associate the pictures with the words.

Architecture and database design is also notoriously hard to teach.  There are two ways to learn these.  Either you have to make the mistakes and correct them or you have to apprentice yourself to someone who has made the mistakes and corrected them and who will call you a dumbass repeatedly, loudly and often for re-making them.

AI can’t and never will be able to design and build an application.  This is also true of most developers and for all the same reasons.  They don’t teach you those things in college.

The Solution

You have to make it easy to balance all the previously stated concerns:  Do it for the developers.  All of our applications use a Master Data Management (MDM) database that holds all the information necessary for your enterprise, so you won’t have to duplicate data between applications.  All of our applications use a Single Sign On (SSO) database to hold all the Authentication and Authorization data we discussed above.  We will talk more about the MDM and the SSO in the Backend For Frontend (BFF) section.  This is fairly non-technical, don’t let your eyes glaze over for a couple of pages

Generating Code

 The only way I know of to solve the problems above is to write about half the code and all the architecture for the junior developers.  They are all junior developers.

Once we design the database to do the task at hand, we generate the package that we then turn over to the developers to finish.

Generally the architecture has four major pieces:

• UI
• Backend For Frontend (BFF)
• Application Programming Interface
• Database

We will take these in reverse order from the bottom up, and explain why what we do is not only superior, but the only way to achieve consistent, secure, maintainable, performant results.

Database

We have already related that we design the database by hand.  Database design is an art, art is subjective, and machines can’t do art.  There is a ton of generated code here, however.  One of the “best practices" is to allow access only through stored procedures.  I personally have never seen any applications that do that besides the ones we build.  We generate those stored procedures for Create, Read, Update, Delete, Search (fuzzy) and Search Exact.  This also allows us to implement our multitenancy and security designs automatically.  Finally, it gives the junior developers templates from which they can copy and paste any code as a template that wasn’t generated for them

Multitenancy

Yes, everyone goes in the same database.  This is for security and administration ease.  There is nothing like having 7500 clients in 7500 databases needing 7500  upgrades or changes all at once.  Been there and done that for client enterprises.  That is not the way to run a railroad.  This multitenancy is different too, it is modeled after  table-based multitenancy, but doesn’t require a key in every table identifying the data’s owner.  We call ours relational multitenancy, because the data can easily be related back to the company or user it belongs to.  This is what relational databases were designed to do after all.  We achieve this by issuing a new, globally unique identifier (GUID) that identifies the user and the session for each time the user logs in.  this ensures that the user can only see what they are supposed to.  This is unique in the industry.

Security

We use that same GUID to authorize the user once they are authenticated.  That means that we can filter out functionality that particular user is not allowed to see.  For example, we might have a salary column in the database and only people with the HR title can see salary.  This also can be checked at the user interface(UI) level so that the non-HR user can’t see any HR functionality.

Application Programming Interface (API)

The API is about 85% generated and  there are four parts

• Repository
• Business Logic
• Core
• API

All of the classes (classes are where the code lives) in this layer are partial classes and in a “Generated” folder so we can extend the functionality easily and differentiate generated and regenerable and hand written code if we need to, so the hand written code doesn’t get overwritten if the database changes and the code needs to be regenerage..  Let’s refer to that salary example earlier.  We can check the authorization for the salary column and hide it (not include it, really)  here.  

Repository

This is where all the code goes to ship data to and from the database and to translate the set-based recordsets into Data Transfer Objects (DTOs) that the procedural code can understand.

Business Logic

The business logic layer has several responsibilities, like enforcing rules and translating the DTOs into Models suitable for consumption by the UI.  We translate these so we have an abstraction layer between the database and the UI in case the database changes.  We can even swap in a completely new database (and have) and with these translations, nobody needs to know that the ‘Sex’ column is now named ‘Gender.’  This layer is completely generated, and only needs to be modified if the database changes or some unique functionality needs to be included.

Core

The Core project holds all the definitions and contracts.  The definitions are the structure of the DTOs and Models, and the contracts are the interfaces for at least the Repository and the Business Logic that say “these objects have these methods and those properties.  If they don't, your application won’t compile.  This is a way to enforce NOT changing the underlying functionality and breaking downstream applications.  This project is 100% generated

API Project

The API has all the wiring to the other three projects generated, but has no controller methods.  That means it has no endpoints that can be called so we can only expose the methods that we want to.  We do this to minimize the security footprint of the API.  All the methods are written by hand.

Here is a visual representation of the API Layer

Backend For Frontend (BFF)

This is really where the magic happens.  Phil Calçado at SoundCloud came up with this pattern and it is perfect to allow us to generate code and pull in the various pieces of functionality in one layer that is specific to a screen.  That means that a mobile app has the same database and API as the web version of an application, but since there is less screen real estate we compensate by returning less data in the BFF layer.

The BFF is generated but the endpoints are left as an exercise for the developer to minimize security footprint as discussed above.  It has the same Core, Business Logic and API layers as the API, but no repository as we will have already had all the data we need from the database.  

This is perfect for our purposes since we are pulling in at least three different APIs for each application we build, the MDM, SSO and whatever database the application needs to accomplish its tasks.  

The following is a visual representation of the BFF Layer.

The User Interface (UI)

The user interface is, like the database, art. This is a little more traditional art, or craft, since it has functionality, but has to be both functional and pleasing to the eye.  This is all hand coded because machines can’t make art.

Here is a visual representation of the structure of the UI.

Putting it all Together

Hopefully, we didn’t put you to sleep with the semi-technical talk, but we really want to make the point of why Sentia is different and better than any other development company you could hire. Finally, let’s put all the pieces together and show one of our recent executions for a Gastroenterology Practice in Dallas.  You will notice that we have talked about all the pieces you will see and the communications between them represented by various colored lines.

Here is a visual representation of a solution we designed and built for the medical industry.

With the exception of the database design and the API endpoints the first two tiers are completely generated.  The BFF and UI layers have containers and wiring that are generated leaving only the html and the BFF endpoints to code by hand.

Conclusions

If we can automate what we do, we can automate what you do.  The Health Suite was a multi-year project but we accomplished it with a minimum of staff in a minimum of time by utilizing the automation of the code generation tool to herd the cats, write the architecture and produce more than half the code.  The generation tool is currently in .NET 8, and I am planning on upgrading to .NET 10 this month as .NET 10 will debut in production next month, in November of 2025.

This plan solves every one of the problems we identified with custom software development in the problem section of this article.  This functionality makes development fast, secure, robust, performant and maintainable.

WE also have written about solving the general problem, meaning that we look at the whole problem not just your version of it.  We were tasked with the Scheduling system represented above with the Gastro practice and decided to code for Whitesnake putting on a show at Reunion Arena in Dallas in 1985.  If we can schedule the band, the attendees, the equipment, the staff, the security, the venue and all the other things it takes to put on a show in a data driven way, then certainly we can schedule a colonoscopy in OR3 at 6:00AM with a doc, a CRNA, a colonoscope and a patient.  That doesn’t have much to do with generating code, however.

One caveat that we will address head on.  This is a Rapid Application Development (RAD) system.  It is designed to get you up and running as quickly as possible.  Some of the code might not be as performant as it could be, with making multiple calls one for each referenced table in the database to get data and then stitching them all together in the BFF.  This is fine and by design.  We don’t want to charge the client for performance they don’t need.  This performance requires custom development and most of that is on the database side with joins and doing one call to the database instead of multiples.

We know this.

We are prepared to make any changes necessary and know how to, clearly, in the case that your enterprise simply has more data than throwing processor cycles at the problem can solve.  It is really a simple problem to handle.  Further, many times hand written database code can be problematic, so why use it until you have to?

This is the way to tackle this problem, and I would posit that this is the only way to tackle this problem.  SAP, Salesforce, ServiceNow, whatever ATS you are using and all the software you can currently buy are inferior to this and you know it since they require you to purchase the package and then hire a bunch of developers and servers and networking to finish their package and make it all work in your enterprise.  

Since we solve the general problem and use a data driven approach, their complexity is all just configuration for your business with our system(s).

If you liked what you read, please like and subscribe, click the notification icon, subscribe to our newsletter, and follow us on all our social media and blog sites.

If you have comments, contact us here, on our site, SentiaHealth.com, our parent company SentiaSystems.com, or send us an email to info@sentiasystems.com or info@sentiahealth.com.