I’ve heard a lot about Low-Code over the past couple years. I actually wrote the post below about 10 years ago but never published it. Much of it still applies.
My first project at Unstoppable Software (many years ago) was to create an application that tracked service tickets. As a sales strategy before I was given the project, we built a Microsoft Dynamic Data site to quickly show how easy it could be to enter ticket data into a web application. The Dynamic Data prototype was pretty nifty. It probably did half of what the client needed in only about a day’s work.
Unfortunately, we let the success of the prototype influence the design of the application we developed for them. We decided to use Web Forms, but not the extensible, working with Objects and Linq kind, the Drag and Drop, HTML-generating kind. Similar to the prototype, I was able to quickly get a good base of functionality working. However, I soon began discovering major limitations with the technique I had applied. The framework seemed to take over, and not let my code do the work, when I wanted to write something more customized.
At a certain point, the limitations became clear. I could either forge ahead and try to work around the design for the remainder of the project (which wasn’t much), or I could rewrite large portions to work better. We decided to keep going, finish up the project. We pushed through and delivered a working project to spec. However, it would have been very difficult to move forward in another phase (had we had one).
There are a couple things I should have done:
- Designed a more flexible technical solution (we now have a more standard way of doing things)
- Prototype in a way that either a) was an appropriate constraint on the technology or b) was technology-agnostic
But most importantly, I made a major mistake. The work I did first was the easiest, most known, element of the system. What I should have done was mitigate risk by performing those tasks that were most custom first. That way, if I uncovered any design issues, it would not be too late to alter the design or improve it for the future.
I still believe that a Low Code solution is only as good as its extensibility. When developing an application that will run a real business process, it is inevitable that it will become sufficiently complex to test the limits of Low Code. It is at that point where custom software must be developed to stand-alone or integrate with existing applications.
