Even when organizations thought they were rigidly specifying which database or programming framework to use, developer choices became part of the technical debt those businesses would have to deal with for years. Separate, individually sensible, decisions about which technology to use for your customer database, website and e-commerce system could leave you running a major, customer-facing site on an unsupported stack. PHP code is widely used, but also widely disliked (it’s the 9th most dreaded language in the 2021 Stack Overflow developer survey). It’s less maintainable than some alternatives, but you may find you’re still supporting it years later following developers’ choice to use it because it was easy to learn and easy to deploy. These days, such choices are even easier for developers to make, and the unintended consequences can affect your business in ways that ripple out from the specific application they’re building. Whether you’re adding services to sell alongside your physical products, embedding smart features in devices to make them more sophisticated and more valuable to customers, or just working through the digital business transformation every organisation is going through to become more efficient and productive, what developers build is a key part of what your business actually does.
Convenience wins
Cloud services, APIs and enterprise-grade open-source platforms mean any coder can use the same platform Google runs YouTube on by signing up for PlanetScale or the AI-powered search engine technology behind Bing by using Azure Cognitive Search. But they also mean that developers can make choices based on convenience, familiarity, personal productivity or what looks interesting – and that decision effectively sets a technology strategy for the organization. Cloud services rely on viral adoption by individual employees that becomes so widespread that companies start buying seats rather than processing all the individual expense claims. That could be the marketing team moving customer data to Salesforce, developers putting test VMs on AWS, calling a mapping service in an app, or just using an IDE in the cloud. There’s an API for almost everything – from making phone calls and sending emails or Facebook messages, to image recognition and transcription, looking up the specification of a car from a VIN number and paying suppliers. Most organizations have arrangements with payment processors, mobile carriers and other service providers, including central billing and budgeting arrangements. Developers adding a Stripe payment API to an application, ordering Twilio SIM cards for IoT devices, picking an authentication API for app sign-ins, or calling an electronic signature API for approvals in document workflows are unlikely to have the details of those corporate services. If the applications take off, you might find that a substantial portion of the operating budget is going through these new channels. These new services may be more powerful and valuable to the business than the old arrangements, but you’re also taking on external services that you might want to start monitoring for latency and uptime. And depending on the location of the data in your organization, you might also be depending on your internal network being completely reliable and available (which might not always be true for legacy applications on older platforms). If your organization relies on an API that turns out to be delivering faulty information, who’s liable for any problems that causes? Increasingly, development teams are making purchase decisions about platforms that would once have been centralised. MongoDB famously attracted developers by being packaged for convenience: the ability to just unpack a download and start working in 15 minutes was something a relational tool like MySQL couldn’t deliver a decade ago (and MySQL was easier to get started with than Postgres because it was in a repo). Although the defaults have since changed, if a developer in your organization picked MongoDB several years ago for cloud services-like convenience rather than features, you might end up with a database that was exposed to the internet by default because it didn’t have the right security features enabled. SEE: Cloud computing is the key to business success. But unlocking its benefits is hard work Similarly, using components from open-source projects can speed up development, bringing you coding best practices from a large community, for example, with tools like GitHub’s code scanning and Dependabot alerts to improve code quality. But it might also bring you vulnerabilities in packages like Log4j or a handful of the 1,300 malicious npm packages that WhiteSource detected in 2021 alone. Maintainers of the most popular packages on npm are now required to use MFA, but most npm packages include dependencies on dozens of other packages that you also have to trust. Architectural decisions also have wider impacts. Microservices let developers decouple code into functional units that they can update or replace independently, reuse in different projects and orchestrate into larger systems that provide scalability and availability. But that orchestration means that what you’re creating is a potentially complex distributed system where you have to care about managing state, dealing with the network and understanding consistency models – all the things that transactions in relational databases used to take care of. This may be exactly the right direction for your technology architecture to evolve, but that needs to be a strategic decision rather than a choice made by individual developers.
Managing the options
The implications of developer choices aren’t necessarily bad. What developers experiment with and find effective can turn into best practice that helps you gradually adopt new technologies and techniques. When developers can run scripts in a MongoDB instance that allow them to see what’s going on in the database directly, they’re no longer at arm’s length from production. Instead of calling a database admin when there’s a problem, they could work on database issues as they come up without waiting for operations to get involved. That’s exactly the kind of ‘shift left’ that starts organizations on the move to DevOps, where development and operational teams communicate and work more closely together, using monitoring and automation to speed up getting new features into production. Similarly, developers may adopt Docker because it makes installing new tools and sharing code with colleagues more convenient and far less fragile. But that can be a natural step towards containerising applications that you want to move to the cloud and refactor with new features that take advantage of cloud services, event-driven and serverless architectures and microservice patterns. Look for tools and practices to help you manage developer choices and set the right policies, for open-source and other technology choices. Software Bill of Materials (SBOM) tools use manifests like SPDX to help you understand your software supply chain. ClearlyDefined tracks licences, source locations and security issues for open-source projects. Look for the Open Source Security Foundation (OpenSSF) Scorecards that show whether key open-source components meet security best practices (like whether the project requires code reviews and fuzzing, signs releases or has unfixed vulnerabilities). You need to strike a balance here. This isn’t about micro-managing developers; it’s about understanding the implications of development choices the way you would think about the choice of services and suppliers you rely on in any other area of your business.
