In 1954, the high-level general purpose programming language Fortran was created at IBM. In this year, there were a few options to choose from in the software engineering area. Nowadays, we have a lot of options in our hands and each day, this number grows, as do the number of decisions.

The Java platform is an example of the assertion above in which we evaluate the options available for us (non-commercial and commercial options). An underlying choice we have to make involves the IDE. It should be an easy decision; after all, an IDE (in this case) only needs to support one language through some versions, but the reality is that we have some options like Eclipse, IntelliJ IDEA, NetBeans, and Rational Application Developer. The decisions don’t stop here; we have to choose between others options such as:

• Server application (Tomcat, Wildfly, Weblogic, Glassfish).
• Web framework (Spring, Java EE, Play, Grails).
• Persistence libraries (Hibernate, EclipseLink, jOOQ, Spring JDBC).
• Presentation libraries (JSF, JSP, Wicket or some library beyond the Java Platform).
• Package management tools (Maven, Gradle, Ivy).
• Continuous Integration tools (Jenkins/Hudson, Bamboo, TravisCI).

Wait! These decisions are easy. We could choose the following options: Eclipse, Wildfly, Spring, Hibernate, JSP, Maven, and Jenkins. No further decision is required, right? No! This is just one level of decisions. Others levels, for me, are the following:

• The plugins or subprojects of the options above or any other libraries provided by the open-source community or over commercial licenses used to facilitate our work.
• The specific projects developed inside the organizations.
• The upper level involving the options of technologies and languages to be chosen, like Cloud Computing Platforms and Ruby language.

Considering these levels of decision-making, we can have a scenario where we need to choose a library to deal with date and time and have the following options on our hands: JDK java.util.* API, joda-time API, or xtime API developed by the team inside the organization.

Until now, I used the Java Platform as an example. There are other general purpose platforms like Ruby or DOT.NET as well as specific purpose languages like Scala, R, Go, or Perl. To worsen this, we can have two or more platforms involved in our projects and thereby more options from which to choose.

So, how do we deal with this complex universe of options to choose? This doesn’t have a simple answer. Thus, I suggest the following practices for dealing with it:

1. Make the decisions together with your team or even some teams. Thus, the decisions are shared and debated between some professionals with different experiences to thereby reach the better decision.
2. The most popular options (platforms, technologies, tools, or libraries) must be considered the first option in decision-making, whereas the options can be shared with the whole organization or a group of teams, the most popular options are better to promote the alignment of knowledge between the professionals and reduce technical impediments.
3. Test the new options, and when the knowledge is dominated and minimally disseminated, use them. To introduce a new option, evaluate it before use. Moreover, disseminate the results of the evaluation with other professionals to collect opinions and thereby take a better decision.
4. Don’t create a new option like library or framework in the community or in your organization unless you have great justifications and differentials. Prefer to contribute to an existing project instead of creating a new one. Only invest your time in a new option if the community or your organization doesn’t support what you need.
5. Don’t try to embrace the whole universe. The universe of options is growing up continuously, and because of that, it will not be feasible to use or know about everything at the same time. Instead, choose one option per technical requirement and change this option after a maturation time.