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.

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.

In the future of software development, customization is not a problem but the solution.

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.

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.

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.

While I hate the idea of being prevented from 'customizing' a tool, I _do_ believe that company staff and processes are moldable to a canned solution (provided the proper functionality), while management thinks "the new system has to operate exactly like the existing system".

Compare the Apple Newton, which you had to 'train' to recognize your writing...
vs the PalmPilot, where the YOU were trained.

I'll never write the letter E the same again!

I see nothing wrong with customizing off the shelf software -- as long as (flag==0).

PS -- I own you.

Customizations are a necessary evil. Software and websites in general are NOT one size fits all. In order to suit the needs of a particular industry, you must pay attention to the details of that particular industry. Furthermore, enhancements can increase both customer and employee satisfaction through either ease of use or extra functionality.

I think it all comes down to the planning and implementation of customizations. Yes, they can prevent you from upgrading to a newer version of the software, but that's why you have programmers. If it weren't for customizations, we would be out of a job. After all, most ideas are not new, they are merely customizations of existing ideas. One might argue that everything is a customization.

Our company's software is highly configurable - that is, you can specify custom fees, fields, report you want to view, etc, etc. I always have to custom-design one or two reports for a new customer. For configuring the system, it may take a few days on an installation.
Customizing it, is another issue. Executives are all to eager to offer "customization" which ends of costing literally man-weeks and creates fun "production testing" situations - after all- we don't know what this customized system is really going to do until it's in production with all the quirks and user stupidity taking effect.
I'm still working on changes to a system installed months ago - every week they change their mind on what it should REALLY look like....
There's a difference between rewriting whole blocks of code and functionality and having a flexible system that can be configured for different clients.

With all due respect, the term tar-baby, while certainly not meant in any racist sense here, is found by a great many with a background in African American history to be have such a racially charged etymology that it should generally be avoided...

I'm in a bind right now where I need a web application that will integrate tightly with our current site. The packaged solutions just aren't cutting it, so it looks like we'll be using an opensource package and then "owning" the app from that point forward.

I'm finding I agree with the "customizations are a necessary evil" stated above.

> have such a racially charged etymology that it should generally be avoided

Normally I'd agree, but it's a really useful metaphor that existed before it was co-opted for other uses. It's particularly apt here-- particularly with the connotation of intentional entrapment. The software vendors could be Brer Fox.

http://www.randomhouse.com/wotd/index.pperl?date=19990212

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.

> 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.

> 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.

I found the use of Tar Baby absolutely chilling.
Perhaps you should add that link that explains the origin of the term as a prelude to the text (which btw, is reaallly stretching the metaphore here)

lawdy, programmin' sho is hard!

This articles intent is spot on. Customizing software is a trap. But the message is watered down.

I would follow it to the logical conclusion. Programming anything is customizing. You are a programmer. Unless you are updating a software project with a minor change you should always feel free to start from scratch or rewrite.

There is no secret sauce that some software developer has created that you can't recreate with a little programming. Furthermore, if you are asking a business to change the way they work to fit the software you are making a mistake.

The customer is always right. Software development is like magic. You can make that app do anything the customer wants. As long as you stay away from the though that you can save time by customizing someone else's software.

Anybody who says you can't do that to a change request is not being honest. The only thing keeping you from customizing a program you have created to meet a clients expectation should be common sense (when dealing with contrary requests) not the limitations of someone else's software.

i.e. Pink borders, floating popup clock, date picker with iCal support, email merge, remote access, format conversion, database backend change, or file format agnostic.

Say yes of course you can reverse the text direction on the screen and when printing. You are a programmer. You can do it. The only expectation you should be managing is your clients expectation on delivery times and cost. Every change requires time and money. And all those fancy buzzwords can be added in at additional cost after the base feature set is working. It is your responsibility to make that clear.

Just remember open source is there for your perusal. Use it as a reference for your own implementations. Anyone who thinks programming isn't a lot of work is in the wrong line of business. There are no shortcuts.

Is this because I'm black :(

!

Offended by tar-baby? Well I think we need to stop using the word cracker too. I don't care if it is a common word that describes a thin, crisp biscuit, I find it offensive.

Honestly, can we come out of the 20th century now? Maybe we should ban the book of African-American folklore? Would that make you whiners happy? Oh, maybe we could burn them all, all the books that you don't agree with. That would be even better.

Customization can exist in one of several different flavors, and I think its a reasonable request to clearly articulate what exactly is meant here by customization. If I use Java or C# in order to create a program from scratch, I am still "customizing" template resources and utilizing components (including 3rd party libraries and widgets). On the other hand, customizing also covers the use case where I create a short utility macro in VBA for MSWord. Clearly the two are very different scopes.

When evaluating applications for use in my company, I always look at the degree to which it is extensible, and the costs associated with that in terms not only of upgrade revisitation but also software development skills necessary to extend the application, because the assumption I make is that the application WILL need customization to a certain degree.

I shy away from solutions which require changing the underlying application (i.e., require recompilation) and prefer solutions that have a clean "plugin" architecture. In an upgrade path, you may have a period of time where the plugins are not up-to-date with the application, but usually plugins will either be replaced within a few weeks of an application, or new functionality will be offered that subsumes the old.

But what about the ned to customize for performance gains, at least where i work we are taking software and stripping out "features" for the sake of performance quite a bit, we usually need a vendor app to go about 2-3 times faster or scale to about 2-3 more clients than they built it for, and most of the time more hardware doesn't make it faster. i say customization using the vendor provided SDK is required, you just have to be smart and try to use the built in functions as much as posible.

>Maybe we should ban the book of African-American folklore

fyi: Some of us are not american and do not know anything about african-american folklore.

> yi: Some of us are not american and do not know anything about african-american folklore.

Or give a crap about Americans protecting each other from potential discrimination.