The true cost of small changes

We use “T-Shirt sizes” as a quick, somewhat-visual way to estimate the effort we think implementing a change will take.

Here’s the scale we use:

Extra Small – Trivial to implement; a feature that you think will take only an hour or so to complete.
Small – A feature that you feel reasonably confident that you could knock out in an afternoon.
Medium – A feature that you are pretty sure in how to approach, and think you could complete in a day or two.
Large – Either a feature that you have a fair amount of uncertainty about or one that you know will take several days to complete.
Extra Large – A broad and complex feature, or something that you don’t know much, if anything, about.

They are deliberately granular, and non-contiguous. They’re designed to give a quick gauge of relative effort. We aim to provide a quick steer to the client as to whether it’s worth pursuing further or not.

Clients often prefer the certainty of a fixed cost, but they’re often surprised at the cost of those at the small end of the scale. Small changes are rarely cost-effective individually. Behind every change is a set of necessary, partly-unknowable, activities that we can’t control and the impact of them are magnified at this end of the scale.

It is tempting just to do the “quick-fix”, and skip the quality practices but this is a dangerous precedent and is what leads to the build-up of technical debt, and the cause of further bugs which begets more “quick-fixes”, and so on.

So what are some of these activities that surround the obvious part of software development?

Development “ramp-up” — getting the development environment running and getting into the headspace of the application takes some time –I like to think of it like the loading time of a video game–
Discussion and communicating with the client – smaller changes don’t lend themselves to up-front discovery, so that gets done on-the-fly with the client. This necessary and essential step can be unexpectedly time-consuming, sometimes taking longer than every other part of the process combined.
Verifying the change or fix. Making the change itself is quick, once you’ve identified the problem, but checking that it does indeed work and hasn’t broken something else can be time-heavy when there is no automated test-suite, meaning manual checks have to be done—how far do you go? Testing the whole application manually is infeasible. For us, in our work taking over poorly maintained codebases, this step is often magnified because we have become responsible for a codebase we didn’t write, and can’t know what dragons might be lurking beneath the surface.
As part of our QA processes any code written by a developer should be checked by another to make sure that it meets standards and maintains or improves the overall quality of the codebase.
Documentation needs writing or amending to ensure that it remains accurate and useful.

And this is when it all goes perfectly.

Small changes are often not particularly valuable— or at least are harder to quantify easily in monetary terms. But they are frustrating, and so fixing them is desirable. This is why we advocate strongly for setting up ongoing scheduled development time, batching several small changes together to deal with them quickly and efficiently.

One of life’s small pleasures is seeing the look of frustration replaced with a smile on our clients’ faces when longstanding niggles have been removed. If you have a laundry list of niggles or frustrations in your Ruby on Rails application, contact us to discuss whether retained development is right for you.