CIOs and IT leaders are stuck in a paradox of competing priorities regarding developing, enhancing, and modernising applications.
On the one hand, they seek innovation, experiences that delight end-users, and agile devops practices that enable the quick delivery of new business capabilities.
On the other hand, they are concerned about mounting technical debt, ensuring applications go through the proper security validations, and demonstrating whether prototypes can perform and scale in production environments.
Yes, CIOs and IT leaders want to have their cake and eat it, too. They know all the wants, must haves, and wish lists from their developers and delivery leaders.
More time to develop code “the right way,” more people on the team, better training, more nimble development infrastructure, modern application development tools, better stakeholder engagement, and well-defined priorities are on everyone’s list.
IT leaders are aligned with their teams on their needs, but must also face business realities in driving digital transformation, working with budgetary constraints, and meeting compliance requirements.
CIOs want application development teams to know how to make prudent decisions around trade-offs, what steps to take to ensure that what’s developed is supportable, and why collaboration with end-users, stakeholders, architects, and operations is as important as getting the application done.
To address these paradoxes, CIOs hope their development teams understand development principles and trade-offs. Here are five to consider.
1 - Balance technical debt and innovation
It’s very easy for development teams to get excited chasing innovations or adding spikes around new technologies to the backlog. CIOs and IT leaders want innovation, but they are also concerned when development teams don’t address technical debt.
A healthy agile backlog should show agile teams completing a balance of spikes, technical debt, new functionality, and operational improvements.
Prioritisation on agile teams should fall to the product owner. But IT leaders can establish principles if product owners fail to prioritise technical debt or if they force feature priorities without considering the agile team’s recommended innovation spikes.
CIO and IT leaders are also realistic and know that new implementations likely come with additional technical debt. They understand that sometimes developers must cut corners to meet deadlines or identify more efficient coding options during the implementation. It’s reasonable to expect that newly created technical debt is codified in the source code and the agile backlogs, and that teams seek to address them based on priorities.
2 - Always develop secure and maintainable code
Development teams are under significant pressure to deliver features and capabilities to end-users quickly. That is certainly one reason teams create new technical debt, but it’s a poor excuse for developing code that is not maintainable or that bypasses security standards.
IT leaders don’t want spaghetti code, nor do they want overly complex code that requires advanced engineers to maintain. IT leaders are responsible for the long-term maintenance of the code they deliver, knowing that developers and teams get reassigned to new projects. They expect code to follow architecture patterns, coding standards, naming conventions, logging patterns, and exception handling.
They also expect development teams to collaborate in defining and evolving standards. As technology, platforms, and best practices continue to evolve, organisations cannot rely on architects to own and specify all the guidelines.
3 - Create delightful user experiences that perform and scale
In the early day of Web development, software teams had difficult trade-offs in application architecture and design.
One approach had the development process start with teams engineering the back-end database and coding business logic. Engineers created reusable and scalable solutions, but the implementation often constrained the user experience and designs.
In the other approach, Web development teams start with the front-end designs and deliver great experiences to end-users. But these designs often implemented business logic inside server-side templates or made frequent service calls resulting in applications that didn’t perform well or scale as required.
CIOs need to deliver great experience and performance. Today development teams can utilise wire-framing tools, low-code platforms, feature-flagging capabilities, microservice design patterns, devops best practices, test automation, and cloud architectures to deliver both.
4 - Avoid coding to solve tech for tech’s sake problems
When I sit with development teams during their agile planning sessions, I listen for the underlying problem statements and place them in one of several categories. The best features and stories aim to deliver or improve capabilities for a targeted group of end-users. I may also see dedicated spikes to test new solutions or prototype new capabilities.
Sometimes technical debt is addressed within a user story’s implementation. Other times the work is significant enough to require multiple dedicated stories on the backlog. These are all good examples of work that the product owner should review and prioritise.
Sometimes I see work targeted to solve a technology need. On the low end, it might be utility classes to support configurations and service connections. I’ve also seen teams try building micro-content management solutions, low-code capabilities, and API management tools.
Most development teams should avoid building technology capabilities that solve technology issues. Robust solutions to technical problems are often available through open source libraries, public cloud computing services, low-code capabilities, and commercial software services. Architects and development teams should evaluate these options before signing up to develop “tech for tech’s sake” solutions.
5 - Adhere to data governance standards
The last thing CIOs and IT leaders want to see when development teams build or enhance applications are more data silos, duplicated data sources, or poorly engineered data structures.
For most organisations, the size of data debt often exceeds technical debt, and the business impact is significant. Just ask any data scientist to make sense of the urban sprawl of data sources that live across enterprise data warehouses and data lakes.
It’s incredibly easy today to create new relational databases, NoSQL data stores, and data lakes. That’s both a blessing and a curse, and the issue is how to help development teams know what data sources are available and the best way to interface with them. Reviewing data catalogs, API portals, and master data sources should be the first step for development teams before creating new data structures.
If new data structures are needed, teams should use data modelling tools and follow data governance standards as non-negotiable practices.
To summarise, CIOs and IT leaders want innovation, speed, satisfied end-users, and development teams excited to solve business challenges. But they also need reliability, performance, efficiency, scalability, security, and applications that can be maintained long term.
These aren’t mutually exclusive goals, but practical trade-offs come up every release, sprint, and user story. IT organisations should define engineering principles and debate their implementations as part of their development process.