Developers build systems to solve problems. Business problems. In the planning of an application, we are, unfortunately, not immune to the forces of economics. When we consider a budget and a timeline, our primary concern is feasibility. That is, can we set expectations such that we will deliver what we and the client have agreed on?
Requirements discovery is hard, and it’s unrealistic to expect all requirements to be clear at the outset of a project. New information will be unearthed and new stakeholders will contribute their viewpoint down the line. In fact, it’s likely that the project you’ve scoped originally will change materially by the time you deliver it.
There are aspects of a project that repeatedly slow down the development process, and they are ones that low-code platforms are well suited to handle. Here are a few examples.
Visual Documentation of Data Models and Workflows
"Documentation is the castor oil of programming. Managers think it is good for programmers and programmers hate it!"—Gerald Weinberg
Documentation is frequently regarded as the last thing that’s produced before an application is shipped. It’s seen as an add-on, and not a fundamental part of the development process. While few would like to admit it, there are many reasons documentation gets the limited resources that it does. Here are three:
- The person charged with writing docs is likely not aware of the full scope of the project.
- They are unsure of the intended audience.
- There’s was no budget for documentation.
This is where low-code platforms shine. The visual and declarative nature of the platform provides a foundation for agreement between users and the developers.
When you initiate a workflow, you can visualize what should happen along with context and an explanation. This is available out of the box. It’s then up to the project manager to add color as to why the process is taking place, and thus, fill in the gaps for the end user.
Changes to the Data Model
By far, the biggest part of a project that is consistently underestimated are changes to the scope of the data model. They could be as small as adding a field to track whether a user is active or inactive. But, they could be as large as changing the relationship between a set of fields and an object. For example, you may realize that a user may have many addresses and there needs to be a separate model just for “address.”
But, what about the API that serves your integrations? That will likely need to be reconciled with changes to the data model as well. As you can see, a small change in your customer’s perceived scope could have wide reaching implications for the architecture and UX of your application.
Low-code platforms mitigate this situation by analyzing the dependencies your change will affect. The platform has knowledge of your application’s design and will alert you of breaking changes before they hit production.
There are changes to the data model that can materially change the scope of the project and impact timeline, budget, and the need to involve development resources. But, the two examples here should not. They are common use cases and therefore predictable.
Authentication and Authorization
This may seem obvious, but your business application likely contains data that must be kept under lock and key, and different members of your organization need to have access to different things. Users must login to be authenticated so the system knows who they are, and they must be authorized to access a particular resource based on their role. There are super-users who can administer everything, and there is the ability to assume the login of a user for debugging purposes.
I mention this because it’s something every developer should think long and hard about before building themselves. In fact, rolling your own security is a known anti-pattern. So, this is something you as a developer should not have architect, build, or maintain unless absolutely necessary.
Roles Best Suited for the Developers and the Development Team
As the management of more and more of these aspects of the development process are given to analysts and project managers, what are the career paths for the developer to follow?
Undertake the Unpredictable
I want to be clear that I’m not saying that the role of the developer will be diminished. On the contrary, I believe that by abstracting away these tasks to the people who spend the most time with stakeholders is a way to free up development resources to do a number of things:
- Increase test coverage.
- Improve performance.
- Instrument usage tracking.
The bottom line is that abstracting the predictable nature of enterprise software development allows developers to work on harder problems that analysts and PMs cannot do, such as ETL, data cleansing, analytics, improving UI performance, caching, and more.
Not only that and probably more importantly, this abstraction also enables developers to expand their skills further than they ever thought before. Think of a team that was once confined to using .NET/Cobol/Delphi to build and maintain a portfolio of solutions, for example. They can now deliver native mobile apps or responsive web applications. And they can do it without having to spend a year or more learning Android or iOs. The end result is a far greater number of full-stack developers (including mobile).
The areas where there is still a large developer shortage will gradually disappear. There will be more opportunities for career advancement, and development teams will be multifunctional and highly productive. Project managers will be working with a development team that triples its throughput. One project manager described it like this: “We literally run out of backlog and we are now challenging the business to innovate in other areas."
Nice work if you can get it. And, with a low-code platform absorbing the boring and repetitive aspects of development, you probably will.
About the Author
Matt is CEO of an application development firm, Voyager Scientific, which provides workforce automation solutions to clients. He also gives lectures on data visualization and meditation practice.