From the 1970’s until 2014, Burger King’s slogan was Have It Your Way. “Hold the pickles, hold the lettuce, special orders don’t upset us” were some of the words to the company’s 1970’s jingle. The idea behind the promotion was that we could order our food the way we wanted it, regardless of the “way it normally came”. As I kid, I was an “extra mustard, extra pickles” guy. This was no problem for Burger King. I don’t remember if other establishments were as accommodating or not, but Burger King certainly capitalized on the perception of their competitors’ inflexibility.

Fast forward to today. We, at least in the US, have the expectation that restaurants (and often other businesses) will cater to our every requirement: dressing on the side, no tomatoes, gluten-free. Our expectations arise from everything from preferences to health concerns. We’ve come to expect the same from our software.

Now, don’t get me wrong (I sure do say that a lot, don’t I?), I generally believe that the software we use for a given purpose must be appropriate for that purpose. We should use tools that fit us; we should not have to contort ourselves to fit our tools, broken processes notwithstanding.

My belief aside, we must be cognizant of the fact that finding or making tools that fit our processes comes with a cost. Customization of tools and software must be undertaken carefully and deliberately; we must understand the cost of customization creation and maintenance versus the cost as well as the impact of changing our processes, expectations, and possibly our culture. Here are two situations that help illustrate these points.

I worked in an organization in which we were moving to a new backlog and test management tool. Our senior leaders were adamant that the workflow of the tool would not be customized and that no custom fields would be added. Though this appears to contradict my “use tools that fit us” recommendation, the context paints a different picture:

  • The tool allowed for two flavors of customization; I’ll call them easy-to-upgrade and not-easy-to-upgrade.
  • Our existing process had many steps to it; some were of questionable value and some were used inconsistently. Using this tool’s default workflow forced us to reevaluate our process’ steps; we realized we could use the tool’s default flow, simplify our process, and lose no business-impacting value. This meant we did not have to customize the tool’s workflow.
  • Two of our senior leaders had been through upgrades of this tool at other companies. What they’d learned was that custom workflows and custom fields fell into the not-easy-to-upgrade flavor; in fact, in one case, these kinds of modifications prevented an upgrade from happening at a previous company. We avoided those customizations as much as possible.
  • When we completed our move to the new tool, we had exactly one not-easy-to-upgrade change, because it not making that change would have impacted our ability to do our jobs in a negative way.

In another organization, the team modified an open source software package to behave more appropriately for that team’s members. Making the tool behave to their specification was a good business decision because it allowed them to be more effective with the tool. The challenge came when they needed an upgraded version of the tool. Unfortunately, their changes were rather invasive, spread across multiple sections of the code. When it came time for them to take a new release of the software package, there was an appreciable amount of work to be done.

A solution that was more appropriate for the long term was to create a set of objects to encapsulate their required changes and hook those objects into the software package’s framework; this was my recommendation to that team. It needs to be said, however, that the software package’s documentation didn’t address its capability of providing this level of configurability, so the team should not be looked down upon for their original implementation decision. They had a business problem to solve and they solved it to the best of their ability using the information they had available at that time. Once the encapsulation implementation was complete, the team got almost all of their desired capabilities, all of the business-impacting capabilities, and an easy upgrade path for future releases.

As per my usual, I’m won’t suggest that no one should ever customize anything and that we should be subservient to our tools’ defaults, but we must be deliberate in our decision making to understand not only what a customization will cost and allow now, but what future costs those customizations will have.

Like this? Catch me at an upcoming event!