4 Common Reasons Low-code Projects Fail

摘要： Far too many organizations today expect magic from low-code tools and their initiatives fail. Where do they go wrong?

▲圖片標題(來源：faithie via Adobe Stock)

In recent years, organizations have begun adopting low-code tools, most often in response to the assertion that their employees can create applications without having to code like a developer. That often is referred to as citizen development.

At the same time, 64% of IT professionals have also started leveraging low-code as their go-to, work-around development solution. It’s not surprising that we’re seeing this shift in application development at a time when demand for applications is greater than the supply of skilled workers to create them, leading to significant project delays and backlogs. In fact, a whopping 86% of IT decision-makers say the biggest challenge to digital transformation is that there are too few software developers.

While low-code tools certainly have many benefits, far too many organizations try to use these platforms expecting magic to occur – and instead meet with mixed results or outright failure. Why the disconnect? Here are some common reasons low-code initiatives fail at organizations:

Putting low-code tools in the hands of the wrong people.

While low-code tools are heralded as platforms that amateurs (citizen developers) can use to easily build applications, they’re not meant for anyone to solve anything. As an illustration: Many people can play chopsticks on the piano, some folks can play beautiful music, and a select few are concert pianists. The instrument used is the same, but as complexity increases, it requires a certain level of skill. Invariably, real business problems require that low-code tools be used by the right people (typically professional developers) to accelerate digital change. Low code should appeal to everyone. However, they probably most appeal to people who can code but get more done in less time using low-code tools instead.

Giving the tools to the right people but having them do the wrong things with it.

If professionals leverage low-code tools to create applications more quickly but don’t listen to business stakeholders, they’ll still build terrible applications -- they’ll just build them faster. Low-code tools don’t save bad developers from bad development. It’s important to still treat low-code efforts like real, professional development projects. Users who cut corners and think any issues will be solved in testing (but then don’t actually test the application) are going to run into serious problems. Agile principles should apply to low code as well as traditional development methods. In fact, low code should allow one to iterate more often to make sure the applications meet the changing needs of business stakeholders.

Not dealing with deployment and maintenance.

Many low-code projects are built in production mode. For instance, let’s say that we built a solution for handling help desk tickets or expense reports and I think of a clever and useful way to improve it. The odds are that will break the solution (which is obviously really bad). Or, my updates will annoy other users and prevent them from finding what they are looking for when I develop in production. When using low-code tools, it’s tempting to make quick and (seemingly) helpful updates whenever an idea strikes, but it’s still incredibly important to test and validate, and prepare and train IT and users before just throwing a change into the wild. Developing in production has the potential to disrupt user activity or damage live data. What is especially true with many citizen developer projects is that change management is not the highest priority. There might be a packaging/deployment facility for one-time deliverables, but it often results in a complete overwriting of the original application. Actual change management is rarely seen among low-code platform offerings.

Focusing on building the application and not considering how to deliver it.

Building the application is only 10% of its delivery process. For example, low-code tools won’t help you create a good design for your solution, make it compliant, or properly secure it. (The options for securing it might be really limited). In fact, the default for low-code platforms is often to let users do whatever the solution builder has the privileges to do. The onus falls on the solution builder to take away user privileges that are unnecessary. Auditing and monitoring? You’re usually on your own. Documentation? Education? Maintenance procedures? They’re usually manual or nonexistent. By only focusing on building an application, you might end up with something that is clever in the short term, but that is poorly designed, not compliant, and insecure in the long term.

Low-code tools are steadily gaining in popularity, with Gartner predicting that low-code application building will gather more than 65% of all app development functions by the year 2024. As this technology gains greater momentum, it will be even more important for organizations to think about who is using these tools, what they are using them for, how they are using them, and which outcome they are expecting. By better understanding how these tools work and how low-code projects differ from traditional development projects, businesses will be primed to avoid these common low-code project failures. Low-code development is, after all, still development.

轉貼自： Information Week