As a software system grows, it's important to start evaluating new features not only on how hard they are to build but how hard they are to maintain and most importantly, test. If you want a reasonable assurance that a feature is going to work correctly after each new release, then somebody (or something) needs to test that new feature before each release.

More features means more testing for each and every release, and therefore a system gradually gets more and more expensive.

New features have different costs in terms of testing which may not correlate at all to their cost in terms of initial build. Let's divide them into three categories:

Barely Noticeable

If a feature fits in to an existing test plan, the ongoing cost of testing the feature may be very slight.

As a simple example, suppose you add a new field to your registration form, to collect the user's favorite sport. Your existing test plan already covers registering a new user, and verifying that their data was persisted correctly. Verifying that this additional field is handled correctly will increase the testing burden only a tiny fraction.

Linear

If a feature causes you do add an new test case (or a few new test cases), the testing cost is linear.

For example, suppose you add "contact us" form as a new feature. A user is taken to a page where they may fill in some feedback about your site. On submitting the form, an email is sent to help@example.com.

Your standard regression test plan would now need to include a test case or two to make sure that this form was still working correctly.

Exponential

These are the ones that hurt.

If you start with a feature that has N different permutations and then you add another "dimension" to the feature that has M permutations, you now have NxM test cases instead of just N!

As a very simple example, suppose a user was allowed to customize their home page to display a custom color scheme (4 choices). To effectively test this, your existing test plan contains 4 test cases. Now you add a custom background-image (4 choices). Now to effectively test the home page you need to perform 4x4=9 test cases.

Automated Testing

Of course, automated unit testing, or fully automated regression testing can lessen the burden of testing "multi-dimensional" features. However, automated testing isn't free either.

First, somebody needs to write the test cases to begin with. If this can be done by writing some simple nested loops in your test case - it's not so bad. However, if there are any substantial differences in the fixture data that needs to be set up for each permutation in your grid, this can take a good deal longer.

Second, something needs to execute them. If some crazy new dimension came along and multiplied your entire unit test suite by a factor of 3, the time to execute a full suite of tests just went up by three. Regardless of how fancy your continuous integration system is - that's going to hurt productivity.

Finally, somebody needs to maintain the test cases. More test cases means the next time you a) upgrade your unit test framework or b) upgrade your core data access layer... the more work you've got to do.

Reality

Obviously, you can't turn down every request for a multi-dimensional feature. But next time, give them the care in costing that they deserve.