Every team, every operation, and even every object has its weakest link. You can’t remove the weakest link as another aspect will take its place. Hence business, like every other area of life is consistently addressing the weakest link to raise the strength of the whole. Our team, like make is constrained on resources, specifically solid engineering resources. Because of this there is a healthy appetite to go in a direction that we’ve never gone before – low-code. Just imagine, no longer are your users constrained for weeks or months to have an engineering resource assigned to their task. Now, in this magical world you can just have the user accomplish their goals themselves, or at least limit the burden on your team by offloading simple tasks. It sounds too good to be true, but is it?
We’re now about a year into our low-code journey, and I can tell you that it certainly has huge benefits, that are accompanied by significant drawbacks. For those of you who are interested I’d like to share our story thus far as we walk, and sometimes stumble down the road to success in low-code. Our outlook is certainly different than it was a year ago. Not simply more optimistic, or pessimistic, but better informed around the implications of the road that we have chosen. Or, should I say, forced into as we had no other choice to cope with the load and insufficiency of engineering staff? I’d imagine that our story is the same as many others; large visions and small abilities drive ingenuity. Furthermore, where one succeeds partially, another can come along and learn from them to succeed more fully. I hope that some of my readers will be those who, if not succeeding more fully, will at least be those who enter the journey more prepared for what lies ahead…
The Catalyst of Challenges
We’ve already talked about a lack of engineering staff, but there are other criteria at play when it came to our making a low-code decision. The primary one was implied previously, but it’s all around velocity in a sustainable manner. When we looked around at the work that needed done, there was simply no way to do it with our existing staff and toolsets. Even looking around the company at other tools, there was always a large enough gap in our criteria to prevent usage of an existing toolset.
The Criteria
Low-code is a delicate balance between the customizable, and the black-box. That which you can control (albeit at a cost), and that which you have no control over. When embarking on this effort it will be critical that you understand where that line is with each vendor that you choose, as well as where your range of acceptability lies. Be aware, we’ve encountered significant challenges on this front by certain quarters of our users. For some, everything must be customizable, to the pixel count of padding on a widget. In a low-code world this is usually very difficult, if not impossible.
Be aware of your users' expectations around ability to customize the user experience. Rough waters lie ahead without an agreed-upon expectation.
With that, let’s explore at a high-level what our requirements were. More details will be shared at the detailed post to follow.
- Affordability
- Code-based and stored in source control
- Enterprise Supportability
- CI/CD driven with pipeline supporting multiple environments
With that said, let’s embark on a detailed review of what we’ve learned as we’ve progressed down this challenging but rewarding journey.