Customization: The Software Tar-Baby

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)

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!

lawdy, programmin’ sho is hard!

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

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 :frowning:

!

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.

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.

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.

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.

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.

Get a real job. If it ain’t custom, why bother?

These days, software customization to a software solution are nearly always needed. This allows the software to be tailored to your needs, allowing for greater success, either with users or in business processes.

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