The cost you don't see
The Hidden Cost of Features
Sure it might only take a few hours to code, but you're going to be paying for those features for years.
The act of dreaming of possibilities is incredibly addictive. The name of our agency even hints at how much we like to think big and consider the things other people have dismissed. Things others have already written off as unrealistic, too expensive, or too extreme.
When it comes to working with a client to plan the features of their new project, my inclination is exactly the same. I can't think of a more invigorating moment than the one where we're in sync, almost singing a duet about what we want to accomplish together.
They say "Oh wouldn't it be great if we could..." and immediately I reply with "Totally! We could absolutely do that, I am thinking of the ways in my head right now! Here is how we could approach that..."
I love pleasing people, it's one of my most endearing and self-sabotaging qualities. I love getting people excited and helping them find happiness. What I often forget though, is that making people happy today can sometimes be at the expense of their prolonged success and/or happiness.
It's easy with the kids
Somehow as a dad, I don't fall into this trap. The kids say they want something and it is almost ingrained in me to immediately respond with a big old slap of reality to show them what's what. After all, if I don't do it, who will? Disappointment and disillusionment suck hard, and I don't want any part of that for my kids.
I've had to work to tone it down over the years, find the middle ground so to speak. Hopefully, I've found the right balance, but the little voice that's telling me to immediately dash all my children's dreams is my desire to tell the truth as much as I can.
When we're willing to tell them the truth, it builds trust, and the same is true for our colleagues and our clients. Without that trust, our relationships are doomed for failure
How features end up costing you more than you think
In some ways, the cost of a feature is obvious. We sit down and we estimate the time its likely (or at least what we think is likely) to take and then we multiply out how long that is by how much we need to charge to make a reasonable profit, and we roll that into the estimate we give for the project (assuming we're estimating rather than pricing as Jonathan Stark tells us to).
This is the cost we all initially see, but if we're paying attention, we'll notice that this is never really the true total cost of the feature.
The initial build
Even during the initial build-out, the time we estimated when we originally drafted up the project, we can begin to overshoot our projected costs. There are a lot of ways this can happen, but there are two pretty obvious ones:
Scope creep
The most dreaded two words in software development, scope creep is when the specifications of what we're trying to accomplish change after we initially spec out the project. It happens for a multitude of reasons, and realistically it should be expected to happen on any project.
You may discover while building that the assumptions you had made when planning the feature out no longer appear to be true after implementing other features in the system.
The client may discover, or remember, that what they think they need now is different than what the team dreamed up at the project's inception.
Neither of these things is bad, it's the natural course of software development, and it's a good thing to apply what you've learned along the way to improve the results of the project. You aren't going to just discard what you've learned, are you?
The thing is, this is very likely to make the project take longer (and therefore cost more, either to the developer, or the client). On occasion you may find you reduce scope as you go because the project simply doesn't need what you thought, enjoy it when it happens.
Software developers are terrible at estimation
We all know this, and in reality, humans in general, are terrible at the estimation of novel tasks. There is a high likelihood that unless this project is cookie-cutter, and therefore you are doing the same thing you've done many times before, you are going to underestimate the time it takes to complete at least some of the features of any given project.
I've underestimated a project by more than 100% multiple times, and one large project I was involved in went over the estimated time by somewhere close to I believe 500%, and this was a project taken on by a seasoned software team that had shipped multiple on time and under budget projects over the majority of a decade with a combined experience of probably more than 20 years doing very related software.
After the initial build
After you've completed and finally shipped the feature, your work is very likely not done. Few features are perfect the first time they're released, either because the requirements relied heavily on assumptions that later change, or were poorly understood to begin with, or because the quality of the implementation was constrained by the initial timeline or budget. Here are a few ways you're going to keep paying for this feature for as long as it lives:
Bugs
If you didn't already know this, all software has bugs. When planning for a new piece of software, you should be planning for this unavoidable truth. These bugs won't neatly present themselves during internal, or external testing, many won't even rear their heads in the first year the product is released. Some may never be discovered at all. Your software will have bugs, and someone has to pay the programmers to find and fix them.
Maintenance and Security
Sometimes, the software your dev team wrote won't have any show-stopping bugs in the code itself, but it's very common for the code that we depend on to have semi-regular security releases (and you guessed it! There will be more of them the more feature-rich the software is!). To keep your application safe and trustworthy, you need to regularly have these updates applied.
The number of external libraries, modules, or plugins your application uses will likely be directly correlated to the number of features you have. Think of this as increasing your security surface area or the maintanance footprint of your application.
The more external dependencies you have, the more time that is going to be dedicated to keeping those dependencies up to date, and replacing them when they are deprecated or no longer supported.
Developer cognition
Maintaining, extending, updating, and fixing existing code requires the developer doing the job to have at least some level of knowledge of how that code behaves.
The quality of their work will be directly related to how well they know the code they are working with. Several things impact this capability:
- The developer's experience/skill level
- The developer's tenure at the company and / with the project
- The complexity and novelty of the code
- And most importantly for this discussion: the amount of that code
Each feature carries with it accompanying code to make it work, and each line of code carries with it an amount of complexity and cognitive load.
This load slows programmers down, and what slows programmers down costs the project extra money.
Infrastructure cost and performance
Additional code is not only expensive for your developers to write and maintain, but it's also expensive for your CPU and your consumer's CPU to run.
Additional Javascript libraries to handle everything from marketing data collection to fancy slideshows and annoying "innovative" click-and-scroll jacking all add both data cost and CPU/time cost to your web pages.
Visitors/users use more cellular data to download your pages and more CPU cycles and therefore volts from their battery to parse your HTML/CSS and Javascript and even more to execute that Javascript.
This directly costs them more money over the long haul and costs you in page speed scores (potentially lowering the number of users you can be fed from search engines and the number of those users that complete your conversion targets).
On your servers, the additional CPU cycles that it takes to churn through your server-side code to handle complex features, the more you pay your cloud hosting provider to support your project, and the fewer users you can serve given the same hardware.
What do we do with this information?
It's great to have a general understanding of these facts but what actions can we take based on this knowledge?
Be wary of low estimates
Developers are going to underestimate the time it takes. If an estimate or quote comes in much lower than its competition (either within a software team or in a vendor relationship) be skeptical of the estimate. This is a good sign that initial quality may be low, or that the development team is trying to bid low to make up the cost later. Conversely, consider high estimates as a sign that you're less likely to deal with paying extra for the overruns later.
Be willing to postpone ideas
I don't want you to ever stop having, expressing, or developing new ideas for features that could make a big impact. These are the things we get excited about and the things that make software useful. I only caution to prioritize the features that are pressing and important and to postpone further enhancements until there is some breathing room in the schedule and budget to consider them. You'll only learn more in the intervening time. If an idea keeps coming up over and over, it may be a sign that it is time to take it out of the icebox, hone and refine it, and get it on the schedule.
Advocate for smaller software
I don't expect non-developers to know the nitty-gritty of what features make the software heavy from either a performance or complexity standpoint, but what they can do is ask developers how the feature will impact these metrics and listen to the feedback given.
Consider setting performance budgets for request size or page speed score early and ensure any shipped software doesn't overspend that budget. Ask the development team to use tooling to monitor the code complexity (like CodeClimate). Good devs will jump at the chance.
In the end, we want to avoid surprises as our software ages, and aside from the admonishment to perform our regular maintenance (as our mechanic always tells us!), we can also ensure costs stay under control by simply writing less software and focusing our energy, time, and money on software that matters.
