At what point in a project should the platform be chosen?

Question

When a project is designed (i.e. a need is identified, and it is decided to develop a computerized solution for it) one of the first things the customer asks: on which 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 those who are laymen on the subject. And we’re often charged for a definition before the project even starts.

Apart from some "obvious" cases (e.g., the team you are going to develop is already formed, and all professionals only master a single platform), what is the best time to make this decision? In college, I learned that the ideal is to do it at the end of drafting phase (i.e. when the specification and review of requirements is completed) when any design restrictions will already be identified. But in practice I don’t know if that would work - in view of tendency to adopt agile methodologies to the detriment of traditional ones. Still, it seems to me a mistake to say "let’s program in X" before even knowing the particular characteristics of the application.

If there is no particular reason to choose between one technology and another, should one "hammer" it before it all begins? Or is there a more specific point in the project where that decision is more appropriate?

Note: For the question not to get too wide, I’m looking for arguments of a technical nature, and not market (e.g.: availability of professionals with specific training for hiring, average salary, etc).

Answer 1

I’m going to ask your permission not to answer the question exactly. I think it’s easier to think about characteristics that influence the choice of platform:

• Deploy: how the software will be delivered and consumed? It can be a shelf software, a mobile web app, a computer web app, an app, a local app...
• Ambience: 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...). Some licensing issue, maybe?
• Team: So yes, I think there’s a point that you’ve already talked about. Are we going to build a team or do we already have the staff? What is their expertise?

Here are two interesting references:

• Gov.UK - Choosing technology
• How to Choose the Most suitable Technologies for your project?

I brought this reflection because, if we think about the issues I have presented here, we will see that they are not always dealt with in the same stages of the project. Therefore, answer exactly the timing for choice of platform is fearful.

Answer 2

Each language solves a problem, but in 99% of cases the decision will be restricted to more common languages (let’s say between .net and Java). In this case, the decision should take into account the company’s infrastructure: is it more Windows-oriented? Are our databases SQL Server? Or are we more focused on 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 team’s expertise. If your team still needs to be formed, it ends up being a philosophical decision.

One should beware of vanities, too, not that there is anything wrong with that. A Shiite of . net can create as argument defects that Java does not have, and vice versa. All this can impact negatively on a contractor, however much the "victory" of the argument is achieved at that moment.

In short: choosing the best language involves choosing the best people, which is a subject well more extensive.

Answer 3

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

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

Hardly a project will diverge much from something that already exists, whose solutions in each platform are also known, so often we can have an answer right at 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 is convenient a longer time of research, until the definition of what will be developed.

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

Let’s take the web applications As an example, almost all languages have robust solutions to create them. I don’t 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 responses to dynamic web systems in today’s world.

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

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

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

Answer 4

When should the platform be chosen? At the beginning.

Can it change in the middle of the project? Yes, can if the development cost and time is less than continuing with the initial strategy. To make the impact of the strategy more logical, I will quote briefly on the choice of the platform.

Listing in order of importance as choose a platform

1. The platform must, theoretically, allow the solution to be developed on it. Similar case studies are ideal but not mandatory
2. Chosen platform must have pre-qualified human resources, even if by additional hiring, or consider within the deadline.
3. The platform should either be focused on its type of project, or have libraries that facilitate its type of project, and cost should be acceptable
4. The plateform should allow the development of minimally functional software before other options (varies with context)
5. The platform should be maintainable better than the 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 of each platform and just developing integration between different platforms is a good option.

---

Practical examples

An electronic trade that needs a blog, that has tight deadlines and few human resources, could hire a software as a service that would take care of the e-commerce platform, but the blog, having more personal resources easier to achieve and development time would be less, could use a certain popular blog software. If you needed a newsletter, you could use a popular service that has affordable prices for volumes not too high (e.g., up to 20,000 contacts) and a simple to administer interface for a non-technical person.

An electronic trade of a huge company, could hire a multi-disciplinary team to make a bespoke e-commerce, with very specific interface and optimization requirements for search engines. However, other features such as data analysis would be prudent not to be developed from scratch, but to use some Business Intelligence software. The newsletter system could also be only an integration with the purchase of a paid license for a certain product widely used in the area, but sending the emails out of own servers, for the sake of reducing costs for bulk sending.

Why then it’s important to already start with at least an idea of which platforms will be used?

The two examples above strategically chose multiple platforms according to the 5 items I went through. So the question arises: what would happen if the decisions were postponed? Well, the natural tendency is to want to do everything on the initial platform, which tends strongly to generate costs because without the right management, all projects tend to strongly want to 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 has missed significantly.

Answer 5

Last responsible moment (last Responsible Moment)

Since there are many possibilities and variables involved, it is better to adopt a principle, a heuristic, rather than a well-defined rule. It is appropriate to consider the Last Responsible Moment https://dzone.com/articles/lean-tools-last-responsible.

There’s a curious statement in the question. It reads, at the end, "if there is no particular reason to choose between one technology and another...". Note that, if in fact it does not exist, then the choice is irrelevant and of course the moment it occurs (when) is also irrelevant, provided it is not after the last responsible moment.