Software Development: Fixed Cost or Opportunity Cost?

May 23, 2013 OpenSystems Media

When starting a new project, part of the decision making process is deciding which components to design in-house, and which are best left to external vendors. Sometimes the dividing line can be as simple as outsourcing the hardware platform, and doing all software development internally, but the choice is often far more complex.

If we examine the simple hardware/software division a little further, this may not be such an unrealistic scenario after all. In this case, the company has decided that their core competency is in software design, and that they will be able to differentiate themselves through the innovative software they create on top of commodity hardware. Here, the company has recognized that by intelligently allocating their limited resources, they will accelerate time to market, and greatly improve their chance for success.

A more realistic scenario is a company that decides to keep some hardware and software development in-house, and outsource or contract the rest. Again, this partitioning usually emphasizes the internal strengths the company has, and leaves the highly specialized aspects to outside experts, such as designing radio-frequency modules, or implementing very low-level software components.

In doing this analysis, the company would also need to compare the cost of developing a component in‑house versus buying it ready-made. Assuming the component under consideration would provide limited differentiation if developed in-house, but still needs to be robust, there is often the temptation to keep the development internal to guarantee quality. Many companies falter here because they view their resources as fixed cost.

While a full-time employee may indeed be a fixed cost from an accounting standpoint, they are not a zero cost employee. There is the opportunity cost of having them work on a component that provides limited differentiation in the market. And, more importantly, the long term time and effort to support specialized components.

There are studies which assert that the typical designer throughput is 20 to 30 line of code per day. Not per hour, but per day. Clearly, this is an area of intense and heated debate, especially among the designers themselves. However, when you add up the time needed to properly design, review, document, and test each line of code, that value becomes quite accurate. Especially when evaluating highly specialized software components.

Now, let’s consider a specialized component that requires 10,000 lines of code. And, let’s assume the textbook studies are conservative by an order of magnitude, and that software engineers are capable of 300 lines of designed, reviewed, documented, and tested lines of code per day. This means six to seven weeks of designer time (again, assuming the studies are off by a factor of ten). At an average pay rate of $80,000 per year, this means approximately $10,000 to develop this one component, not considering the overhead of support staff, IT infrastructure, etc.

Worse still are the long-term maintenance costs of developing a component in-house that does not add differentiation to your end product, or requires significant long-term support effort due to its complexity or specialization. The original developer may need to be pulled off a future project to debug or update the component, resulting in unplanned delay. And, not only does this delay impact the current project, it defocuses and demotivates the developer. They may have welcomed the challenge of the initial task, but being asked to support it many months or years later is a less enjoyable.

Overall, the challenge of deciding what components to develop internally, and which are best left to specialized external vendors, is a complex one. Many companies, especially large ones, view their designers are being a fixed cost. And while they are, from a pure dollars and cents perspective, the bigger cost is the opportunity cost, and the impact on time to market. Large companies need to consider smaller, more agile companies. And, similarly, small companies need to allocate their limited budgets to areas that differentiate and highlight their strengths.

A new white paper from ARM on the thinking whether to “buy” or “make” shows how embedded software thinking needs to shift.

About Anthony Pighin
Anthony has almost 20 years of experience in software development and customer-facing roles, and has worked with companies in Canada, the United States, Europe, and throughout Asia. He holds a B.Eng in Computer Systems Engineering from Carleton University, Ottawa, Ontario, Canada, and currently heads sales and strategy for Code Time Technologies.

For more information about Code Time Technologies, please visit:

Anthony Pighin, Director, NPI and Partnerships, Code Time Technologies
Previous Article
National Instruments platforms and tools evolve for IIoT developers of all skill levels
National Instruments platforms and tools evolve for IIoT developers of all skill levels

Almost 31 years ago National Instruments (NI) introduced LabVIEW, one of the first visual programming langu...

Next Article
What exactly is software-defined storage?

"Software-defined storage" (SDS) is one of those terms where if you ask ten people for the definition, you'...


Stay updated on Developer Tools & Operating Systems with the Dev Tools and OS edition of our Embedded Daily newsletter

Subscribed! Look for 1st copy soon.
Error - something went wrong!