Facing the Challenge of Customizability

May 27, 2018

Good Morning,

few Programs can exist without customizing: a design matching the corporate identity, additional reporting functionalities, special workflows, you name it. And in every software, customizability is a challenge.

In software development, we differentiate between a product and a project. The distinction goes as follows:1

  • A product is developed for the market. The software company invests money into the development of a product with the goal to sell it to a large number of customers. Investing in this sense means advancing money, which may or may not reap returns when the product is finished. A product therefore offers good rewards (write once, sell many times), but also carries a sizable risk (the market doesn't care).
  • A project is developed for a single client according to their needs. Typically the development firm will still need to advance the money required for the project. The risk however is much lower, because there is a customer who will pay the full development cost of the software. The returns on the other hand are lower, too, because the project software cannot be sold to other customers.

Many software companies have found their happy place doing both: They provide standard products for the market and projects to tailor their standard products to specific customer requirements. This tailoring is typically called customizing - and it is one of the biggest challenges to be faced in designing a product.

In my years as software developer, I have encountered various products which have been heavily customized, and most of them had at least one of the following problems:

  • Everything is private
    This can be one of the most frustrating things to encounter as developer tasked with customizing a product. The product defines a few "entry points", which however do not give you the freedom you need. At every turn you have to ask the product development team to give you an additional entry point or to make yet another method publicly available. This can easily make a two day project an odyssey of multiple weeks.
  • Everything is public
    While this is the exact opposite of the previous bullet point, it is exactly as bad for the company. If a method is public, someone will use it (and forget that they did). A public interface can never be changed without worry that some customizing will break. And if the customizing was important, what seemed to be a small change in the product can quickly become a political nightmare. This leads to a major deadlock: if everything is public, nothing can be changed. Product development grinds to a hold.
  • The product architecture is a mess
    A messy architecture is bad enough in product development alone. At some point, changes to a bad code base become ever harder, the risk of breaking existing functionality becomes ever greater. How is one supposed to implement complex customer specific features into such a code base without breaking everything? And how to not make the customizing even messier than the already bad code base? Even worse, customers sometimes request a customizing added on top of an existing customizing. That's like a bad meal with awe-full sauce and an even worse spicing.
  • An extraordinary sales department
    Some salesmen can sell just about anything - and they do it, too.2 Even though the developers hair stands on end because he can barely make the requirements work. This will often lead to ugly workarounds with strange side-effects.
  • Putting the "product"-badge on customizings
    Depending on the agreements with the client, a software company may be allowed to include customizings as part of their product. This is great if the customizing is taken as a feature that gets thoughtfully embedded into the product. If customizings just get "slapped" into the existing code one after the other, however, the product more than likely becomes a mess after a while. The reason is simple: A customizing does not usually have to take all the products features into account. It is very clear which features the customer needs and uses. To keep costs for the customizing down, only the necessary changes are made. Why would you make the customizing work with feature x if the customer does not intend to ever use said feature? Putting this customizing into the products code base however leads to a problem: A different customer may very well use feature x, which is now incompatible.

Many of these challenges can only be met with some strong self-control and good foresight. There are, however, various ways to takle these issues:

  • During development of a new product, it must be clear whether the software should be customizable or not. If in doubt, go with yes.3
  • Any software should have a clear architecture. This is especially true if others should customize the software. I personally believe that the exact architecture is not as important as the consistency of said architecture. Once a new team member (in product or project development) has a grasp of one part of the application, they should be able to apply that knowledge to all other areas of the software.

  • Consider the implementation of a plugin system. Plugins are a powerful way to allow for customizability. In the extreme case that all product functionality is bundled in multiple layers of plugins, everything can be changed for the customer (the architecture does become harder to understand, though).
  • Use automated (regression) testing. Not only does automatic testing help in the development of the product or the specific customizing. The real power becomes apparent when automatic regression testing can be applied to the product and all customizings at once. Whenever product development has (again) broken the interface, automatic tests of customizings catch the error before it gets rolled out to the customer. This makes both the product developer as well as the project developer sleep easier at night, because they can be pretty sure their stuff still works the next day.
  • During customizing, think about product features which will not be compatible with the customizing - and document this fact4. If someone later moves the customizing into the product, incompatible features have a greater chance to become apparent.
  • Do not make everything public/private. Every part of the application has to be examined in regards to the necessity of it being customizable. Everything that needs to be customized must have a clear public interface (an API if you will). This interface must be created in such a way, that it a) provides all required functionality, b) can be extended whenever we forgot something in a).5 If product development is in doubt which parts of the interface have to be public, wait for the first customizings to come around. In my experience it is better to make too many things private than to make too many things public. There has to be an easy ways for project developers to get their public interfaces done when they need them, however. This leads me to the next and most important point:
  • Talk to your colleagues (coffee makers are a great place for that). In my experience there is oftentimes a barrier6 between product and project development. Especially if the two are separate departments. However, only the customizing department knows what they really need.

In my opinion, the challenge of customizability is a big one. Customizing is one of the biggest sources of income for many software companies, but there is no one right way to make it work. Still, I hope I have offered you some food for thought to enhance the work of your product development and project development alike.

  1. This is a simplified distinction, of course. As per usual, reality provides many gradients in between products and projects. The software company could, for example, sell a customizing at a discount but in turn get the clients allowance to sell it to other customers as well.
  2. Don't take this one too seriously. As is usually the case, neither is the salesmen at fault, nor the development team. There are customizings, however, which better had not been done. And some better communication between departments could works wonders to prevent such cases.
  3. Allowed answers are: yes and maybe.
  4. This documentation could even be a test in the form of: If feature x is active, break the test with an appropriate message.
  5. In my mind, this is one of the hardest nuts to crack. One good way to tackle this problem is the combination of a plugin system and dependency injection. Plugins get their dependencies injected, which in turn have a public interface that can easily be extended. This topic can fill books, however, and can not be fully discussed here.
  6. The size of this barrier ranges from garden fence to Great Chinese Wall. Only open communication can lead to good software, especially in the early stages of a products market adoption.