Hidden Software Development Costs That Crush Your Bottom Line

| November 17, 2016 | 1 Comment

Would you commit 19 developers to building software that was already available off the shelf? Especially if I were to tell you that it would cost millions of dollars more to do it yourself?

Recently, I met with a company—a large healthcare organization—that actually did this. Following a demo of our XL Release and XL Deploy products, the Development Manager turned to me and said: “That’s good, but we’ve already built-it.” That struck me as a bit…ambitious given all the work they have to do just to develop products for their own customers.

red-onionSo after peeling back the onion a bit, we uncovered that they were using an astonishing 19 developers to create builds and deployment scripts using Jenkins. Not only that, they also needed every single one of those 19 people to manage and maintain it. Every. Single. One.

Lastly, I did a rough calculation of about how much it cost them to do the job in-house:

19@ 100,000 (USD) FTE + 1@ 150,000 (USD) FTE = 2,050,000!

This is pretty simple math, but the grand total is over 2 million dollars—just to build it.

This is not chump change. This is serious money going out the window to develop software that’s already been made and paying an obscene amount of cash for the privilege of doing so. It’s enough to send the most stoic of CFOs into apoplectic shock. And that would be the appropriate response to spending millions of dollars on software that’s already available out of the box.

plugsIt’s also unnecessary. As I discussed with the Development Manager, our products automate deployment and pipeline orchestration so you don’t have to worry about building any of that. We also give you visibility so that, with your time freed up, you can focus on figuring out what’s not working and address real problems that are inhibiting your success. I explained that, if they were using our software, they could auto generate workflows.

They could plug in the tools they’re already using, which lets them continue to use the right tool for the right job. For example, they could continue to leverage Jenkins for what it’s great at—continuous integration. They could expend their energy on revenue-generating products for their customers. And they could scale the whole thing to meet growing customer demand without the blood sweat and tears that scripting entails.

Unfortunately, like a page out of the Phoenix Project, the manager had lost focus on the company’s higher objectives, which is, of course, understandable when you’re busy overseeing a staff of 19 people. For managers, it may help to occasionally remind themselves of this fundamental rule:

DevOps = people + processes + tools for the purpose of serving customers

In fairness, this manager wanted the development team to be happy, but developers are happy when they’re building software. They are not happy maintaining it.
Lots of people think that using tools like Jenkins, Puppet, Chef and all the Open source tools to build orchestration and deploy solutions makes it free, but really, it’s not. And this company, with the 2 million worth of software development they’re putting into it is a hair-raising example of that. That figure by the way, does not include the additional hundreds of thousands per year for ongoing maintenance. It also doesn’t include reporting, which the manager of the team told me was planned for phase II.

If I were a CIO, VP of Operations, or VP of Development, I would want to know how I can build my bottom line not crush it. If just 15 of those developers were freed up to develop more software that customers will pay for, I would make damn sure they didn’t get tied up doing unnecessary internal projects that suck hard-earned revenues down the drain. Wouldn’t you?

Recommended Case Study


Patrick Bishop

About the Author ()

As VP of Sales for XebiaLabs, Patrick offers a distinctive blend of sales savvy and technical know-how. His experience includes over 15 years driving enterprise software sales, plus a background in software engineering for the financial services and military sectors. He has worked extensively in DevOps and in the areas of SecurityOps, compliance, and privacy for Fortune 100 insurance and banking organizations. Patrick has long history of developing and launching start-ups and a track record of dramatically growing revenues from the ground up.

  • Christopher O’Malley

    Excellent point and important consideration for leading in the digital age.

    As a CEO, I worry most about discovering worthy ideas that matter to our customers and turning them into deliverables that make a difference…continuously. I want everyone within Compuware inspired and enabled to continuously improve our ability to serve our customers’ interests. Your example illustrates a lack of understanding of the most basic and essential tenet of an enterprise – serving your customers. A financially healthy and growing enterprise should have too many ideas for the available resources to deliver which manifests itself as a backlog. Product Managers should be making gut-wrenching decisions on prioritization of deliverables in best serving customers. As a partner in business, development should be continuously improving their throughput to deliver as many ideas as possible in best serving customers. Having 19 people work on efforts that continuously leave worthy ideas for serving customer in the backlog when those efforts could be more effectively/efficiently achieved/maintained in the form of a consumed service or tool is exactly the wrong thing to b doing in the digital age.