DEVOPSdigest

Low-code development tools change the application development process less than we probably think. Of course they help, but the problems we had before low-code's rise to popularity are still with us — and still unsolved.

Furthermore, I'm hoping that low-code ceases to be a topic of conversation. It won, it's everywhere, and thus it's no longer special. According to a study commissioned by WEBCON, 84% of CIOs expect the importance of low-code to increase in the next 12-14 months. Perhaps we can now regard "low-code" the same way we regard "drag-and-drop," namely, ubiquitous, commonplace, and perhaps even expected.

What we should be talking about is how we're using our development tools and what we're using them to accomplish. You know — methods and results. The stuff that matters.

For example, how about the fact that many problems start well before development even begins. Regardless of tooling, the design phase of most projects is still too often characterized by ideas and requests that aren't fleshed out and understood.

The steps for creating an application haven't changed. There's problem definition, design, construction, deployment, delivery (user assistance, governance, etc.), and continuous improvement. The vast majority of low-code tools have, at best, reduced the time and skills required during construction; they've made a large difference for a small part of the overall solution lifecycle.

I can think of a bunch of topics that are worth more attention than low-code:

Measuring efficacy

How well does an application address the problem it was designed for? It requires us to have defined goals and a way to measure an application's effect on the organization to see if it's meeting those goals.

Subject matter expertise

This is especially true of business intelligence. There's a huge hype machine out there selling business on the idea of data-driven everything. All the beautiful interactive charts in the world won't make a difference if they're based on data that's collected poorly and/or wasn't harvested and staged properly. Moreover, it won't lead to useful insights and good decisions if management doesn't know what data will be of help, and how. Again, we've got tools taking center stage over knowledge, and it's a problem.

Change agency

Can digital transformation be imposed on high? Does it need to happen organically with some coaching and facilitation? How do you combat fiefdoms? Knowledge hoarding? Learned helplessness?

The pursuit of perfection

Too many corporate cultures punish a lack of perfection, and refuse to make a move until perfection is all but assured. But the whole point of agile development (as an idea) and many similar ideas is to start with something good and enter into a continuous cycle of incremental improvements. It's really hard to get organizations to accept that.

Applications as relationships instead of projects

As much as continuous improvement and minimum viable solutions are being touted, most companies want defined scopes, fixed prices, and defined deliverables. How do we get them to accept that solutions are their digital DNA and they ought to be refactored and reworked on an ongoing basis? That vendors and/or staff should be hired on their basis to adapt first and foremost?

Decentralization without chaos

If we want innovation to take place in the trenches, and we don't want that to result in a plethora of incompatible, incoherent one-off silos, what can we do?

Digital curation

It includes libraries of algorithms, code repositories, design patterns, user experience approaches, ready-to-use-and-modify applications, data staging, and more. Are traditional IT practices up to the task of harvesting, cataloging, and promoting everyone's good ideas?

Branding applied to the user experience

When users know what to expect, they need less training. When we define a way for applications to look, feel, behave, and interoperate, introducing something new doesn't slow everything down. It's okay for a company's digital approach to be unique, but probably not for every single application to be unique.

Mind you, each and every one of these topics can apply to low-code creations. They can also apply to traditionally coded creations, too.

Go to: I'm Tired of Talking About Low-Code; Bigger Issues Are at Stake - Part 2