Launching a new project, whether from scratch or taking over an existing project, one can not avoid asking themselves a question of what technology stack to use. Tech stack is a multitude of software components used by an engineer for resolving given problems in the course of the project development. Nevertheless, the choice has to be thoroughly thought through since otherwise you can wind up with unsuitable tech stack even if this stack have worked well before. Mistakes like this usually result in difficulties in development and functional restrictions and overloads. Moreover, the ever growing number of available tools improves its functional ability faster and faster. Nowadays, one can get all the necessary data to run a project including its documentation, quick start guides, open source projects data to use as a sample, info from sites like StackOverflow where enthusiasts answer any kind of technical questions.
Talking about a number of technical tools and components necessary for implementing of a project, any other terms of identification won’t fully reflect codependent nature of the components. It includes the frameworks, languages and software products on which everything else is built. You have probably already heard about tech stack in the context of engineering or development called "full stack" able to control the multitude of implemented components. It’s opposed to the more segmented approach with developers only functional code, database-only (DBAs), and operators managing production. In all cases, everyone is responsible for a more or less important part of the technologies used. In the "segmented" configuration, we will undoubtedly see architects responsible for establishing a certain coherence in the implemented technologies.
Launching a new project is always a matter of investment of both time and money in order to find the right solution to the most recent problem. If you have been doing .NET for 10 years, you can take advantage of a project start to get started on a data integration and computing server in Scala, or leave AngularJS to React.
It involves spending time studying technologies, and often making some unsuccessful attempts before understanding how to organize your project. This learning phase can increase eventual cost of development. Whereas if you used an environment in which you know how to start a project, you would be able to manage the different technical challenges and information to solve actual business-related problems. You would also know the limits of the tools, and therefore you would have defined boundaries of the functionality of the application and minimize the risk of engaging in technical issues with no way out.
However, new technologies usually have certain advantages : better potential to respond to different types of problems; adaptation to tools that are more common to the market (current or future); new patterns of development applicable in other technical environments (e.g. functional programming, asynchronous programming).
Investment is vital for growth, relevance, and avoiding aging technologies. Although, we must evaluate the "surface" of the experiments we want to do, not to do too many things at once. You can start with finding a programming language and associated servers before embarking on a new type of database. And hopefully, there will be new projects to experiment with variety of new techniques or to test a different PaaS/IaaS provider.
Another important consideration is understanding of functional problem. For instance, if your task is to solely solve the problem, it’d be better to use already known technologies that would allow you to concentrate on the problem itself and not waste time trying to figure out a new technology.
There are lots of evaluation criteria the stack, which will be more or less important depending on the project. For example, consideration of licenses (what they allow or prohibit, their cost), access to source code, even the publisher / team of maintainers if it’s open-source, etc.
The characteristics of the functional problem are one of the first criteria of choice. It's all about choosing the right tools for the job. Will the app have to support 100,000 simultaneous users? Are there libraries / DSLs to model the problem? Is the app is crucial and must run in 99.99% of the time?
Too heavy or complicated to implement technologies drag down the temp of development longer and more expensive, so those are to avoid.
You probably know that things like running SQL Server on FreeBSD are not going to happen. Therefore it would be better to choose rather steady stack with components known to correctly interact with each other. This is particularly valid for project test runs: you will avoid accumulating layers and layers that are always a little more incoherent and unmaintainable.
The stability of the technologies chosen must correspond the type of project. The bigger the project is and the longer the project, the more you will favor a stable pedestal, not too buggy, which does not change every 6 months. Another important aspect is the existence of a "community" of users who, by using it, will test it, push it to its limits, and thus give more confidence in its stability. And, as a bonus, it’s always a good idea to look up the questions / answers abound on StackOverflow. I would rather bet on Java with its over 900,000 questions then on WinDev with 20-something questions.
To be able to deliver versions as often as possible, to update without spending 3 hours each time, I find it essential to automate the deployment of my apps. The ideal is to do everything in one click, unfortunately it is sometimes impossible. So it would be better to estimate how much a deployment costs based on your hourly rate.
We must not forget the human dimension of the project: we are almost always brought to work with strengths and weaknesses of others. And technology can be a great way to achieve great things. Or to destroy a quality work in less time than it takes to make a cup of coffee.
Suitable tool can the project, bring together its parts and guide developers into a common direction, without having two full-time people to integrate the work of three other people. Tools or techniques that facilitate the communication or description of interfaces used by developers need to be thoroughly explored.