Customization: The Software Tar-Baby

Vendors often pitch customization as a feature of their software:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/11/customization-the-software-tar-baby.html

I agree that customization can cause problems later on down the line. I have experience of this with open source CMS packages they are never quite what the customer wanted they either did way to much or not quite enough, so inevitably muggin’s here was the one to fix it. Oh the joy of upgrading a customized package. Now we build and maintain our own CMS we know what it does and how it works, if someone wishes something new we add it to the package. Makes our life easier but then our target isn’t the world.

Do what we do: when a customer wants a new or more customizable feature, we charge the customer and then add it as a permanent feature, being careful that its existence does not break or change current configurations after an upgrade. Good for us, we get paid to add features. Good for customer who uses software, as the feature will exist in all future versions. Good for other customers, they get a free added feature.

Systems that are customizable but hard to upgrade were not built with smart underpinning technology. The CRM product we use is customizable to a point. The reason only to a point, is that it has to maintain a degree of compatibility to allow for upgrades. And when they change the underlying technology they provide tools to convert to the new technology. Sometimes its requires no effort and sometimes it is like converting VB6 to .NET.

But while you are bringing up how software that is customizable has underlying traps when you try to upgrade. When was the last time you were able to take an extremely complex VB6 application and easily upgrade it to .NET? Even custom applications need to be upgraded as the technology becomes obsolete.

Companies by software that is customizable because they have a pain and need a pretty immediate cure. It’s not that buy software will save you money, but it will save you time up front because it’s mostly pre-built. If you determine that you will be heavily customizing a software package, you most likely will toy with the idea of building it from scratch.

I have also experienced projects where customization hindered the ability to upgrade.
In most cases, the upgrades added functionality that appeared to be worth becoming the ‘owner/expert’ in the tool, but rarely have folks appreciated that the owner/developer of the tool is now in-house.
With some wonderful exceptions (like apache and perl), most of my brushes with opensource have resulted in customizations and in-house ownership.
For this reason, opensource has been seen as lowering the cost of acquisition while increasing the cost of ownership.
My brushes with payware, however, has generally appeared lacking in functionality, reduced control, and a clear bias towards consulting-ware.

Which one works best for you?

I work in the Enterprise Management Systems Arena and have a SysAdmin background, not a developer per se…

I hate (hate, hate, hate) customizing software for a customer (I’m on the vendor side of the equation, but as a developer). It’s seen by some as “job security”, but it’s really a nightmare waiting to happen. Customized software packages jump up and bite the vendor (in my experience) as often as they bite the customer.

Take the package that works best for you, and STICK WITH IT. If it needs to be customized, then customize the base package (with an option that can be turned on) and get on with advancing civilization.

Customisable software packages are no fun for the vendor, either. Fred Brooks reckons that it takes three times as long to produce a programming system than a program, and three times as long to produce a programming product than a program, and that these factors multiply: it takes nine times as long to produce a programming systems product than a simple program.

Trying to work out what the extensibility model should be is painful, and ensuring that you don’t then break it with respect to the customers’ extensions is even more painful. The best approach, IMO, is to try to persuade the customer to conform to the way the software does things - obviously trying to improve the software so that it’s a bit more like what the new customer expects while still satisfying other customers, but still trying to ship the same software to all customers. If you really can’t, maybe you don’t want that customer. If you still want that customer, by all means go for an extensibility model but keep the coding of those extensions in-house, and test all extensions that are practical when making a new release.

Esoteric configuration options simply make your software harder to test, because you’ve got more to cover. If you aren’t managing to test all your options and reasonable combinations of options (testing all combinations of options causes combinatorial explosion so is infeasible), consider dropping some options that are rarely modified from their defaults.

The worst way to do it is to have a lot of slightly different versions, one built for each customer, with customisations in core logic. It’s a maintenance nightmare.

When was the last time you were able to take an extremely complex VB6 application and easily upgrade it to .NET? Even custom applications need to be upgraded as the technology becomes obsolete.

The whole point of buying software is to avoid incurring the expense of writing it yourself. However, if you heavily customize purchased software, you can have the worst of both worlds: no control over your destiny (you don’t “own” the app), and no freedom to switch vendors (you’ve invested too much in it).

It’s tough to walk this line.

Packaged apps are rarely “good enough” for business software.

For instance, I’ve evaluated over a dozen issue tracking/project management packages. All of them assume things about your process that aren’t true. They make you click seven times to do an operation that should only take one click – so I end up falling back on index cards.

The latest approach to profitable software development is software product lines: the integration of technology and management to develop the ability to rapidly turn out variations on a theme – in cases where it applies, SPLs really are a “silver bullet” that dramatically improves quality while reducing cost and time to market.

Mass-market software products are the glamorous part of the software industry. When you do make money, you can make a lot of money, since a hit product can keep selling copies without adding developers. The potential for high margins is a danger, however, because you’ll attract big companies like Microsoft as competitors, as well as open source alternatives. (Look at how gcc has wiped out the low-priced compiler market)

Custom solution companies produce more reliable revenues in good times and bad. Profit margins are less, because you need to pay developers for each sale, but that, together with vendor lock-in, keeps competitors away.

If your codebase is designed for customization, you can create a “software factory” that can specialize your products for particular customers. It’s one of those happy cases where everybody wins: customers get a better product cheap, vendors are profitable, and developers spend their time doing creative work rather than putting out fires.

The whole point of buying software is to avoid incurring the expense of writing it yourself.

I disagree, if all you intend is to buy software that you don’t have to customize, then you must change your business processes to match the software. The fact that you change the software to match your business processes means that you are buying software that has the “ability” to be customized.

But unless the software is open source, or your company is large enough to force a software vendor to put their source code in escrow, you run the risk of any application disappearing let alone not being able to upgrade it. Keep in mind, that you don’t own the source code - you own a license to use it.

But you are absolutely correct, the more customized your solution becomes the harder it is to justify the cost of replacing it. But then again, if you actually take the time to be able to know what code your are injecting into the customized application then you would know what needs to be ported to the next release.

A few years ago, I worked for a little Natural Gas trading firm (You might have heard about it. It’s initals started with “E” and ended in “NRON.”) We purchased a pipeline nominations system, with source, and customized the heck out of it.
Eventually, the company ran into a spot of trouble, and had to sell off its wholesale trading arm. This was held up for weeks while they negotiated the transfer of software licenses. The nominations system was a sticking point, because it was based on an obsolete version of the vender’s software, and it was hard to get a new license for it.

Bill Gates talked about this idea in his book “Business at the Speed of Thought” and addressed how many companies spend millions of dollars “tweaking” an ERP system rather than tweaking their business to match it.

In some applications, some people think their approach is the only “correct” approach and go about customizing a software package to do it “their way”. In reality, most systems are designed around generally accepted practices and you ought to first justify what you are doing different before you justify making the customization.

How many companies can’t upgrade their ERP software because they customized it just a little too much? How many different ways are there to manage accounting? Customization is why SOX (Sarbanes-Oxley) and HIPAA are so difficult to implement–you have to rethink/redo all of the customization you made the first time around.

Just like object-oriented development: favor composition over inheritance(customization)

I’ll definitely agree that customization is the bane of my existence when it comes to upgrade processes for any of our purchased applications. Unfortunately it’s a necessary evil when you are in niche markets where packaged application base is small to non-existent. Especially if your product model does not conform to the many widget or service billing based systems. You make the deal with the devil to get you to 80% then fight the rest of the stuff as you can.

It almost feels like most of the packaged application vendors prey on the clients by intentionally leaving holes in functionality for “Business Partners” or “Value Added Resellers” to fill. Once you are in bed with them you end up dealing with both the maintenance costs of the software, but the consulting fees to get your customizations re-customized when the originating company changes it’s base every other time.

Not that I’m bitter or anything

Is it just me, or are the main posts appearing with the wrong date? This one wasn’t here yesterday (November 6th), but it’s dated November 3rd on the main page.

Comments seem to have the right date/time, though.

Yeah, the RSS feeds seem a little off as well.

given that SAP has turned the packaged software (customized just for you) business into a megalith; I doubt that either side of the industry will be rejecting the notion any time soon.

but, also given, that suits decide on software, should we be surprised??

I blame the client CIOs far more than the SAPs of the world who’re just asserting their social Darwinism.

Mike Swaim,

Hmmm… EES and Sitara?

Ken

I used to work for an embedded systems house that did custom SS7 protocol work for phone networks. It was a great market for customization because there was almost no international standardization. Every country spoke the protocol a little bit differently, so they’d need a box like ours to talk to the rest of the world.

If only they knew just how poor our ability to manage all of those custom builds was…

My business does lots of “just like the last one, except…”

Managing them is hard – you need very high source control discipline and understanding what “form, fit, function” means, else you’ll fork your code base, and then proceed to screw yourself as you diverge your product lines.

At one point in my career I was responsible for the our call center support software. The entire software package was based on customization. By the time we were “done” with customizing it, we had made it so that there was no way that we could upgrade to a newer version without a team of developers to completely rebuild all of the customizations.