The costs of configurable settings in your web application
By and large, the received wisdom when it comes to configurability and flexible settings for web applications is that more is better. Making something configurable frees up the engineer from having to make mundane (but necessary) changes that can be left to other people. It's desirable to change the state of software without having to rebuild or redeploy the code. There are a lot of obvious benefits to making software configurable, and these benefits are plain to all.
What I'm going to focus on here are the costs of configurability, based on my experience and observations over five years of writing web applications full-time. These costs apply to other kinds of software beyond the realm of web applications. I just choose to limit the scope of discussion to web apps because these costs manifest themselves the most when there's a fast development cycle and rapid iteration.
The following is intended to be a comprehensive, itemized breakdown of the costs of making an application setting configurable by the user. By itemizing and breaking these out separately, my intention is to make it easier to count the costs. For any given web application, it will be easier to see which of these apply, and to what extent.
The up-front cost of developing it as a setting. It comes as no surprise that the up-front cost is higher and requires more time than hardcoding, and is thus the most immediate and salient concern for the lazy programmer. If you're treating it as an investment and the setting is important, then of course it will pay off later. But if you're moving quickly and pushing out new features every week or even several times a week, the up-front costs of the things you're doing will be very important.
The cost of developing visual flexibility to accompany a setting. If your setting involves anything that has an impact on the visual presentation of any pages, be sure to consider that. For example, if you want to support different widths for a column of text, it is probably in your best interest to delineate discrete acceptable values rather than allowing continuous values. You'll know how to handle widths of 100, 150, and 300, for example, and you'll have to test them out to see how they look, but you probably don't want to allow just any width. Other situations may warrant a limited range on values; these values can be continuous, but restricted within a certain range. For example, if you have a setting for the maximum length of a summary text field, you'll probably want to test how your layout handles the minimum and maximum lengths of the summary text.
The cost of attention when sifting through all the other configurable settings. Even if it's relatively easy to change a setting, your love of settings probably means you've got even more settings. If you take the simple approach in laying these out in a list of settings for you to scroll through, there's a cost you incur. The cost of paying attention to this setting in the midst of all your other settings is one reason to stop and think whether you really want it to be configurable, but it's also one way you can force yourself to be more discerning and make only the most critical things configurable.
The cost of informing all stakeholders. This becomes more important as the size of your organization grows. The part to be concerned about here isn't in letting everyone know just that the setting exists or where to find it; that's a simple matter and thus negligible. It's in telling everyone involved and making sure that they understand what the setting does, whether it has any side-effects, valid values for the setting, and whether it's a critical setting that should be changed with caution. It's surprising how easily people forget, especially if it's a rarely used setting.
The cost of determining a default fallback value. How failsafe do you want your code to be? Chances are you'll have some situations — such as bringing up a greenfield installation, restoring from backup, and database unavailability — when you won't have access to the setting. If the setting isn't available for some reason, what kind of default value do you fall back to and how do you proceed? Will this default continue to hold true and be valid as your software matures?
The cost of abstraction and the cognitive load associated with translating it to concrete results. To make some things configurable, it may be necessary to generalize and turn the setting into an abstraction. Take the problem of content management functionality on your custom webapp. You may end up having to manage embedded Flash SWFs, images, simple blocks of text, or any combination of the above. Many content management systems call these "page elements" to encapsulate their full versatility, but this kind of abstraction is another step away from merely "image block" or "text block." What's the URL for the "graphical element" — in other words, the URL for the image? In using a general tool for a specific case, you end up having to refer to things in the most general terms first and translating them into their specific names, rather than calling them just what they are. This costs you time. Time is money, and it adds up.
Now, given these costs, what is one to do? In software engineering and in politics, we resort to compromise. For example, we could hide a setting from users so that only developers or sysadmins can change it. This way, you maintain the configurability that you want and avoid many of the unnecessary costs listed above.
It may also help to know the nature of each setting: are the acceptable values discrete or continuous? If they're discrete, such as officially supported sizes for visual elements, you can impose restrictions on values that you accept so that it's harder for the users of your application to shoot themselves in the foot.
Ultimately, in any discussion of costs, no matter how focused and limited in scope, we must remember to consider the benefits. Neither the costs nor benefits considered alone give us a complete view of any situation, and each must be considered to give context to the other. The difference is that costs are difficult and unpleasant to pinpoint and isolate. They don't receive the attention they're due, but who could blame us? We prefer to look on the bright side and think instead about reaping benefits. We enjoy watching our projects and our companies grow. But it's by being aware of our costs and knowing what hampers us that we free ourselves up to build more of what we want.
What I'm going to focus on here are the costs of configurability, based on my experience and observations over five years of writing web applications full-time. These costs apply to other kinds of software beyond the realm of web applications. I just choose to limit the scope of discussion to web apps because these costs manifest themselves the most when there's a fast development cycle and rapid iteration.
The following is intended to be a comprehensive, itemized breakdown of the costs of making an application setting configurable by the user. By itemizing and breaking these out separately, my intention is to make it easier to count the costs. For any given web application, it will be easier to see which of these apply, and to what extent.
The up-front cost of developing it as a setting. It comes as no surprise that the up-front cost is higher and requires more time than hardcoding, and is thus the most immediate and salient concern for the lazy programmer. If you're treating it as an investment and the setting is important, then of course it will pay off later. But if you're moving quickly and pushing out new features every week or even several times a week, the up-front costs of the things you're doing will be very important.
The cost of developing visual flexibility to accompany a setting. If your setting involves anything that has an impact on the visual presentation of any pages, be sure to consider that. For example, if you want to support different widths for a column of text, it is probably in your best interest to delineate discrete acceptable values rather than allowing continuous values. You'll know how to handle widths of 100, 150, and 300, for example, and you'll have to test them out to see how they look, but you probably don't want to allow just any width. Other situations may warrant a limited range on values; these values can be continuous, but restricted within a certain range. For example, if you have a setting for the maximum length of a summary text field, you'll probably want to test how your layout handles the minimum and maximum lengths of the summary text.
The cost of attention when sifting through all the other configurable settings. Even if it's relatively easy to change a setting, your love of settings probably means you've got even more settings. If you take the simple approach in laying these out in a list of settings for you to scroll through, there's a cost you incur. The cost of paying attention to this setting in the midst of all your other settings is one reason to stop and think whether you really want it to be configurable, but it's also one way you can force yourself to be more discerning and make only the most critical things configurable.
The cost of informing all stakeholders. This becomes more important as the size of your organization grows. The part to be concerned about here isn't in letting everyone know just that the setting exists or where to find it; that's a simple matter and thus negligible. It's in telling everyone involved and making sure that they understand what the setting does, whether it has any side-effects, valid values for the setting, and whether it's a critical setting that should be changed with caution. It's surprising how easily people forget, especially if it's a rarely used setting.
The cost of determining a default fallback value. How failsafe do you want your code to be? Chances are you'll have some situations — such as bringing up a greenfield installation, restoring from backup, and database unavailability — when you won't have access to the setting. If the setting isn't available for some reason, what kind of default value do you fall back to and how do you proceed? Will this default continue to hold true and be valid as your software matures?
The cost of abstraction and the cognitive load associated with translating it to concrete results. To make some things configurable, it may be necessary to generalize and turn the setting into an abstraction. Take the problem of content management functionality on your custom webapp. You may end up having to manage embedded Flash SWFs, images, simple blocks of text, or any combination of the above. Many content management systems call these "page elements" to encapsulate their full versatility, but this kind of abstraction is another step away from merely "image block" or "text block." What's the URL for the "graphical element" — in other words, the URL for the image? In using a general tool for a specific case, you end up having to refer to things in the most general terms first and translating them into their specific names, rather than calling them just what they are. This costs you time. Time is money, and it adds up.
Now, given these costs, what is one to do? In software engineering and in politics, we resort to compromise. For example, we could hide a setting from users so that only developers or sysadmins can change it. This way, you maintain the configurability that you want and avoid many of the unnecessary costs listed above.
It may also help to know the nature of each setting: are the acceptable values discrete or continuous? If they're discrete, such as officially supported sizes for visual elements, you can impose restrictions on values that you accept so that it's harder for the users of your application to shoot themselves in the foot.
Ultimately, in any discussion of costs, no matter how focused and limited in scope, we must remember to consider the benefits. Neither the costs nor benefits considered alone give us a complete view of any situation, and each must be considered to give context to the other. The difference is that costs are difficult and unpleasant to pinpoint and isolate. They don't receive the attention they're due, but who could blame us? We prefer to look on the bright side and think instead about reaping benefits. We enjoy watching our projects and our companies grow. But it's by being aware of our costs and knowing what hampers us that we free ourselves up to build more of what we want.