Analogy is one of the most powerful tools in written and oral communication.  It serves as the foundation for which understanding is built between two parties who have differing backgrounds and experiences - some common knowledge, which both can relate to, and upon which mutual agreement is forged.

So, it's no surprise that analogy always comes into play when aligning business constraints with the software engineering process, most commonly with regard to budgeting.  

Common Software Development Analogies

Buying a Car

The "like buying a car" analogy is often used in small to medium projects.   I believe its rooted squarely in the fact that projects of this size tend to be priced similarly to what you'd expect to pay for a low to medium end luxury vehicle if you drove it new off the lot.  

As individuals, we have a pretty good understanding of this process--we've likely purchased a car before, sometimes many cars, and we have a well defined understanding of the value the vehicle going to bring, the long term costs of maintenance, the responsibility of the party who sold the car to us, and specifically where that responsibility ends and ours begins.

The reality is that building a custom software product isn't like purchasing a finished product at all, car or otherwise. The analogy could be strengthened by comparing the process to designing and building a car, which involves ideation, sketching and preliminary design, prototyping, tooling, testing and tweaking.  There are always flaws which get ironed out through iteration and refinement.

When a company designs a car they budget it as R&D and spend millions to get it right.  Software development is research and development too, but when we're able to hit a price point that's comparable to BMW's mass-produced finished product the value proposition becomes a lot more clear. Expectations must be clear: there will be flaws, but they can be iterated over and improved upon.

Building a House

The building a house analogy comes up consistently in our work.  Medium to large software projects fall in a price spectrum similar to the construction of a private home or small commercial structure.  

Again, as individuals we have a pretty good understanding of this process as well.  We may not be intimately familiar with the details of construction, but we all pay for housing in one way or another.  We have an understanding of property values in our markets, that the size and complexity of those homes are commensurate with their price, and most importantly that it takes a significant amount of time to complete.

This analogy is more accurate than buying a car:  it's not factoring in mass-production or economies of scale, it accounts for the design process, and the budget consequences changes mid-construction, and most importantly it frames the process as one which is labor intensive.

It's still flawed though, the biggest reasons being the predictable cost of materials and the safe assumptions one can make in constructing a physical thing.  Let me give you an example:

I want to install bamboo floors in my home (good choice).  I visit a flooring store where the floors have already been produced, boxed, and ready for purchase.  They cost $3/sqft, and my home is 2000sqft.  My general contractor installs these floors several dozen times per year and knows exactly how long the process takes and they charge $2/sqft for installation.  My flooring will cost $10,000, with minor contingencies (< 10%) to buy an extra box or two of flooring for cuts and factoring in unexpected labor for a tricky portion of the installation.  

There's no analog for this in software engineering.  We simply cannot visit the user authorization store and purchase a pre-built access control model and install it in your application.  Sure, we've built user authorization many times before, but every component is tailor-built to the use case.  To fit the analogy, we have to engineer our own wood.  When it comes to installation, flooring might have a handful of variables which are all known at the time an estimate is given:  the type of foundation and sub-flooring of a home, local building codes, and the layout of the home.  In integrating software systems, there are an unknown number of variables, some of which are discovered in planning but the majority of which must be uncovered during implementation.

Even the basic physical properties of a home's layout have no analog in software engineering. Maybe there's a wall on the north side of a room, but the blueprints stipulate that people over a certain height must be able to walk through the wall.  Software can do that, but there are an enormous amount of rules which must be defined and accounted for, and often countless edge cases which must be accounted for, designed and tested.

DIY on Payroll

The most common analogy encountered in software development is the equivocation to a software engineer's direct payroll cost.  This analogy is rooted in some truth:  it acknowledges that software engineering is labor intensive and that the dominant cost comes from human resources.  But, this direct comparison of "what would it cost to do this internally" also has flaws.

Buyers who aren't familiar with the hiring climate in software development might be shocked by exactly how expensive engineer labor actually is.  Here's the national average for a Senior Developer compared to our local market in Fayetteville, Arkansas:

source: https://www.glassdoor.com/Salaries/index.htm

Compare this to a much more expensive market like Washington DC and you'll see that cost can climb quickly depending on your geographic market:

source: https://www.glassdoor.com/Salaries/index.htm

Buyers who aren't in the technology industry might immediately realize that developer labor is more expensive than they are accounting for.  But, this doesn't actually account for the total cost of hire.  In a sector which has a massive shortage of highly skilled laborers, competing for talent requires highly competitive compensation and benefits packages that quickly add up to as much as a 20% increase over base salary.

The Actual Value Of Development Staff

This is only part of the story:  Developers operate in teams, so a single engineer in a vacuum cannot be expected to deliver quality software.  Even when Lofty engages a client on a full-time-equivalence basis of 40 developer hours per week, clients have access to our entire team when a challenging problem arises.  Each member of the team has unique specialities which give them an advantage solving specific types of problems.

Developers also require management and professional development.  A developer with no project management assistance will not be able to keep stakeholders aligned with the software development lifecycle.  Additionally, a developer with no technical leadership will stagnate in their position, ceasing to develop professionally and falling behind the curve on an industry which changes rapidly.  Good engineers crave professional development, and they'll turn over rapidly in its absence.

The reality is that to build an effective development team, you need a team which has been vetted and built to work together well.  It requires technically competent leadership structures, project management resources, and multiple developers who have complementary skill sets.

So, no, you cannot replace the outsourced development of a $100,000 software project by hiring your own senior engineer for $100,000/year. The decision to bring development in-house is a big one that requires a large staffing and professional development commitment not just for your project, but in perpetuity as long as that team is on payroll.

It's about money

It's no surprise that each of the analogies above are rooted in cost. There are two primary concerns of a software development engagement:

1) Will the software solve my problem?  

2) How much will it cost?

In any sort of successful engagement, the answer to number 1 must be a given before cost evaluation is worth the buyer's time, and that leaves pricing as the big unknown.

Why Good Analogies Are Necessary

As humans, we lean on analogy to try and measure if costs are aligned with value and the analogs I mentioned are the common go-tos. But, because software development is so radically different from the common purchases we're familiar with outside the tech world, it's very easy to draw false-equivalences between software engineering and what we already know.

As consultants, its our job to help clients understand our value, and that sometimes includes analogy - but we have to clear up the discrepancies, and make sure comparisons are fair and accurate to truly communicate value in a familiar way.

‍