http://www.perlmonks.org?node_id=1135780


in reply to Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

Honestly, by now I don’t think that it is “the teams” that actually matter ... not in the slightest(!!)

Why?   “Because you are building:   a machine.”

“Who gives a damn(!), really,” if your ‘teams’ are Large or Small?   Who gives a damn(!!), likewise, if their ‘division of responsibilities’ was (in somebody’s lauded opinion ...) ‘appropriate?™’

Here’s the bottom line, IMHO.   (And the reason why you oughta go buy that Managing the Mechanism e-book ...)   When your team finishes its work, the software that you have “teamed up” to produce is going to walk out onto that playing field ... alone.

Your “team” is going to head to the locker-room, and as you do so, you’re gonna hit a Start button which will cause this thing that you have created to play the entire game ... Automatically.   And the standard-of-acceptance, at that point, is going to be:   Binary.   (1) it works, or (0) it does not.

The brutal fact of the matter is that we are all in the business of constructing software mechanisms which will be executed by a silicon chip smaller than our pinky fingernail ... and beyond our direct control.   The designers of mechanical robots are all-too familiar with such notions.   Even though our “robots” consist only of binary instructions, they are otherwise no different.