It usually looks like this: there's already a decision about new product / project, people are extremely happy & eager to start straight away, silently expecting to "do it all perfectly" this time, avoiding all the mistakes from the past. But before they get into actual work, there's the sweetest & the most pleasant work to be done ... Visiting the armoury to pick the optimal selection of libraries, frameworks, architecture patterns & other tools.

Fasten your seat belts, new toys ahead! :)

And then the quarrel starts:

• this testing framework or the other one?
• which DI container is the best?
• ORM, micro-ORM, nano-ORM, ...?
• MVP, MVC, MVVM, MVW, ...?

... and so on.

Everyone has her/his own opinion, preferences & .... hopes. Unless your happy flock suffers from the groupthink syndrome (btw. this one deserves a separate post), the battle flares up:

• "X is better, because it supports BDD style!"

• "Y is the one to pick, because company ABC uses it & everyone knows how successful they are!"

• "Extensive RESTfulness of Z makes it more RESTful than the REST ..."

In 99% of cases it's the clash of opinions & personal preferences, not facts. The less established the group is, the bigger's the problem (no surprise, people do not know each other, so they didn't had time to earn mutual respect).

Usually the battle is very fierce, but short. However, the consequences may be serious: from wounded pride and letdown frustration to avoidance of responsibility and no ownership over the solution. The most immature team members can even try to silently "smuggle" their tools of choice, hoping that when people find it out unification will be already too expensive.

The actual choice usually is far less important than many think. Unless someone opts for something very risky (low maturity, troublesome maintenance / support, very steep learning curve, no learning resources, etc.) or very outdated, each solution can be implemented pretty much equally well using myriads of different technical means. But many seem to ignore this mere fact, when there's something interesting within their (assumed) reach.

How to approach that?

There are several schools - sadly none of them perfect though :) I'll skip the ones that are just too naive or plainly stupid (like the worst possible choice: hoping that people "will just figure it out as community", which works only for either small or well-aligned, seasoned teams).

1. Moses - single person to show the right path, just like that; go to her/him, convince her/him, accept their final statement - obviously a wrong strategy if the person is delusional / not respected / lacks charisma, knowledge or firmness; heavily trust-based

2. Blackmail - my favourite one: single person sets "acceptance criteria" & asks the community to come back with ONE, agreed option that meets them, BUT keeps the right to veto (but not to override!) the proposal. Community is told straight away that if they fail to come with a single proposal, this single person will pick something him/herself - and here's the twist: it should be known from the beginning that this choice will be less welcome by developers than compromise they are able to work out (e.g. it can be a proven, but boring tech they want to move from). Works like charm :)

3. Guild wars - a basic trade between representatives of interested teams ;> jointly worked out, rotten compromise that doesn't fully satisfy anyone, but everyone has his/hers small win. Usually requires active facilitation, especially when conflicting personalities are involved.

4. Separation of concerned - an option for courageous, which also requires really sold, well-established teams; rules are basic - each teams chooses their stack independently, but:

• all the future operations & support (& suffering the consequences of own choices ...) is on the team
• there's some agree high-level protocol of compatibility (e.g. regardless of test framework, there's one common way to call all the tests, so a member of each team can do execute other teams' test)

1. Beauty contest - quite expensive, but can very positively impact engineering culture in the organization in general: in a fixed timebox (1 day <-> 2 weeks) willing teams prototype full-spike demos of the tech stacks of their choice & present it to whole community (short presentation + access to the source code); choice is by voting (can be anonymous), but teams can't vote for their own demos.

Whichever path you pick ...

... make sure that:

• rules are clear & well communicated for everyone
• responsibility is well defined & assigned
• scaling is taken under consideration (not only scaling in terms of performance, but also in context of solution's growth & number of people who will work on it in parallel)
• key technical choices are not rushed before they are truly needed (or at least fully confirmed) AND not delayed due to analysis paralysis when they start to become a bottleneck

Pic: © GiDesign - Fotolia.com