Business

Technology choices and Project Consequences

This article is aimed at those we have custom software built for them or intend to and look to understand the technology choices.

Developers get to experience hundreds of technologies. Technologies come and go, get popular, fall back to oblivion or hang around without merit. A developer must not only learn technologies to stay current, they must pick the ‘right ones’. The ‘right ones’ are not always the best or the most popular or even that mainstream. What are the influences and how should you deal with technology in a development?

In my experience there are a few forces at work.

  • First of all there are the technologies that magnetically pull new developers
  • Technology that pulls the more mature developer
  • Those that attract because of cool, funky, trendy and cutting edge
  • Those that are pushed from large corporations
  • Those that are magnetic because of open source attachment

Notice that I have mentioned a number of influences and none of them are because they are inherently brilliant technologies.

As a business, your solutions provider may opt for technologies that make sense to your business or they may not.
When you get a quote for software each solutions provider will push their technology. It makes sense. They should push their technology, as it will provide stability and robustness as long as the technology they push is a) congenial with the functionality and b) does not serve as a hindrance in any way.

The motivation for their recommendations though is what you should look for.
You don’t want them to use your project as a testing ground for a new technology. If they use your project, you could get their teething problems and your project will most likely overrun on time and budget.

Ask the right questions of your solutions provider.

  • Have you utilized this technology in a production environment?
  • Has the development company used the complete architecture (combination of technology) in a production environment?
  • How stable is the technology?
  • What is the usage of the technologies across other developers? You don’t want anything obscure, so that you cant find a replacement developer if you need to.

What red flags to watch out for

  • A technology that is younger than 2 or 3 years
  • When the technology does not have a roadmap
  • When it’s not being used by the company who created it
  • When the documentation is sparse
  • Lack of forum information, StackOverflow questions and little other resources (YouTube etc)
  • When the technology is dependent on a technology with these red flags
  • A technology that you do not use everyday or platform you are not familiar with
  • This technology is cheaper than the other, that’s why we recommend it
  • This is opensource, thats why we recommend it

None of these red flags are inherently terrible, but they are flags that need questioning. These are also, by no means the only red flags, consult an expert to look at your specific requirements and determine whether the proposed technologies are a good fit for your business.

Final thoughts

On the balance the architecture, design, platforms and technologies should be a balance of:

  • robustness
  • stability and longevity (roadmap)
  • compatibility with your developers
  • compatibility with your business
  • efficient for your developers
  • efficient for your business