BlogArticles over here were reposted from different websites with content improvements or any adjustment to the content originator website for better understanding. Please look for the actual author website about content creation.

  Which Technology best suits to a requirement?

Whether you’re modernizing an existing system or starting a new system from scratch, the task of choosing technologies can be a daunting one.  Do you go with the old stand-by, or is it time to spread your wings with something new?  Do you try for something flashy (but risky), or do you go with a proven approach?

The most familiar technology often becomes the hammer for every nail.  Before you head down that path, take the time to make sure it really makes sense.  There are many questions that need to be answered.  In this post I’d like to focus on two questions:

Is it here to stay?

Ensuring that your technology will be stable and relevant for years to come will help you avoid that costly rewrite a few years down the road.  I’d recommend two assessments to determine its staying power.

How long does your application need to be in the field?  Hopefully for a long time, right?  Will the product be around to help your application meet its timeline?

  • Choosing mature technologies is always a good decision, but sometimes “mature” can mean “becoming irrelevant”.  Going with a tool that’s near the end of its lifecycle may mean a costly rewrite sooner than you might hope.  It’s a good idea choose to technologies that will be around for the foreseeable future (5+ years).
  • Similarly, if a product has been de-emphasized by the vendor, you may miss out on new features even though the product is still supported (Windows Forms and LINQ to SQL come to mind).  It’s always a good idea to understand the vendor’s view of the technology before using it.

User Base 
Adopting a brand new technology is tempting, and sometimes it’s the right decision.  However, if you’re doing anything more than sandboxing, you’ll want to be sure that the tool has a strong, active user base.  Here are a few ways to figure that out:

  • Forums — How many participants are there?  How quickly are issues resolved?
  • Releases — When was the last release?  When’s the next release?  What’s scheduled to go in it?  Easily finding answers to these questions is a good sign.
  • Published partners — Do any reputable companies rely on it?
  • Conferences and User Groups — Are there sizable user groups and conferences?  This is always a good sign.  Visiting these events will help you learn the lay of the land.

Is it a good fit for this project?

It’s easy to choose the latest technology, or the one you’re most familiar with.  However, you may be setting yourself up for heartburn later if you don’t consider whether the technology really fits the needs of this project.  Assessing external dependencies and your development team’s ability to perform well with your technology are two good places to start.

External Dependencies 
Are there special software tools your application will need to depend on? Answering the following questions can help you save your clients headaches down the road:

  • Operating system — Will your software run on a single operating system, or will it need to run cross-platform?
  • Browser flexibility — for a web app, will you support any browser, or is your user’s browser decision made for them?  This is common in many highly-regulated industries.  You may want to tailor your solution to your browser’s strengths — for example, if you’re going to rely heavily on Javascript, ensure that your user is running a browser that will be performant.
  • Hardware communication — As in many manufacturing and healthcare applications, many software tools need to control hardware viaUSBBluetooth, serial or some other communication.  You’ll want to ensure that your technology has privileges to access these channels.  In many cases this means that web technologies won’t fit the bill.

Development Expertise
Choosing a technology that meets requirements but is new to the development team can be a risky move.  It’s important to have experts on the development team, or at least easily accessible by the team.

  • A lengthy learning curve will extend the development cycle and can lead to poorly written software.
  • Remember that not all subject matter experts have to be in-house — a contractor or consulting firm (yes, a shameless plug!) can provide the leadership to bring a development team up to speed and ensure that good practices are followed.

Remember — Tradeoffs!

You will rarely, if ever find a set of technologies that completely fits your needs.  Be ready to make tradeoffs — a concession here, in favor of a significant advantage there.  Making the best technology tradeoffs can put your application on the right path for a long time.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.