An Article

Budget Creep: How Change Impacts Custom Software Development Cost

Nick Walsh By Nick Walsh // 11.19.2021

Software development remains an expansive, experimental, young… and immature field. That immaturity flies in the face of the (occasionally overwhelming) complexity behind the platforms it creates. A quick search on just about any topic within software development is a deep, dark pit of competing opinions that change on the regular.

Big, impactful decisions lack consensus. Which language? Which process? We’re missing a quorum on which HTML tag to use sometimes, much less core business logic. These factors — immaturity and uncertainty — make software a field especially susceptible to change.

Let’s take a look at the roots of that change and the downstream impact it has on cost.

Software Change Through the Lens of Construction

We use a lot of construction analogies to cover software concepts. They’re familiar, similar, and being able to imagine something tangible helps cement (ha!) the idea.

When it comes to building or remodeling a home, there are plenty of costs that seem predictable: Materials, labor, permitting all feel like they can easily be inferred from previous projects. Surprise costs come from a few places, but we’re interested in change. Industry change, regulatory change, change of plans — all affect the predictability of price.

As a Florida native, I had a few family members in Miami stick it out through Hurricane Andrew back in ‘92. In the wake of the storm, area building codes were transformed. If you’d estimated new construction before and after, there’d be new line items like hurricane straps and impact-resistant glass to pay for.

Quotes in software development follow the same pattern. Features, hosting, team members — the core process seems predictable based on recent projects. When something like GDPR comes into effect, though, the element of surprise makes an appearance.

With that in mind, next we’ll dive into the ways change manifests in an application.

The Faces of Software Change

In the world of software development, change takes three forms:

  • Refinement of the industry. Given software’s importance in virtually every sector and the capital involved, there’s an incentive to move the needle towards maturity. Predictability in approach, lower failure rates, performance for increasing scale, the whole nine.
  • Regulation catching up with technology. Laws has notoriously lagged behind the speed of innovation, especially when it comes to privacy, consumer protection, and accessibility. As these rules come into effect (worldwide), new complexities spring up.
  • Refinement of the plan. No matter how meticulous, no set of software requirements survives from estimate to launch.

These three sources of change affect two main project parts: Implementation (through refinement of the industry and regulation) and process (through regulation and refinement of the plan).

Implementation: New Bars to Meet

A side effect of the march toward maturity is the parallel march towards complexity. As the quality bar rises for anything user-facing, the specializations and requirements behind it have to keep improving their pole vaulting skills.

Project Team Size

Webmaster was a popular title when I first dipped my toe in the pool of web development. Webmasters would handle everything: Design, markup, styles, functionality, servers, and even IT in a pinch. It made a lot of sense when Space Jam was the peak we all looked up to.

Design and development marked the first bit of separation as browsers improved to support things closer resembling “art.” The quirkiness of CSS helped shoehorn a front-end developer position in there, too.

These days, every role is trying its hardest to hit an inflection point and split, like some kind of specialization mitosis. Yesterday’s web designer may now be a product designer, interface designer, experience designer, illustrator, animator, or some other subspecialty. The same is true for any other software-related title.

This loops into cost on the back of expectation. What used to pass for a project team may not carry the collective expertise to match the quality of competing companies. Everyone wants to be the next Slack, but the Slack bar is set by 1500+ employees and contracts with a number of talented external firms.

Today’s good is tomorrow’s outdated, and what passes in implementation now won’t fly on the next project — each new specialty adds a decision (do we need it?) and an onboarding cost.

Performance, Responsiveness, Accessibility

Make things fast, make them work on all the devices you can, and make sure they’re accessible. The first two affect SEO and conversions; the last one has laws and fines attached.

It doesn’t take much evangelizing anymore to make these points a priority, but they’re all on a sliding scale. How accessible is accessible enough? How much has that changed in the last year? Does that require an additional team member with the requisite specialization?

In a field littered with moving implementation targets, these three have been among the most volatile.

GDPR and Data Security

Like that building code discussion earlier, laws and regulations around the world create new project requirements. Billions of dollars have been spent on GDPR compliance efforts. When’s the last time you visited a site, no matter how niche, that didn’t have that notification to accept cookies?

As laws catch up to the whole “move fast” thing the tech industry has been chanting for a decade, it’s inevitable that more line items will pop up on every estimate.

Process: Keeping the Bigger Picture in Scope

Process problems compound. It’s an expensive butterfly effect — seemingly innocuous decisions today can lead to flaming piles of money later.

Sprinting in the Wrong Direction

Seeing a result to end a weekly or bi-weekly development sprint is a huge improvement over a flippant “we’re still working on it” status update. It’s the best part of the agile movement.

Time and again, though, we see teams focus intensely on short-term cadence and lose sight of the bigger picture. Setting priorities on a weekly basis diminishes the weight of a change. It’s like making a single turn on a long road trip.

Several sprints and a few direction changes later, it’ll feel like progress has been made. But, if you haven’t kept sight of the end goal and accounted for those turns along the way, it’s not the right progress.

Backfilling Architecture

HIPAA compliance, internationalization support, event stores. The project roadmap may not need certain bits of data governance now, but backfilling architecture in a future phase is substantially more difficult than starting with it in place.

It’s a hard call, but there are foundational decisions worth making early. Heated floors are a tougher ask when they require ripping out and replacing perfectly good tile.

Real Data

Coming back to software requirements not surviving to launch, no interface survives first contact with users and real data. Wireframes, prototypes, designs — process can help get you to the right neighborhood, but polish and refinement of the underlying ideas is a necessary line item.

The sunk cost fallacy rears its head here often. It’s hard to let features go or simplify functionality that doesn’t test well after putting development time in.

Testing, Quality Assurance, and Technical Debt

No automated tests, a big change request… and a 1–20 hour estimate.

Opting out of proper code testing and data sanitization only reaps benefits in the extreme short-term. Soon, every change will become a nightmare to find, fix, and verify. The larger the platform, the more painful the debt that accompanies wading into the unknown.

Embracing Change with Custom Software

Custom software is an exercise in change management. Change isn’t a bad thing, and it’s unavoidable — it’s that whole surprise thing that creates trouble. As entropy in the form of specializations, tools, and overall expectations increases, the underlying effort will always carry a danger of surprise.

Planning for hidden costs comes in two parts: Finding the gas lines under the landscaping, and assuming they’re there in the first place. Early detection, early prevention, and even avoidance altogether is possible, but it takes experience and expertise.

Next Up

Speed Alone Doesn’t Define a 10x Developer

Nathaniel Bibler By Nathaniel Bibler // 11.17.2021

Measuring the performance of software developers has long focused on coding speed. But the real 10x developer is the one with clear vision and focus.