Getty Images
4 low-code best practices to streamline adoption
To be successful with low-code adoption, organizations must clearly define project goals, ensure the right mix of staffing and tools, and regularly asses business value.
Low-code software development won't be the right choice for every application or organization. But, when the approach is, teams must take certain steps to ensure implementation goes smoothly.
Low-code tools have become more prevalent in software development. This change can open the floodgates for IT departments to create and maintain their own applications. However, some standard programming practices -- such as version control, bug tracking and requirements management -- might be too heavy or too nuanced for low-code tools.
Organizations need to set some ground rules on how and when to use low-code tools. These rules should apply to everything from staffing and tool choices to design processes and code releases to production. These four low-code best practices can help organizations get started.
1. Start small with low-code tools
Before implementing low-code tools and platforms, identify less complex projects that match the potential benefits of low code. For example, simple, quick-win projects -- such as ones with isolated data -- lend themselves well to this development style.
Low-code tools typically work with isolated software backed by an internal database. Select a proof of concept that's a real representation of future projects but a scaled-down version. This approach lets you test-drive low-code tools to ensure they provide business value before you scale up to larger deployments.
Start with no more than two projects at a time, and avoid multiple projects completely, if possible. Once programmers get to four projects or more, it is easy to spend so much time switching focus that they essentially make no progress at all.
2. Staff for aptitude, not knowledge
Self-taught programmers often struggle with complex applications and dreaded spaghetti code. Low-code tools produce different types of applications, such as those that have a visual or database representation, with limited code around rules. For example, these rules can be as simple as a validating a Social Security number or predicting a delivery date.
Low-code software tends to have less code than its alternatives and is organized into well-packaged functions. Such applications also tend to fulfill isolated functions. Since there's limited code, self-taught programmers are an ideal fit. Someone from the business side of the organization with limited coding experience, for example, could be a good fit for a low-code project.
However, don't rely solely on one self-taught programmer to hold the keys to the kingdom of low-code tooling. A single programmer creates a single point of failure. As another low-code best practice, ensure at least two people -- preferably three -- can use the tool and understand the entire creation process.
3. Choose tools that support project complexity
Software tools have evolved to account for nearly every possible problem a technical team encounters. There are tools for planning, bug tracking, continuous rebuilds and metrics -- plus IDEs that put all this functionality behind one interface. Your team may, or may not, need this scope of capabilities.
One key consideration with low code is integration. Modern applications tend to use APIs to communicate and work together. For example, a low-code application could have an employee tracker function that needs to communicate with a low-code warehouse stock manager. In this case, the app requires some higher-level tooling and functionality. Likewise, if the IT department wrote a traditional warehouse stock manager for this low-code tool to connect to, it might make sense to find out the underlying technology and purchase a low-code tool from the vendor designed for that architecture.
Another approach is to use a low-code programming tool and then slowly add free, open and cheap components for software engineering. For example, if an organization will only use a low-code project once and it requires little maintenance, teams could define requirements with a word processer and track bugs with a spreadsheet.
Decide which tools must be coupled with low-code applications based on budget and usage. A simple rule of thumb is that projects that require more than one staff member, or will last a year or more, probably need more sophisticated tooling.
4. Have a clear vision, timeline for low-code projects
When development teams lay out a project timeline, they want to find a happy medium. You can't spend a month breaking down each one-hour increment of work in a Gantt chart. And you can't just point the team in a general direction with a deadline and hope for the best. Ideally, your IT project management follows the rolling wave planning mindset.
A key low-code best practice is to clearly define the vision for a project. Use previous project timelines to estimate the new project length. Then, plan to work in one- to three-week increments, with demos of working software at each step. Before the next increment, completely define the current work, plan the next increment -- with some wiggle room -- and make sure there's a general theme for the following few increments. Leave some time for refinement, too, potentially during a 15-minute daily check-in.
The product owner is responsible for the end goal of the software, whereas the programmers handle development and implementation. Start plans to finish the entire project two-thirds of the way through, with a built-in buffer. Define in a document what will be built during each increment. This structure ensures a project has time to evolve and grow but also establishes reasonable deadlines for its eventual completion. Since low-code development is typically faster than traditional, manual development approaches, it's possible teams will complete low-code projects early. If that's the case, consider shortening project increments.
Tips to get started quickly with low-code tools
Start small with low-code tools. Specifically, do this on small, technically representative projects. Before expanding into more complex projects, pause to consider and calculate the business value. Also, avoid the trap of multiproject work.
Staff for aptitude, not knowledge. Hire and keep staff with a mix of subject matter expertise (aptitudes) and traditional computer science skills. And ensure multiple team members possess necessary know-how; don't introduce a single point of failure.
Choose tools that support project complexity. Be sure to understand an app's integration needs to select an appropriate tool.
Have a clear vision, timeline for low-code projects. Develop a planning strategy that mixes simple documentation with room to evolve. And work with IT to create test environments and a stable rollout process. Plan for save points right before code moves to production so you can roll back to previous working builds.
