Several years ago, one of the partners of a company I worked for, commented the following with me:

In USA, people tend to adapt their work-flow to the software they use. In Brazil, we always want to adapt the software to our needs.

He was actually complaining about the way we Brazilians behave regarding software adaptation vs software customization. And I mostly agree with him that we Brazilians really do that while there are several situations where it would be much simpler (meaning less cost) if people could just adapt themselves to the way the software already works. I can’t speak for people in USA though, since I don’t really know them enough! :)

Martin Fowler also wrote great articles on the subject.

In this article, I’ll present my thoughts on what this means for those working on this customizations.

Jason Fried and David Heinemeier Hansson, founders of 37signals, also talked about this subject in their (recommended) book Rework:

Build half a product, not a half-assed product

Some ideas are really great and powerful.

But if things go wrong they can become a disaster!

The authors greatly summarized the problem in the topic “Let your customers outgrow you”:

…There’s a customer that’s paying a company a lot of money. The company tries to please that customer in any way possible… Then one day that big customer winds up leaving and the company is left holding the bag - and the bag is a product that’s ideally suited to someone who’s not there anymore. And now it’s a bad fit for everyone else.

They also give great advices like “Say no by default”.

This is really important because it is so easy to say yes as it is ineffective. A good manager is that one that is able to understand a “no” suggestion from developers and convince their client to accept the “no” too.

There are lots of situations where we just want some change because we don’t want to change ourselves. Think in about how much developers still use a centralized version control system like Subversion or CVS just because they don’t want to learn how distributed VCS like Git and Mercurial work. Think how much they lose by choosing to not change their minds.

The decisions around customization should be well thought. Not all customizations are worth. If you have a product that is shared among some clients, all of them having some different requirements, you shouldn’t agree delivering every requested feature.

As a rule of thumb, I would ask myself some simple questions:

• Is that change something that could be implemented as some sort of a plug-in?
• Is that change really useful, including for the client who is asking for it?
• Will the other clients use that feature?
• Is it easy to isolate it and add some software switch for enabling/disabling that feature?

If any of these questions can be answered affirmatively, then it probably worths implement the feature. Of course, the effort/cost vs goodies should be measured as well.

In the other side, you should probably say “no” to your clients if the change implies in either:

• There will be a substantial change to your system, increasing the risk of failures. This is specially true if the application doesn’t rely on a good test suite or if it is a critical application.
• Adding such a feature means that you’ll need several conditionals among all over the code.
• Accepting the change means that any future change would become much slower to achieve.
• Implementing the change will make it much harder to get some reports from the system and/or will make the report generation or interface navigation time much slower.

I guess there will be a gray shadow between these lines, but the main problem is that most people I worked with in my life simply will never consider saying “no” at all. They say it is just a matter of money vs time needed to accomplish it. But usually they’re not able to really estimate the costs of such a bad decision in the long run.

I wonder if Brazilians will change their mind some day and start to evaluate adapting themselves to some software or process sometimes instead of insisting in customizations. I also wonder if they’ll learn to negotiate better the features instead of just accepting the requirements as they are. I hope so, but I don’t really believe it will happen any time soon…