Low-Code: You’re Doing it Wrong
Don’t treat low-code like high-code. Recognize its advantages to maximize results.
Companies don’t truly understand the many wonders of no-code and low-code software. They end up not taking advantage of its full capabilities. Wasting time and effort by treating low-code the same as traditional software development.
I tend to use low-code because I find that no-code can get me 80% of the way there but I always need 20% code for things like integrations to make the solution truly useful for the end users.
Don’t Do This
Where I work now we have to take projects before an executive board for approval before we can work on them. Every project has defined stages: Initiate, Design, and Execute. There are no shortcuts.
The executive board meets every two weeks. Getting your project on schedule can take a month or more. You must present a specific PowerPoint for each step of the process.
The PowerPoint takes at least a week to get pulled together and for all parties to agree to. Scheduling the board review and getting approval can take a month or more.
In 5 years, I’ve never seen a project rejected. I have seen a request to go back and gather more information.
While this approach may be a good idea for projects that take thousands of hours and cost millions of dollars, it is not a good idea for low/ no-code software.
Advantages of Low-Code
Low and No-Code software refers to software built with a visual tool. There are often reusable components and a point-and-click or drag-and-drop element to them.
Low-Code is great because it has a lower barrier to entry. Developers don’t need much training and the cost is usually low considering it can be reused across various business areas.
The number one advantage of Low Code is speed! It’s quick to prototype. It’s quick to debug. It’s quick to make changes and updates.
It often takes longer to document and train users than it does to build the solution. No lie.
Can you see the problem with the staged approach? Or even in defining sprints in Agile?
It slows down what should be a quick process.
What Should You Do
Take full advantage of Low Code’s ease and prototype quickly and frequently. When I was a consultant I would do discovery all day and then prototype at night.
The next morning, I’d review what I built with the customer and then resume discovery. Edit my prototype at night and repeat.
By the end of the week, we had a pretty good darn baseline. All the integrations and any custom code needed still remained to do. But the structure of the workflow was there.
Customers were thrilled and amazed at what we had accomplished together in one week.
Take It a Step Further
I’m no longer a consultant. I’ve been at one company for 6 years and have built solid relationships with my users.
That lets me take advantage of another feature of Low-Code software. Bridging the Tech Divide.
It doesn’t have to be Developers on one side of the room and Business on the other. We can sit around a single table and prototype together!
Agile on Crack
Talk about agile, right? Embed that developer with the business. Eliminate confusion between the Product Owner and Development Team.
Change, test, and try things out. Rinse and repeat. With Low-Code software, there is only a minimal need for software developers to shut themselves away to code.
Coding can be a collaborative effort between business and IT. This results in better solutions and a quicker development cycle.
You would think IT management would jump on that train.
And yet, here I sit, putting together a PowerPoint slide show. I have a new CTO, so I’m hopeful. Any ideas on how to convince him? Please comment and help a girl out!
