We maintain a web application for a client who demands that new features be added at a breakneck pace. We’ve done our best to keep up with their demands, and as a result the code base has grown exponentially. There are now so many modules, subsystems, controllers, class libraries, unit tests, APIs, etc. that it’s starting to take more time to work through all of the complexity each time we add a new feature. We’ve also had to pull additional people in on the project to take over things like QA and staging, so the lead developers can focus on developing.
Unfortunately, the client is becoming angry that the cost for each new feature is going up. They seem to expect that we can add new features ad infinitum and the cost of each feature will remain linear.
I have repeatedly tried to explain to them that it doesn’t work that way – that the code base expands in a fractal manner as all these features are added. I’ve explained that the best way to keep the cost down is to be judicious about which new features are really needed. But, they either don’t understand, or they think I’m bullshitting them. They just sort of roll their eyes and get angry. They’re all completely non-technical, and have no idea what does into writing software.
Is there a way that I can explain this using business language, that might help them understand better? Are there any visualizations out there, that illustrate the growth of a code base over time? Any other suggestions on dealing with this client?
5
A few pieces of advice. First, use an analogy – pretend you were implementing this without computers, such as doing it by mail (not E-mail). As you add features, visualize the form customers fill out getting more and more complex. Think about the increased breadth of skills required by staff and the number of staff required to fulfill each function. Talk about the increases cost to manage the increased staff, such as management, training, HR, payroll and so on. Computers can do this faster but most other aspects still apply.
Second, gather code and QA metrics such as the number of bugs found, code complexity, automated test coverage, time to develop, time refactoring (if any) and so on. If you have QA, capture the number of tests required for a full regression and the time needed to run them all. Support increased costs with facts makes them much harder to argue with. Even a simple diagram showing the number of and interdependencies between different modules may help.
Third, gather analytics about how customers use your software. If you create a feature no one uses, being able to point to an automatically generated, auditable source of truth can help you prioritize work (at worst) or avoid unnecessary features (at best).
Fourth, get an outside opinion. This may or may not be viable depending on the company size and structure but pull someone senior in from elsewhere and get an unbiased opinion. They will likely suggest a mix of improvements to development practices (a win for you so you can get time for refactoring or increasing your output) and better prioritization of features (also a win for you so you have fewer, better features). Alternatively, suggest relevant reading like “The Lean Startup” by Eric Ries.
Last but not least, try to understand the business case. Why do you think the business is driving these new features as hard as they are? Are they trying to keep up with competitors? Are they under pressure from their management to deliver? Perhaps the people driving you are the symptom and not the cause. An “us and them” mentality is counterproductive. It may be extremely difficult at first but this will help you in the long run.
I have been in your shoes before. And its a little more simple than you think. Put yourself in their shoes. Which means you need to stop using words like fractal and code base… they have no idea what that means. I am not trying to be mean here. However, you need to address your audience in a way that they will understand. In my case I fully involved them in the development process and made sure they knew what each resource was doing and how adding a new feature would impact that resource. You may even have to reveal cost to them by letting them know that, this engineer who is working on the feature you asked for last week is getting paid x per hour. You now need him to split his time to work on these two other features you are wanting next week. He is the only engineer on the team with that skill. The business managers need to know a lot more detail but in a less techy way. Does that make sense?
I am using simple way to manage requests for adding new functionality.
Each new functionality that out of initial scope should be estimated.
So when customer asks to add some feature, I and my team think what should be done, and how
it could be done. When we have all necessary information we prepare estimations and
describe what parts of the system should be updated to have requested feature done.
Without many technical words. And when customer see ETA he can calculate final price.
Then he decide, do he want this feature or not.
Do not agree on each customer request without any word.
Each feature should be discussed, agreed and estimated.