{"id":492,"date":"2015-04-27T15:20:19","date_gmt":"2015-04-27T15:20:19","guid":{"rendered":"https:\/\/solutionstreet.com\/blog\/?p=492"},"modified":"2015-04-27T15:20:19","modified_gmt":"2015-04-27T15:20:19","slug":"what-technology-stack-do-you-recommend","status":"publish","type":"post","link":"https:\/\/www.solutionstreet.com\/blog\/2015\/04\/27\/what-technology-stack-do-you-recommend\/","title":{"rendered":"What Technology Stack Do You Recommend?"},"content":{"rendered":"

What Technology Stack Do You Recommend?<\/h2>\n

\"\"<\/p>\n

<\/div>\n
<\/div>\n
By: Arthur Frankel\u00a0<\/strong><\/div>\n

 <\/p>\n

Often we are asked, \u201cWhat technology stack do you recommend?\u201d, \u201cWhat language do you prefer?\u201d, \u201cWhat architecture, frameworks, and components do you suggest?\u201d. Just today I was talking with a former colleague who works with educational training systems and she wanted to know the answer to these questions. We were talking about the challenges of her organization and given the new products they had acquired from other companies and their diverse set of technology stacks, one of the most important goals for the organization was to determine the right stack for these products and whether or not to rewrite the code in a single stack or try to get them to talk with each other. Although there\u2019s a great discussion to be had on whether or not to rewrite code (classic article from Joel on Software on why you should never do so<\/a>), I\u2019d like to talk about how we recommend technology stacks.<\/div>\n

 <\/p>\n

In our experience at Solution Street with building custom software, clients may prefer a technology stack for one or more of the following reasons:<\/b><\/div>\n

 <\/p>\n

\n

1. Existing stack<\/b><\/h3>\n

Many companies are Microsoft shops or Java shops and their strong desire is to stick with their current stack because of experience. Given the state of technology, sometimes even with this constraint the door remains partially open. For example, a Java shop is really used to Java and the JVM. Languages such as Groovy or JRuby and frameworks such as Grails lend itself to those companies given their experience and may provide a quicker more efficient way to develop without giving up much of what the organization is used to.<\/p>\n<\/div>\n

 <\/p>\n

\n

2. Developers on staff<\/b><\/h3>\n

Often companies have been hiring people with certain technical proficiencies towards a given software language and architecture. They are concerned about teaching their staff new technologies and whether or not this will be more productive over the long haul.<\/p>\n<\/div>\n

 <\/p>\n

\n

3. Existing small proof of concept<\/b><\/h3>\n

Sometimes clients have started experimenting with a technology stack and are unsure of its true capabilities and scale, but do want to go further with it.<\/p>\n<\/div>\n

 <\/p>\n

\n

4. New CTO\/CIO<\/b><\/h3>\n

Choosing a technology stack based on prior experience.<\/p>\n<\/div>\n

 <\/p>\n

\n

5. Reactionary decisions<\/b><\/h3>\n

e.g., One project failed with this stack so it\u2019s blacklisted – whether fairly or unfairly.<\/p>\n<\/div>\n

 <\/p>\n

There probably are several others of these \u201cenvironmental\u201d type factors.<\/b><\/div>\n

 <\/p>\n

\n

Certainly when looking at technology stacks clients often (at least should) be asking these questions:<\/p>\n