4

Assume you have a small set of suitable programming languages (e.g., Python, C++, Julia), a clearly defined task (development of software services in the context of computational sciences), and a team of stakeholders with whom you'd like to pick the "most appropriate" language.

Assume that the pros and cons of each language have been carefully established (execution performance, development speed, maturity of language ecosystem, language fit in the company's tech stack, developer proficiency, …), and that all stakeholders, in total less than ten, are proficient software engineers. A few of them have almost religious views on which languages to use, while the majority may have one preference or another, but generally believes that all candidates would be viable.

You'd like to (#1) make a clear choice during the course of a call, (#2) maximize the chances of choosing the "best" language, and (#3) leave all stakeholders as convinced and empowered as possible.

Is there empirical evidence as to how to approach such an almost political, but highly technical debate in the most effective way (w.r.t. the aforementioned goals)? Are there some debating strategies that are recommended for such technology decisions?

Several options I could think of did not fully convince me. For instance, an open discussion may engage everyone, but is unlikely to yield a clear decision. In contrast, a poll almost certainly yields a clear decision, but is unlikely to yield the best choice (e.g., most stakeholders may prefer a high-level language such as Python or Julia, but C++ may end up receiving most votes).

Improve this question
8
  • 1
    I don't understand the downvoting. The question is imho rather clear, and should be relevant also to other tech leads or senior developers. Also, it's not constructive. Without leaving any comment or suggestion for improvement (go to different community? provide more details? phrase it differently?), it's difficult to take this as a learning opportunity. Commented Dec 9, 2021 at 6:46
  • 4
    "It seems to me almost like a political debating problem". Yep, you got it, and that's exactly why this question will be closed as too opinionated. Moreover, I think the premise is wrong, that there is a (absolutely) "best" language - there may be a best language for this group of people, and that's why in the end only a vote poll will work. But you may rewrite it a little and ask it on Workplace.SE instead. Commented Dec 9, 2021 at 6:46
  • 2
    ... note also speculative, hypothetical situations are not well received by our community (and I guess its not much different on Workplace.SE). As an alternative, you could check if the question would be a good fit for interpersonal.stackexchange.com Commented Dec 9, 2021 at 6:54
  • 4
    An important factor is fluency of your developer team with these technologies. A possible approach is to generate C++ or C code (like GCC or RefPerSys do....) from project specific formalisms. At last, most operating systems enable mixing several programming languages in a given application (perhaps by having several processes) Commented Dec 9, 2021 at 7:56
  • 4
    I'm torn between downvoting due to the question being somewhat off-topic and upvoting because it brings up a problem that is indeed often encountered by development teams. The helpful answer by Bart swayed me towards upvoting, as the combo of question and answer could actually be valuable. Commented Dec 9, 2021 at 9:29

2 Answers 2

Reset to default
10

If you want to make an objective choice between several technology candidates, I would use a selection sheet.

In a selection sheet, you have a row for each criterion that needs to be considered in making the selection and a weight for each criterion to indicate how important it is (on a scale of 1 to 10).

Next to that, you have a pair of columns for each candidate technology, where in the first column you fill in for each criterion how well that criterion is supported by the technology (on a scale of -3/impossible to +3/fully supported). The other column holds the product of the weight and level of support. This is the score for the technology on that criterion.

Finally, you have a row with the sums of the scores for each technology. The technology with the highest overall score is the one that is then objectively the best technology within the selection criteria.

What the group should agree upon is

  • what are the selection criteria
  • what is the weight of each selection criterion
  • what are the technologies under consideration
  • how well does each technology fit with each selection criterion

If you have people with a very strong preference for a particular technology in the group, you can expect some discussions where they try to steer either the selection criteria or the fit of the technology in favor of their preference.

Improve this answer
1
  • 5
    Two points: * Give "Developer proficiency" a pretty high weight, as Basile mentioned in his comment. * Consider repeating the process after discussing the results. People may find that their initial assumptions about suitable weights and scores were steering the process in an undesired direction. For example, if everyone agrees that execution speed should have utmost importance, you might end up with a technology choice that the team is unable to handle. Commented Dec 9, 2021 at 9:26
3

Just like for any other decision in software development, I would write an ADR https://github.com/adr/madr where criteria preferably include some measurable metrics (amount of developers familiar with the language, time to market to deploy the solution, risks of not having to write your own libraries...).

To make a clear choice during the course of a call I would publish ADR somewhere everybody has an ability to comment and schedule a meeting with all the stakeholders. Ones who prefer async communication will be able to write down their point of view, so it gets mentioned inside the resulting document, others will engage in live debate which will also be added to the doc. By the end of the meeting you will have all the criteria and data points for most of the options and some missing pieces. Fill them, reiterate over the document to make sure nothing is missing and you are set to make a decision.

Since the ADR contains all the context, problem statement and everything, I think the chances of choosing the "best" language are maximized and since the document is publicly available, everybody at any point will be able to see why the decision was made and the context of it.

I have written a dozen of ADRs at this point and here are couple of insides:

  • the less personality is in the doc -- the better. Sometimes I have a favorite option and judge other options not objectively, which is obviously bad and could be fixed by either reflection or thoughtful review
  • ADR minimizes cognitive load, because everything is written down, you don't have to remember staff
  • ADR removes the pressure to make "perfect decision". To me, the perfect decision is the one where a team given all the context, options and risks tried their best to achieve success. ADR documents exactly that.
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.