At what stage of a project should the platform be chosen?

When a project is designed (i.e. a need is identified, and you decide to develop a computerized solution for it) one of the first things the customer asks is: on what platform should the software be developed? In what programming language? As we know, there is no single answer, but it is difficult to explain this to anyone who is a layperson. And we are often charged for a definition before the project even begins.

Taking a few "obvious" cases (eg, the team that will be developing is already formed, and all the professionals only dominate a single platform), what is the best time to make that decision? In college, I learned that it is best to do it at the end of the elaboration phase (ie when specification and analysis of requirements is complete), when any design constraints are already identified. But in practice I do not know if this would work - given the tendency to adopt agile methodologies over traditional ones . Still, it seems a mistake to say "Let's program in X" before even knowing the particular features of the application.

If there is no particular reason to choose between one technology and another, should you "hit the hammer" before it even starts? Or is there a more specific point in the project where this decision is most appropriate?

Note: For the question not to be too broad, I am looking for arguments of a technical nature, not market (eg availability of professionals with specific training for hiring, average salary of the same, etc. ).

asked by anonymous 20.02.2014 / 21:56

4 answers


I will ask your permission not to answer the question exactly. I think it's easier to think about the characteristics that influence platform choice:

  • Deploy : How will the software be delivered and consumed? It can be a shelf software, a web application for mobile devices, a web application for computers, an app, a local application ...
  • Environment : very similar to deploy, but in sequence. Are there environment requirements to run the application? Linux or Windows servers, integration with specific tools (Novell network, Exchange server ...). Any licensing issues, maybe?
  • Team : Yes, I think it's the point that you've already mentioned. Are we going to set up a team or do we have the staff? What is their expertise?

Here are two interesting references:

I brought this reflection because, if we think about the questions that I presented here, we will see that they are not always treated in the same stages of the project. So responding exactly to the timing to choose the platform is awesome.

21.02.2014 / 02:14

Each language solves a problem, but in 99% of cases the decision will be restricted to common languages (let's say between .net and Java). In that case, the decision must take into account the company's infrastructure: is it more Windows-centric? Are our banks SQL Server? Or are we more open to the free environment? All this influences.

On the other hand, if you have an agnostic environment, the choice of platform ends up falling on the expertise of the team. If your team has yet to be formed, it's a philosophical decision.

Take care with vanities, too, not that there is anything wrong with that. A. Shiite from .NET can create defects that Java does not have, and vice versa. All this can negatively impact a contractor, however much the "victory" of the argument is achieved at that time.

In short: the choice of the best language is chosen by the best people, which is a subject well .

20.02.2014 / 22:06

From the technical point of view, I think we should classify the different domains of solutions (webapp, desktop, webservice, batch, mobile, ...) for which different languages can be more or less efficient.

With this idea in mind, the choice of the language / platform / framework can be made as soon as you can identify that domain, that is, the "type" of the system being developed.

Hardly a project will diverge much from something that already exists, whose solutions on each platform are also known, so we can often get an answer right away on the first contact.

This is well related to the estimates: the more known that domain is, the more accurate the predictions will be. So, in the case of a project whose domain is little known, it will be a longer search time, until the definition of what will be developed.

In part, I reject the idea that language is a major choice, at least for the most common domains.

Let's take web applications as an example, almost all languages have robust solutions to create them. I do not see objective propositions to say that Java is better than C #, which is better than Python, which is better than Ruby, which is better than PHP and so on. Of course there are exceptions, such as C or ShellScript, which would not be the best answers for dynamic web systems in today's world.

There is a certain N:N relation between the solution domain and the different languages. As long as the domain has been correctly identified, there is no reason to delay the choice of platform.

The biggest problem lies in limiting the team or project leader in knowing what possible solution options for each domain. What happens is the repeated choice of solutions already used in previous projects. Although not always the most appropriate choice, sometimes this can be offset by the productivity gain gained from previous experiences.

In particular, I end up limiting my projects and jobs to certain domains, in this case, web systems. In general, I would reject a project where the solution would be Desktop, as there would be a large overhead to assimilate the particularities of such a project.

20.02.2014 / 22:29

When should the platform be chosen? At first .

Can it change in the middle of the project? Yes , it may be the case that the cost and development time is shorter than continuing with the initial strategy. To make sense of the impact of the strategy, I'll briefly mention the choice of platform.

Listing in order of importance how to choose a platform

  • The platform must theoretically allow the solution to be developed in it . Similar case studies are ideal but not required
  • Platform chosen must necessarily have human resources pre-qualified, even if by additional contracting, or consider in the term the habilitation
  • .
  • The platform should either be focused on your project type, or have libraries that facilitate your project type, and cost should be acceptable
  • The platform should allow the development of minimally functional software before the other options ( varies with context )
  • Platform should have better maintainability than others ( varies with context )
  • It should be taken into account that in the case of more complex projects, more than one platform can be chosen, which can severely reduce costs such as development time. Getting the best from each platform and just developing cross-platform integration is a good option .

    Practical examples

    An e-commerce that needs a blog , which has tight deadlines and few human resources, could hire software as a service that would take care of the e-commerce platform, and the development time would be lower, it could use a certain popular blog software. If you needed a newsletter, you could use some popular service that is affordable for very small volumes (eg, up to 20,000 contacts) and a simple interface to manage for a non-technical person.

    An ecommerce from a huge company could hire a multi-disciplinary team to tailor e-commerce, with very specific interface requirements and search engine optimization. But other features such as data analysis would be prudent not to be developed from scratch but rather to use some Business Intelligence software. The newsletter system could also be just an integration with the purchase of paid license of a certain product much used of the area, however the sending of the emails leave of own servers, for reasons of reduction of costs for mass sending. p>

    Why is it important to start with at least an idea of what platforms will be used?

    The above two examples strategically chose multiple platforms according to the 5 items I passed. Then comes the question: what would happen if the decisions were postponed? Well, the natural tendency is to want to do everything on the initial platform, which tends to generate costs because without the right management, all projects tend to strongly reinvent the wheel. So it's good to predict as soon as possible which platforms will be used, but keep in mind that this should be reconsidered if a previous forecast misses significantly.

    21.02.2014 / 02:55