We speak to a lot of experts here at SD Times. Almost to a person, they talk about modern applications, tectonic shifts in development, scary scenarios of data breaches, the need for software to ‘be’ the business, and much more. But as I looked back on many of the interviews we’ve done, some overarching themes are still being discussed, even in the face of massive changes in the industry.

Vendor lock-in vs. best of breed
The pendulum is swinging again, only this time, the names have changed, and now there’s a twist. The “best of breed” side more often today is open source, which is exploding in IT departments due to its ease of use and low barrier of entry. With developers and deployment teams given more autonomy than ever to move quickly and release more often, any open-source tool they can find that can quickly help them create, deploy and maintain applications is added to the toolbox.

On the one hand, this model certainly helps organizations speed their time to market and quickly adapt to changes in their market. And development teams love the DIY capability without having to go through a lengthy procurement process to get the tools they need.

On the other hand, managing the APIs and data exchanges between these tools is becoming ever more complex, and creates the potential for downtime if APIs change and applications suddenly fail. (We won’t even talk about the shadow IT problem all this open source is creating inside organizations.)

So, at the other end of the pendulum sit the platform providers, offering abstraction layers that do all the heavy lifting of connecting data sources to applications, tools to tools and more. These platforms make managing that complexity easier, as it’s all done in one place, with one singular view into the systems that organizations rely on for their business life.

But here’s now the twist: Many of these platforms are also open source. While the vendors behind them offer 24/7 support and add functionality that the individual projects can’t or don’t provide, the platforms are open source. If developers choose to use the free version of the tool, they have to rely on the community to ensure the tool is on top of all patches and potential security vulnerabilities. So, has this argument simply become two sides of the same coin? Use the best open-source tools for the job you can find, but get them through a vendor that provides the support, management and updating required of an enterprise development tool.

Speed vs. quality and security
For most businesses today, their websites are the new window displays. This is where their customers visit to see what’s for sale, what’s on sale, to choose an item and make a purchase. And, just as they would change their windows as the seasons changed, so too must they change their websites, only more quickly, to take advantage of market conditions, deal with the unknowns (like pandemics, that have driven so much more traffic to these websites) and ensure a great customer experience.

But many experts had been discussing speed even before all the pieces necessary to support going fast were in place. Organizations likely have adopted Agile development practices, and have stopped monolithic development in favor of smaller services and modern architectures to tying those services together and swapping them out. And the cloud has become the data center of choice for many organizations.

But doing Agile and DevOps without having a test infrastructure in place, without having a security plan in place, will do more harm than the benefits you gain from going fast. We hear the experts tell us that “shifting left” will solve these problems. But asking developers to be responsible for development, testing, security, deployment, management and maintenance is like asking a plumber to build a house. He or she probably can do it, but it will go slowly and take a lot of time.

The point is, this is an exciting time for software development, but also a time that has brought much angst as organizations try to deliver on the vision of software eating the world. What they ought to do is go slow to go fast. Make sure the right skills are in the right place, roles are clearly defined, and everyone has bought into the mission before simply deciding to pick up the pace of development. We’ve already seen enough ‘one step forward, three steps back.’