Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

marked as duplicate by MichaelT, gnat, GlenH7, Bart van Ingen Schenau, Dan Pichelman Sep 16 '13 at 23:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Not sure, I would perhaps close it to new answers so people can still see the question and then click through to the other site. –  Ben Thurley Sep 14 '13 at 23:09
2  
I like to use construction analogies. If you want to add a 2nd story to a one story house, you're going to need to strengthen the existing walls. –  Dan Pichelman Sep 15 '13 at 0:15
1  
@DanPichelman or just adding a addon, you need to break down some walls, while construction is going on some parts of the house is unusable,... –  ratchet freak Sep 15 '13 at 0:52
    
    
You're doomed. It is time to have the company lawyer review the terms of the contract, to see if there is a peaceful way out. That is, in software contracting, a "feature buffet" (where the payer can order anything without extra cost) will usually kill, or severely mime the business counterparty. –  rwong Sep 15 '13 at 2:27

3 Answers 3

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.

share|improve this answer

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?

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.