Amazon Honeycode and the promise of low-code development
“Building apps” is actually an extremely wide subject. From complex, machine learning assisted solutions for tough business cases, up to simplistic planners and message boards, you get what you put in. A growing subset of this industry is low-code or no-code development.
Honeycode – sweet spot or just another bait?
Few days ago, Amazon released its latest product – Honeycode, which is an interesting case study in what companies believe to be a missing link in the software development market, a potential niche. Many do – in 2018 Siemens made a stunning acquisition (bought Mendix for 730m USD), and others have raised considerable capital. Even Google jumped in in early 2020!
How did we get here? Well, apps are everywhere, and someone has to make them. Software development has branched into a less technical, bare-bones version of itself – low code app development platforms. Essentially, those programs allow people with very limited programming experience and acumen to drag and drop what they need and build their own simple solution.
Why low-code platforms gained popularity?
It’s hard not to see the potential here. After all, prefabrication is usually faster and not having to hire a talented developer is going to be cheaper. Until you find all your needs fulfilled by the usually pre-set tools given to you by the platform, and know how much to expect, there is a good argument there.
As with many modern apps, low-code platforms usually run in the cloud, and are fine with cross-platforming. Customization is obviously limited in a way, but one may find that different platforms allow different kinds of customization.
To rehash – being able to quickly design, build, customize and deploy new apps is the main selling point. This is why, unsurprisingly, low-code platforms are varied themselves, with some solutions being aimed at developers themselves, which allows them to cut time spent doing repetitive tasks. This, by the way, speaks volumes of how inefficient and badly designed some of typical programming work is – such solutions should be available to pro’s earlier and outputs would benefit greatly.
In the paragraph above I describe one of the biggest drawbacks of the low-code platforms. They usually serve both professional and amateur app builders. How to manage expectations of both groups? Basic users need simplistic interfaces, limited options and good guidance. Advanced users will seek for more customization, integrations and general functionality.
Low-code (or even no-code) development was a promise floated around the industry for years and years. There were some reasonably good attempts– some of you probably remember the heyday of Visual Basic and Power Builder, which were essentially designed to be used by beginners. Want a trip down the memory lane? Read this article from the 2010 The Guardian, which touts Google’s App Inventor “tool kit” which was supposed to let non-tech cat ladies make their own apps in minutes. Let’s just say, that promise is still not really fulfilled.
In themselves, those were not bad solutions – but they led to crippling consequences and bad design choices becoming a bad standard. One of the golden examples is the Magic Pushbutton anti-patterns, in which business logic was lagging behind the relatively simple front-end development processes.
That is one of the reasons why one should be cautious when using the new breed of low-code solutions. Low skills programming attracts... well, low skill developers with all the consequences of this lack of understanding of software and its inner workings. Just as the Visual Basic became mostly a tool for simple prototyping, it became almost entirely obsolete for anything more advanced.
Core problem with low-coding
It tries to achieve something very good, but is usually just hiding the hard truth. As written well by Bob Reselman (himself an author of books about Visual Basic), making software is both hard and expensive. Good code must be written by skilled people, and they need to be paid. Outsourcing coding to unskilled labour is just that – giving the job to someone without basic knowledge.
And that was the second point by Reselman – that code basic absolutely do matter. Using visual and low-code solutions, we are simply seeing an abstract version of the code itself. But when something goes wrong (and in development, that is rather the norm than the exception), you most probably need to understand the logic behind the system you try to create.
This may create a false sense of efficiency, as even identifying the problem is much harder. Obviously, the main factor that limits this possibility is... lack of advanced functions, which would create co-dependencies and tight coupling. That is clearly another problem one has to always take into consideration when venturing into low-code solutions.
Maybe with more time under their belts, modern low-code solutions will replace a lot of the grunt development work now done by experts. If you really can’t afford a development team at all – maybe that is the only way forward. However, saving on product management and engineering is usually treated as no-go in software, and for good reasons. Lapses in those areas create costs down the line, and may create problems that sink the enterprise.