How to decide on programming language for a project

Before starting work on any project, whether it be a small domestic application or a high-profile Enterprise solution, the people who initiate the development start have the question: In what language will we write?. It may seem rather easy to answer, but not everyone knows that the first question should be What will we write?.

This question is not idle, as the answer to it should be much more specifics than it might seem at first glance. It is often the case that the decision about how to start development, at the level of a medium-sized company, is taken by people who are far from this exact development. Of course, most often there is a technical director who takes on the whole burden of determining a particular development course, but what if there is no such person? An outside auditor in the person of an experienced developer will not read the tea leaves to understand what you want to receive in the end. You will receive either a denial of assistance or incomplete answer, and it wont be wrong of them: as the question, so the answer.

In this article, we will discuss the focal points of choosing development technologies and the mistakes that leaders and managers make, as well as why a changeable fashion should not be followed.

Lets suppose you already have a clear picture of a project and its technical specification. Now, in order not to slip up while choosing the development technologies, you should have at least a basic idea of the difference between programming languages. There are a lot of answers to this question, but now we are talking about fundamental differences and areas of application. Only if you understand these differences, you can ask a crucial question: What are the pros and cons of the X programming language? and get a clear answer to it that can be applied to the requirements of your project.

We will not use professional terms and divide languages into high-level, low-level, object-oriented, and so on. In our case, we need a short list of five items, each of which is simply and transparently related to any technical specification:

1. Platform (application area of a language)
2. Language flexibility
3. Development time and life of the project.
4. Performance
5. Language community

Answers to these five questions can be given by any qualified specialist. In addition, they are simple enough to understand, transparent, and, what is more important, clearly show whether we can use a given language for the development or not.

Different languages different areas

The best way to define a programming language and a primary vector for development is to use the experience of the community. At the same time, it is not necessary to be a developer in order to make the right decision just look at which programming languages are popular in the required field and get through their characteristics in accordance with the list attached above.

Each of the programming languages has advantages and disadvantages.

Lets take Python as an example. This programming language is like a Swiss knife with another small Swiss knife inside in theory, anything can be written in it if you do not have requirements for memory consumption and speed of the final product, of course. Besides, Python has a very low learning curve, so finding Python developers (and even training your own during the project development) will not be a problem, and a huge number of open libraries significantly simplifies the life of programmers. However, as soon as you need the application to be not only simple but also fast in terms of operation, with severe restrictions on the consumption of system resources, youd better forget about Python. Same if you need a multithreaded application: the implementation of the Python language does not support multithreading.

Lets go back to our list of factors and consider Python through it:

1. Application area: almost everything and everywhere
2. Flexibility: impressive
3. Development time: fast
4. Performance: available only if you have significant or unlimited computing power.
5. Language community: a vast army of developers of all levels.

As you see, the main problem of Python that was taken as an example is its gluttony. If we make a web application that will revolve somewhere on Google servers, then we can afford the development in this language. But if it is about a mobile or even desktop application, when the target device can be of low power, forget about Python.

And most importantly: such nuances can be found in any programming language. Some of them may not be important to you, while others will be fatal. And in order to understand clearly what will affect the project and what will not, you need to know what exactly you will get after the development, and who will use it.

Lets consider another one language, let it be C++. Its learning curve is higher than this of Python, but it has a number of advantages that Python is deprived of. For instance, C++ allows controlling the resource consumption by our software, which makes it an excellent choice for writing efficient applications that are to work in a limited environment. Thus, C ++ is widely used in the gaming industry, where a team needs to embed a logic that is very solid in complexity and size into a limited space of the final user configuration, which is far from the server in terms of power. Here we can also include mobile applications and games which have to be content with low-power processors and a very modest amount of RAM, which, among other things, will need to be shared with other residents of the device.

On the other hand, you need to understand that C ++ is like a sword consisting entirely of a blade, without a handle. An experienced developer will manage it masterfully, but a weak team will create an application that wont differ much from the project in a more gluttonous Python, but at the same time will be slower to build. Also, C ++ doesnt have managed development environment that exists in more architectural young languages, it means the software development process itself will be long and painful, and the result obtained at the output may not be a joy.

As an outcome, lets go through our list of factors, now in the application to C ++:

1. Application area: apps that require fast speed and work in a limited environment.
2. Flexibility: low
3. Development time: longer than average
4. Performance: this language is about the effective use of every megabyte of memory. It is used to create the most efficient applications in terms of power consumption.
5. Language community: a vast army of developers, but some of them are pests since the learning curve of the language is very high.

The examples mentioned above are a bit exaggerated but very indicative, and most importantly, they dismiss ultimatum statements like the X language is the best or the X language is suitable for anything. As you see, there is no universal language. Each of them has a number of noticeable differences that will either make your project wildly successful or bury it under endless cycles of corrections and improvements.

New-fashioned programming languages and their danger

In addition to the popular programming languages which are on everyones lips, there are also new-fashioned ones in the truest sense of the word. Most often these are some novelties that offer advanced features other languages dont have, or they have some specific syntax. In fact, this is not so important. What is really important is that choosing a new-fashioned programming language instead of the merely popular one is most likely a direct path to abyss.

All new-fashioned programming languages have one thing in common: their communities involve very few truly experienced developers and even fewer manuals, documentation, and expertise.

In fact, this means that the developers have not found or developed the optimal ways to solve various problems using this language yet, and hence, are experimenting. But experiments are acceptable on domestic projects, and when it comes to commercial development, such surprises are not a good idea, because business loves predictability and specifics.

It also happens that you already have an experienced developer of some new-fashioned language, and according to the list of factors, it suits you perfectly, so why not start the development?

The problem is that along with development, the application is often needed to be maintained for a sufficiently long time, and this requires human resources. Fortunately or not, exotic/new-fashioned programming languages are rarely spread out enough for their community to grow to really noticeable dimensions. This means that if you need a second, third, or tenth one developer in your team, then you will try to close the vacancy for months, if ever. Most often, the future of projects in new-fashioned languages is either to be supported by people who have mastered this very language right in the workplace or to be rewritten for something more commonly used and understandable. Both options cost extra time, money, and nerve cells of leaders.

Here is an example. Only 3-4 years ago, hundreds of companies and projects were looking for Ruby developers specifically familiar with the Ruby on Rails framework, instead of PHP or JavaScript developers. Rails were so popular and its developers so highly-paid, that the representatives of this community allowed themselves statements like:

Ruby on Rails and PHP are like Apple Macintosh and PC. We are few, but we are the elite. Ruby on Rails and PHP is a culture against chaos.

It seemed that RoR was a future, but the fashion implicated in technical necessity was over: several new libraries that covered the need for Ruby on Rails functionality in development were released for steadily developing JavaScript, and the popularity of the Ruby language and its framework began to fade. Yes, Ruby on Rails is still used on many projects, experienced RoR developers are in demand in the market, but the number of vacancies is fewer than several years ago. This happened, first of all, because the programming languages competing with Ruby on Rails also did not stand still, and due to the updates, the creation of new frameworks and libraries, an urgent need for RoR eventually disappeared.

Once in a few years, some language or framework shoots, and a small community is built around it very quickly. For example, Rust or Golang are popular now. And no one knows whether these languages will find a lodgement or will be replaced by more stable and matured old-timers. Generally speaking, getting into development relying on a new-fashioned language or technology is very risky, since in the future there may be severe problems with support, which we will discuss in detail below.

Areas of application, terms, and support

It is crucial to understand which area the project is being developed in because there are no universal programming languages they all live and develop in their own specialized niches. At the same time, languages and technologies are segmented not only by area (web, mobile, desktop, and so on) of the development but also by a sphere of application. For example, the same web development can be conditionally divided into client front-end and server back-end. And for both these parts of one and the same web project, languages and technologies will be different. It means that in order to create a web project, hiring a team of JavaScript or PHP-developers who will make you the front-end part is not enough: you will also need back-end experts. This evident nuance often eludes people who are far from programming, which leads to an expansion of estimates at best, or to waste of time and budget losses at worst.

Another aspect that is often ignored is the life cycle of the project. Often the customer builds solely from the development timeframe from the moment of receiving the technical specification to the delivery of a working project. The peculiarity of the dev-sphere is that after the stage of active development, a less intensive but vitally important period of support begins. And this further support is what a large number of companies stumble on.

The classic scenario is as follows: ignoring the necessity for future support and expert advice, the customer chooses the fastest and cheapest option on the most unsuitable technology. Wrong choice and tight deadlines result in the poor quality of code and work on the principle we will insert a crutch here because we dont have time. In the future, the support of such code, the introduction of new features, and improvements will cost way more. At the same time, the project without at least minimal support is doomed to decline and stagnation in a year or two: the IT sphere is continuously evolving, offering more and more new solutions to old problems that instantly become the standard. It is not necessary to search far for examples just open any site which was launched a decade ago and hasnt been supported and updated since that moment, and see what web development solutions were in use during that period. At least they cause an ironical smile, and more often resentment and dissatisfaction.

This simple and absolutely transparent way of checking described by us is needed in order to avoid situations when you are persuaded to create something in a language that is convenient for the executor or advisor. For example, if somebody persuades you to write a mobile game for Android in Python or convinces you that instead of transparent and understandable JavaScript or PHP, you definitely should introduce a little outdated Ruby on Rails, which is expensive in terms of salaries, or try the currently new-fashioned language.

The opinion of experts and experienced developers still should be listened, as this is their territory, but a simple list of factors area, flexibility, time, performance, community will help either identify an attempt of an unashamed cheat, or prevent a gross error by ignoring the opinion of professionals.

Be careful.

Article You may like
Steps to develop best administration of IT Product (Project Management)

Author: Shantun Parmar