The suits love the idea of “low code” tools. To them, less code means less work and less work means speedier projects, faster satisfaction, leaner budgets, and, ultimately, a fuller bowl of gravy for doling out big bonuses to those same suits. Who doesn’t like any of these things?
Developers for one. Oh, they like these grand promises in theory (who doesn’t want to do less work?) but they know there’s often a big gap between the theory of easier development and the reality that sets in when the deadline gets close and the tools don’t do exactly what they’re told.
Low-code solutions have a place. Programmers appreciate their ability to deliver something that works in less time with less effort. They know that low-code tools can produce a decent mechanism that can search, sort, and otherwise juggle tabular data. They’re happy to use them when the time is right.
But developers also fear getting stuck in corners, fiddling with all of the edge conditions, working around all the places where the tool doesn’t do the right thing automatically. They need to handle the glitches, fiddle with undocumented features, and figure out how to satisfy the requests to do things just a bit differently.
Developers get trapped between the promise of the sales pitch and the reality that working with low-code tools is often slower and more aggravating than writing your own stack—in other words, the high-code approach.