Avoiding In-House Development Tools Now May Pay Off Later

Software engineers are builders - so it’s only natural for them to want to build in-house proprietary software tools, customization and integrations. But that instinct can often be problematic for businesses. Here are some reasons you should think twice before letting your engineers build their own internal software:

• Tech savvy investors are wary of custom internal software. On the AWS Podcast, MacLaurin Group partner Alan Williamson noted it’s one of the primary goals for the businesses they acquire: get rid of bespoke software. Why? Because it’s hard to scale if your development process doesn’t rely on industry standards. The engineers or consultants you hire can’t be expected to know how to use your custom, internal tools.

• The technical debt of non-consumer facing software will almost always increase over time. While it might be initially exciting for your team to develop its own tools and integrations, few like to properly fix the flaws are discovered later.

• Developing internal, custom tools may make your team feel in control, but it’s an illusion. Your custom software will still run on ever-changing technology platforms and interact with external software in ways that will require refactoring or patching anyways. Is a short-term fix now worth being stuck with a problematic legacy application later? 

While the dynamic pace of software development will always present challenges, there’s growing evidence that the best performing DevOps teams avoid using proprietary tools when possible. Dr. Nicole Forsgren released an extensive study with Google Cloud on DevOps practices compiled from responses of 31,000 IT professionals. You can read the entire 2019 Accelerate State of DevOps Report here.

On pages 59 and 60, Dr. Forsgren notes that among the lowest performing DevOps teams, 20% relied primarily on in-house and proprietary tools. The better performing teams only did so 5% to 6% of the time. Respondents in the lowest performing group were also more likely to rely primarily on a mix of heavily customized open source and commercial off-the-shelf products. The better performing DevOps respondents were also 3 to 5 times more likely to primarily use open source tools with little customization - and planned to use more.

In another recent study by Forrester Research on tools and toolchains, they found 20% of their respondents also relied on manually hard-coding custom integrations between tools. They noted this practice isn’t only time-consuming, but error-prone and insecure. The complexity of the number of tools and toolchains is already making it impossible for any one engineer to actually know how they all work together. Using bespoke tools and integrations only makes it even harder.

Of course, there are times to build custom internal software and there are challenges to managing open source and off-the-shelf tools as well. But open source shouldn’t be dismissed as insecure any more than tools developed internally should be considered “free”. In fact, Dr. Forsgren also found that contributing and being involved in a vibrant open source community helped engineers feel productive and reduced burnout.

The Forrester report also came to the conclusion that it would be better for teams to adopt out-of-the-box toolchain management solutions. 47% of respondents that had reported an increase in security, 46% an increase in revenue, 45% an improvement in quality and 42% an increase in developer productivity.

Buying a product to make your toolchain more manageable and secure can be well worth the price of resisting your engineer’s instincts to code all the integrations themselves.

Again, there is no denying that with the ever increasing complexity of tools and toolchains that custom, in-house solutions are going to be part of your development environment. But there’s lots of evidence to suggest you should try and make it as small a part as possible. After all, would you rather your highly-skilled AWS DevOps engineers spend their time cutting cloud costs by retooling your architecture to use Spot instances - or constantly paying off the technical debt of ‘fixing’ your legacy, internal applications?