Are you developing too much code? The rationale for low code alternatives in digital transformation programs

Too much code
I am concerned that some organizations are developing too much custom code as part of their digital transformation programs. The code may be tied to delivering new mobile experiences to customers, integrating new data sources into a data lake, generating dashboards, or providing collaborative tools for a departmental workflow. Writing too much code can be a mistake for organizations when supporting and enhancing the code becomes more difficult than anticipated.

It’s easier to write and deploy code today than ever before. Set up a cloud, select a development language and platform, download an editor, setup one of dozens of data storage services, decide on a basic testing process, commit code to git, develop a rudimentary CI/CD pipeline … There's plenty of "how to" videos and tools to get developers started with the basics, or, organizations can hire a freelancer or service provide to do all the heavy lifting. Two weeks you have an app and in two months you are at MVP.

Developing custom code is NOT that easy!


Sound easy? I promise you that it’s not. I just rattled off a half dozen technologies not including all the open source or third party libraries that are leveraged in the code base.

Watch a developer debug a difficult performance issue, solve a complex user data issue, or resolve a conflict in how a browser version interprets a CSS.

I have deep respect for developers working through these issues. Even with the best code standards, debugging tools, and runtime performance monitoring, it can be difficult and time consuming to research and resolve application defects especially if they only impact a subset of users.

And business leaders need to learn and relearn the patience it takes to build and support a custom application. Something what looks like an easy implementation or a quick fix often takes a lot longer than anticipated. One of the most common questions I get from business managers is, "Why does [fixing it | developing it | resolving it] take so long?"

And therein lies my concern. Most business leaders don’t have this patience. Many businesses don’t allocate the budget to support upgrades and enhancements to applications. Only the best of developers write code that is easily maintainable by other, often more junior developers. Few organizations invest enough in developing automated tests and documenting their code. 

And with many platforms and open source libraries being released more frequently, businesses face a lot more risk if they don’t actively upgrade applications.

Why are you developing so much custom code?


It’s good that organizations are looking to develop more applications. It's GREAT actually. Some of these applications are products that drive revenue or customer facing applications that improve end user experiences. Some are workflow applications that make employees more efficient or enable them to better collaborate on business needs. Other applications may be tied to data integrations or analytics programs. Again, all good stuff!!

But not necessarily good for organizations that elect to develop custom code for all these business needs!

I believe there are four reasons organizations are developing more custom code -

  • Business and technology leaders do not invest sufficient time to research platforms, implement proof of concepts, and promote platform-backed solutions to stakeholders. When investments for new applications are justified, the organization doesn't have the time to research and falls back to developing proprietary applications.  

  • Product owners drive requirements toward solutions that can only be implemented with custom code and they are reluctant to compromise when alternatives are presented.

  • Some CIOs are reluctant to bring in third party platforms, sometimes because they fear experimenting before their is organizational support for platform driven development and sometimes because they are concerned on being locked in to a vendor’s proprietary tools.

  • Many developers prefer writing proprietary code over using technologies like data integration, low code, BPM, and other platforms that require less and sometime no custom coding. 

Identifying low code and no code alternatives


So what should organizations do differently? What enables them to seek out platforms and tools that can enable delivering more capability with less code?

The simple answer is to do more research, review, and POCs of the alternatives. In almost every major category of application development need, you can likely find platforms or tools that enable development with less or no coding required.

Need a content management system? I can list at least four. Need to integrate data from disparate sources then I know of six that can get you started. Need to develop mobile first applications for the enterprise then there is at least another half dozen. BI - yes. Even AI and blockchain has emerging platforms that will enable experimentation with less coding. Contact me if you want to discuss!

It's a cultural issue, not a technology issue. Organizations that have a DIY (do it yourself) or a NIH (not invented here) culture have to tackle these beliefs.

Don't leave a legacy of too much code behind.

Further reading on low code 




1 comment:

  1. I wrote this post because debugging applications is *really* hard. If some applications can be "developed" with no or low code, then there will be less to debug in the future.

    ReplyDelete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share