Too many chefs, how to manage them, software edition.

November 17, 2014 1:33 PM

What success (or failure) have you had with any kind of a software architecture vetting process?

Engineering organization of about 50 devs, and growing. We have roughly a dozen folks with titles along the spectrum from "Senior Software Engineer" through "Architect". We want to have architecture meetings where project plans are vetted by this group. The meetings are difficult to run because some individuals have very strong personalities and very firmly held beliefs. It's also unclear to what degree which feedback should be used and which not.

What experience have you had with this kind of a process? How have you defined the goals and format of the meeting? How have you reigned in the strong personalities?

Thanks

posted by colin_l to Society & Culture (5 answers total)

I've never really seen a whole-company "architecture committee" work well. At best it's a speedbump, and at worse it's a symptom of a much larger problem.

The best situations I have seen have had:

* Individual engineers experienced enough to make generally good architecture decisions.
* Staff/Principal engineers within or near each engineering group who can oversee designs from a higher level.
* Communication (not an official committee) among the principals about high-level decisions (avoiding re-inventing the wheel, identifying patterns that might need a more general solution, etc.).
* Very strong core/infrastructure teams who build the base systems the other teams rely on (often this is where the really big picture architecture decisions are made, so centralizing it can help a lot).

A lot of what it boils down to is hiring an engineering team who doesn't need to be micromanaged on this stuff, unfortunately. If you don't have that, no number of committees will fix it.
posted by primethyme at 1:48 PM on November 17, 2014

Scrum-of-scrums. Complete anti-pattern.

A single project with fifty devs is such a terrifying prospect that I'd probably run away.

Six teams of eight developers, each producing a component with a published API that one or more other projects have to consume... well, that's achievable. Basically, build higher walls between smaller teams. They'll still argue, but they'll argue about the points the projects touch, not the internal implementation details of other teams' projects.

It's also unclear to what degree which feedback should be used and which not.

Errrr... the person making that decision should already know the answer to that. Do you seriously have a bunch of senior devs explaining system internals to a HiPPO and asking them to choose between them?
posted by Leon at 2:39 PM on November 17, 2014

Organization-wide standards are your friend: We do it THIS way here.
posted by SemiSalt at 4:15 PM on November 17, 2014

Ask everyone who does 'architecture' to provide a written 25-word-or-less definition of 'architecture'. This exposes the committee approach for the quagmire that it is.

Then break-up-the-teams +1

No one who can't articulate 'loose-coupling' in concept and execution gets to lead a team.
posted by j_curiouser at 4:31 PM on November 17, 2014

If you have two Architects, you'll have two strong opinions.

The massive software company I work for (10,000+ devs) is moving toward "just in time architecture." I.e. "If you work here, you're smart enough to decide for yourself what to do." No more 3+ month architecture planning conferences. The former Architects are in an advisory role only.
posted by miyabo at 5:40 PM on November 17, 2014