Different Is Better

DifferentIsBetter is an AntiPattern.

Sometimes, when you are in a project to replace an older system, you may start realizing that the new system is not really such an improvement... and then you might go with you project manager and ask "why are we building this?", he may reply in many different ways... but a lot of times they simply mean "Because DifferentIsBetter".

Why we should not take a look at the current system to see what we can learn from it? Because DifferentIsBetter
Why we should not ask the user what do they love about the current system so that we can replicate it for the new one? Because DifferentIsBetter
Why should we rearrange all the new UI to do all tasks in a way that is completely different from the way they were done in the current system? Because DifferentIsBetter
Why should we replace that old Clipper system with a DotNet one? Because DifferentIsBetter
Why should we replace that DbTwo database with an Oracle one? Because DifferentIsBetter
Why should we replace that PHP Content Management System with a Java one? Because DifferentIsBetter

Of course, there might be good reasons to replace a system with an almost identical one in a different more modern or more mainstream technology (for example cheaper maintainability, easier extensibility, etc) But if you manager doesn't know a better answer than DifferentIsBetter, then you better realize you are in big problems, because almost certainly the customer is expecting something substantially better than "just the same thing over a different platform" or even worse "a different thing over a different platform but without any real advantage".

Therefore DifferentIsNotAlwaysBetter?, always try to specify WhyItIsBetter? and remember "because it is different" is not a good answer.

DifferentIsBetter in a different (better?) context.

The above bullets imply a context of replacing one system with another (as in a maintenance task). However, consider for a moment someone that isn't just 'replacing' an old system with a new one, but is, rather, attempting to design and build a competitive product where already exist mature, viable alternatives. E.g. designing a new operating system that is to be competitive with Windows and Unix, or a new video-game, or a new book, or a new programming language. In this case, DifferentIsBetter actually applies. Consider the two paths you could take: (a) you make something that is most remarkable for its similarity to existing products, or even just a clone of existing products. (b) you create something that is most remarkable for its differences from existing products.

With (a), you are banking on slightly better execution (with advantage of 20/20 hindsight), but you've got to deal with several problems: (1) competing products that evolve will just incrementally improve to match whatever innovative gains you added. (2) competitive platform products (like OS's and programming languages) will already possess a great deal of value-added in the form of libraries; if you wish to use these, you'll need to match the competitor even more closely (and therefore be less nimble and able to create real value-added with your product). (3) competitive entertainment products (like books and movies and video-games) are a safe bet if you can improve execution (since these are 'consumed'; even if your competitors are good, there's enough space for you and your competitors). However, your entertainment-product won't be remembered... unless there is something remarkably different about it, it will eventually just join the pile of other clones.

With (b), you have considerably greater probability of a partial or total failure. You're a pioneer, pushing the boundaries of the common experience. However, you also have a real chance to create a product that truly new and inspired... to create a platform that will attract new interest, to create an evolving product that existing competitors cannot match because of their momentum (from existing users, existing code-base), to create an entertainment product that will truly seem 'new' to the audience (and stick with them for a long time or get retold through the decades and centuries).

If you're going to embrace the gamble that comes from being 'different', you should seriously reconsider doing something just because it seems to work in existing systems. Perhaps there is something vastly different that would work better... or at least work. Look for it, and give it a taste. And do so while your product is still small and nimble, not after it is loaded down by need to support a truckload of libraries and millions of users. The world doesn't need another Unix clone. The world doesn't need another OperatingSystem trying to be Windows or another computer language trying to be Ruby or Python or Java. In many of these cases, DifferentIsBetter is simply a good mindset to start in. Make it the same only if it's the only reasonable choice after you've exhausted all thoughts of other possibilities.

Some times DifferentIsBetter is a bad way to hide the fact that we dont know how to use X technolgy, and therefore, regardless of the fact that it might be a better tool for the job, we recomend to replaced it for Y technology, because we know how to use that. What could be the name for this other antipattern... maybe NotKnownHere? ?

There are two kinds of fool. One says, "This is old, and therefore good." And one says, "This is new, and therefore better." -- John Brunner, "The Shockwave Rider"

Beware when any idea is promoted primarily because it is "bold, exciting, innovative, and new." There are many ideas that are "bold, exciting, innovative and new," but also foolish. -- Donald Rumsfeld

See BitRot, LinkRot, OldCodeRusts, CarsBreakSittingInTheGarage, NotInventedThisWeek, NewTechnologyWillSaveUsAll.

Category: CategoryRequirements