LOW CODE - REALITY CHECK

For a few years now, many of us were aware of Low Code and No Code approaches to software development but reluctant to fully participate. We’re no longer referring people to our blog posts or webinars to explain what no code and low code mean - most people already know that lengthy timeframes and high software development costs are for those who insist on developing software in the traditional way. Businesses now expect, rather than hope, that their software product will be developed and launched within weeks rather than months (and within startup budgets).

LESSONS LEARNED

We’re now working on our second low code platform and we’ve got some valuable lessons to share. The most important learning point is that you really can build a mobile or web app in weeks but there are some important caveats. First, you need to know what you want to build (up to at least the navigation flow across each screen) and be super organised and prepared to collaborate quickly. Also, although you can build a lot in 6 to 8 weeks, depending on the complexity of what you want to build, you should be prepared for a development cycle of at least 10 to 12 weeks (this timeframe is getting shorter every week). Our first low code platform did not achieve our estimated delivery goal but our second is on track to do so. Both low code platforms saved our clients about 60% of their original estimated budget. That alone is a remarkable achievement.

SCARCE SKILLS

Low code resources are difficult to source and manage. Most are developers but they are not typical in the sense that some lack a structured approach - mainly the discipline and rigour that we seek in teams - especially with regards to planning and the use of Scrum. Don’t get me wrong, they are highly skilled developers but they appear to be more concerned about workflows, datasets and the other intricate details of low code platforms than they are about the rapid passing of time. They are relatively younger than our normal specialists and some are as little as 5 years out of uni. Most are certainly younger than the average PHP developer and have less experience of what can go wrong (and how a client might react) if an estimated end date is changed (even when said change is caused by additional work requests).

On reflection, and with a sample size of just two platforms, I can also conclude that the testing and UAT process is significantly faster and easier than anything that I have experienced before. Now, that might also have much to do with the fact that we’ve engaged more project management resources and therefore, everything is that little bit easier and happens more quickly.

CLIENT PROTOCOL

On the client side, we’ve always insisted on having just one person - ideally someone with intimate knowledge and passion for the product - as sole client representative and point of contact. This speeds up client-side decision making and helps maintain the momentum behind the software development effort. Most of our clients understand and accept the critical importance of this - they may already have a product owner - because it means that the work gets done sooner. The key thing is that we want to cut out the noise and confusion created by a committee of founders or founder representatives - each with their own opinion, voice and maybe ego to match. Much easier and faster to interface with a single person, authorised to make fast decisions and knowledge enough to do so reliably. This rule, and being clear about timeframes for decision making, is especially important when we are collating client feedback during user acceptance testing. We normally specify guidelines and make sure that everyone is on the same page regarding the importance of never exceeding a maximum time frame for feedback. Normally a few hours. On one of the platforms, which is now running late, we inadvertently got into the habit of almost encouraging feedback after days when it would have been more appropriate to get it within hours. A committee was reviewing the work, each person from a different perspective and at different times. Contrast that with the other platform, running ahead of plan, where we have a more disciplined testing process in place and no committees. The client’s representative provides feedback within hours which helps maintain momentum.

LOW CODE - HERE TO STAY

Overall, the low code revolution has mostly delivered against its promise. We know that it is not suitable for every single project but it does fit a very good number.

According to Gartner, Inc.The worldwide low-code development technologies market is projected to total $13.8 billion in 2021, an increase of 22.6% from 2020. When discussing the state of low code with agencies I often hear that some clients abandon low code or low code platforms when they score their first serious funding round. To them I say that they are missing a trick because most platforms have scalability potential written all over them. Yes, most low code approaches have military grade security and offer highly scalable solutions. Also, you can create a “native mobile app” through the low code approach. I suspect that the last remaining and rare obstacle to low code might be a newly minted CTO, funded by the first funding round, keen to be noticed.

Buildze