I drive a Toyota. It’s an offshoot brand called Scion, my model is the TC (http://www.scion.com/#tC). It’s an amazing sports car, very reliable and if I need to repair it I won’t have to search too far for compatible parts.

I’d much rather own this than a Ferrari. All financial considerations aside, I’m not interested in shipping my car out or hunting down shops where I can have it maintained.

But let’s say you’re in the market for something fast, tightly tuned and that performs like nothing else. You’ll want to consider something like a Ferrari, or something even more specialized like a McLaren (http://www.mclarenautomotive.com).

While maintenance and repairs for these high end vehicles will not only burn a hole in your pocket but probably take off half your leg, you’re going to experience a ride that makes my Toyota feel like a baby carriage.

So here’s the trade off, you get the power, the cornering, the acceleration and the extreme excitement though you pay for it. However, there’s another trade off that is usually just assumed and somewhat overlooked during the purchase of an automobile…

Interchangeable Parts. How universal are the components in your fancy racing machine? Do they need to be universal? What kind of performance hit would you be taking if you could even use the same brakes, spark plugs or pistons that everyone else is able to utilize?

This “obvious” trade off becomes a major consideration when planning the development of an Internet Application which is expected to serve millions of users efficiently while maintaining a code base that complies with industry standards and allows for easy editing by anyone who just so happens to need to manipulate the source.

Here are some of the primary considerations:
Decoupled classes: Are you stuck with the part you’ve got or can you swap them out to diversify functionality?
Common knowledge: Will new/other developers be able to get into your code and change it when needed or will it be too confusing to navigate it’s structure?
Performance: Could your application benefit from directly executing some functions rather than indirectly through a framework intended to decouple and universalize your code?

How important are these factors?

Here’s where my views become a bit more subjective but with some solid reasons…

Performance is ALWAYS a factor. You’re always going to want a fast and stable application. The other two considerations may not be as important as you believe. There’s a lot of hype in this industry right now, various organization want to promote their approach and software engineers aren’t always as firm with their clients as they maybe should be when it comes to recommending the right solution to a client while alleviating doubts about deviating from tradition.

Now, I will say that there has to be order and organization. Code has to be understandable so that it can be built upon, patched and maintained. But do we need a common framework for that? No. Come on, it’s code, it’s logic, keep it clean and modular, it’s going to have a rhyme and reason to it. Don’t worry about doing or using what everyone else does or uses. If you need something else, use it. If your client is concerned about your radical ways, take the time to explain the benefits to them, be strong about your expertise, they’ll respect you for it.

“Yeah, but what about Decoupling?” You say! What the hell are you doing with the source of this application? Are you going to open source it? Hand it off to the public for reckless adventures in web app opulence? No sir, no you are not, not if you’re building it as one of a corporations intellectual assets. So why the mad suicidal mission to tear things apart and make sure they don’t touch each other? Is this client really going to rip out a framework and replace it with an entirely different core? Or… is it more likely that they’ll completely rebuild the application at that point?

In my experience, and I’m sure, in the experience of many others, once an app is so far from manageable that the core connections between all classes have to be refactored it’s time for a new app. The UI would probably have lost the meaning in it’s visual metaphors, the consumable services the app connects to have probably undergone considerable alteration and the logic, views and data structure in the application would most likely need to be taken under further review at the very least.

That leaves us with decoupling for the sake of diversity in functionality. Well ok then, now we have something. Interfaces and factories are great ways of allowing your application to use “Interchangeable Parts”. Yet still, there’s nothing wrong with marrying your code to a custom interface or factory regardless of whether or not it belongs to a widespread, universal framework.

Secret Weapons. That’s right, an organization’s intellectual property is it’s “Secret Weapon”! Just as you won’t find transmission components for a McLaren at AutoZone you’re not going to find a solution to RIA performance perfection at the local MVC shack. Do things differently, it’s how you separate yourself from the noise in the background and stand out. The element of surprise can fuel accelerated business an give you an unexpected edge on the economic highways.

Make a seat, intake fuel and output speed just like everyone else. What happens under the hood, however, …

Is Your Business.