If you spent several hours some afternoon researching on the web what technology is the best for your next project, you’d probably come to the following conclusions: Linux is the best, or perhaps the Macintosh… Of course everything can be written in PHP or Ruby on Rails. If you’re feeling very stuffy, you might be old fashioned and use Java or .NET, Windows or any flavor of Unix that isn’t Linux. For your database you should just store everything as XML files, but if you feel compelled to have a database use MySQL. But if you’re still a slave to the 1990′s then you might decide to keep using the corporate dinosaur- Oracle or Microsoft SQL Server. In the end, the only constant is that whatever you’ve used in the past is certainly out of fashion and certainly a slow, archaic approach to solving problems.

Nearly all teams work within a relatively closed ecosystem – the technologies and people represent only a minor subset of all technologies available today. Even within these small groups the number of choices at every level are daunting. Even if you’ve selected your OS, language, framework, and database – what architecture model are you going to use? What is your data access and caching strategy? At each turn you’ll want to pick the best option but have a flood of choices to select from. Many people can tell you about how they led a project that used any particular technology and it worked like a champ with no drawbacks. On the surface it makes it possible to defend just about any new technology as the way to get your next project done.

What is very hard to find is a real comparative analysis that highlights in comparable situations the results with different technologies. It’s not a surprise this is so – such analysis is very expensive and time consuming, and few companies would try to solve the same exact problem using competing technologies because it’s not the business they’re in.

Where does this leave you? What technology should you use on the next project? Most likely, you’ll have the best success with an incremental improvement on the technologies you already have in your toolkit. Why?

Infinite Solutions in Infinite Diversity

Most conversations in technology on the web are exclusive - they advocate X over Y or Y over X. The truth is much more that X or Y can both solve the problem but do it in different ways and with different levels of effort for a team starting from scratch. What’s much more useful is to ask why you can’t solve the problem effectively with the tools and technologies that are a natural fit for your environment. Even if a new technology may be the easiest way to solve the specific problem you’re looking at it may not be the best choice when you consider everything that goes into creating the entire software system and maintaining it over time.

When confronted with a strong advocate for a technology shift, keep the conversation focused on the benefits of shifting away from the natural or familiar selections for your organization.

New Methods are Expensive

When you introduce new technologies or tools there is always a short term hit. Most respected research indicates that even technologies and tools that have a substantial improvement in effectiveness are at best neutral on the first project that uses them. The most successful technologies and tools are ones that are evolutions of things your team already knows. The more divergent it is from that, the more time it will take to get over the learning curve, establish best practices, and generally become effective.

Known Problems vs. Unknown Problems

A common challenge when comparing a new technology against existing methods is not recognizing that while you know of all of the problems with your existing technologies, you don’t know of the problems with the new ones. This can lead to a comparison that shows a number of critical problems with the current technology, and none on the new technology. It isn’t that there aren’t problems with the new technology, it’s that you don’t know what they are yet. Whenever you put in a new technology, no matter how promising it is, it is going to have new, unexpected problems.

What’s worse is that your organization most likely has workarounds for every problem you’ve encountered, so they don’t really have the impact of a new problem. Your development team may not know about them, but talk to the operations staff, support staff, and your users before you assume that a technology problem that worries you really is at the top of their list. It may be that the big memory leak in a third-party library that has you wanting to rewrite a subsystem is conquered in production by having a script reset the service every night.

Existing Code and Libraries

It’s very easy to underestimate the value of existing libraries and practices in effectively solving problems. When faced with a new assignment, your developers can draw from a large pool of existing, tested solutions to a range of the more mundane, plumbing aspects of the solution. This includes storing user information, reliably working with data storage, security systems, and other functional requirements that aren’t unique to the problem at hand. These software libraries accrue over time as developers face similar problems even in development shops that don’t place a high emphasis on modularity and reusability – as long as you have source code control and developers that aren’t paid by the line of code, they’ll naturally find ways to adapt and remold things they’ve already done to fit new needs.

When you have a major technology shift, losing the use of this common body of code will require the first project to reinvent it. On the surface this may seem straightforward but it’s usually held up by a desire to understand exactly how to best accomplish the same common tasks in the new environment. For example, you might have written your own security system for your previous environment which you’ll then need to either re-implement or drop in favor of a built-in capability of the new environment you’re targeting. What’s worse is you need to make these critical decisions at the time when you have the least experience with the new environment: Is its built in security system really sufficient for your needs? What about logging?

Your Customers Don’t Care

With the exception of a narrow range of situations (such as developer tools), your customers really don’t care what technology you use to implement your solution. After all, they’re buying your solution not the technology you wrote it in. Even if the IT representative of the evaluation team in a potential customer objects because your entire solution is written in a technology they don’t like, in the end they are often overruled unless they can point to a practical implication that you can’t mitigate. For example, you may get overruled because it’s a Unix shop and they won’t accept a solution that only runs on Windows. Even in the most extreme cases, if you provide enough customer value it will conquer any customer technology objection. If the prospect has no Windows servers, that translates into a finite cost for them to support a unique system in their environment. If your value well exceeds that, then it isn’t the key challenge to crossing the chasm to that prospect.

We often hear developers discussing internals of software development and giving them the weight of user requirements. If it isn’t visible to the customer, it isn’t a requirement. In the end, your customers don’t pay you to have a beautiful object model. They don’t care how hard it is for you to create your product or what hoops you have to run through. For them, it’s a cash for capabilities decision. It may be true that doggedly sticking with an old technology will mean you can deliver fewer features with each release, or you won’t be able to run on the latest operating system but in the eyes of your customers the question is still how compelling the functionality is and whether you can run on the operating systems they use.

Ignore the Pundits

If you’re part of a shop that has a track record of producing results, be proud. Don’t worry about what is all the rage at producing the next social networking site, focus on what is effective for you. For projects that can afford the risk, take the opportunity to incrementally improve your technologies and methods: Try out a new version of the development framework or new capabilities of the latest database version. Just remember, you can always tell the pioneers: They’re the ones lying on the ground with the arrows sticking out of their backs. Unless you’re part of a dedicated research team, most often you’ll get the best results by waiting for the first round of adopters to figure out what did and didn’t pan out with the newest release and then benefit from that experience. There’s no satisfaction in burning six months working out the kinks of version 1.0 just to have everything addressed in version 1.1 published a month later.

What’s Your Experience?

Have a great story about being the pioneer, working a project that was packed to the gills with the latest and greatest, only to fall on its face? Or perhaps you found raging success completly severing your ties with the past? Drop me a line or leave a comment about it.





http://reliable.esymmetrix.com/development/the-best-technology-for-you