Drive By Dialectics - Part 2

(Not @tottinge)

Part 1 stirred up a bit of a fuckstorm,  which surprised me less than how quickly it became a reasonable conversation.

Nobody cited the post as a LackOfGodwin violation, probably because there's no such thing yet. Maybe if I continue along this historically material path, there will be one.

But to be a little less inflammatory (get the Red out!), here's an analogy that's pretty much structurally identical:

    ScrumMaster:OrchestraConductor::XPTeam:JazzComboOrChamberGroup

(Party [Über]Animal)

A small group that communicates well doesn't need a non-performing leader. The key term there is not "small" but "communicates well".  There are conductorless orchestras, some of which are not particularly small.

Like a priest, the traditional conductor is believed to channel the sacred intention of the composer.

My role model, Charles Mingus - photo by David Redfern

Mingus could be as hard on his bands as any OberMusikenFührer in Germany, but he was also a great bassist and composer.

Got distracted by Mingus. Where was I? Casting aspersions on Scrum? What's the point? Sure, I'm a downtrodden victim of False Scotsman Scrum, but I live in Chicago. Do I have to tell you about my mayor? Worse than even False Scotsman Scrum.

Drive-by Dialectics

Ron Quartel, AKA @agileAgitator, came up with a nice analogy:

    Scrum:XP::VHS:Betamax

Here's my take:

    Scrum:Agile::Communist party:SocialDemocratic parties

The Communists perfected the concept of democratic centralism: an obvious oxymoron/contradiction that functions like a "Mystery" in a classic religion: among other things, it provides cover for autocrats. This lays the basis for what post-Stalinist Soviet leaders called a "cult of personality".  Witness Stalin, North Korea's "Dear Leader" and to a lesser extent Hugo Chavez and the Castros.

(If you think this kind of authoritarianism is incompatible with free enterprise, consider the PRC and Singapore.)

Scrum has triumphed in the corporate world because it centralizes control and information chokepoints in a "Master".  This reproduces the structure of a traditional corporation and promotes Agilewashing.

Other methodologies that essentially promote acentric/holographic democracy and the autonomy of teams are a near-impossible sell in a command-and-control world.

I have worked on four teams doing Scrum (obviously not True Scotsman Scrum - a period of dictatorship of the proletariat has to precede True Communism - substitute analogous rationalization).  One of them was run by an actual manager.  The other three were run by Certified Scrum Masters (blessed from Moscow?) who by the way were all genuinely intelligent and nice guys.

There was zero encouragement for team members to think about the process or about anything other than the microsilos (stories) they worked in - solo.

I don't doubt that these situations were more efficient/productive than classic Waterfall/Cowboy regimes.  But that's not saying much.

Closed for Permission, Open for Forgiveness

I used to think that the pattern I'm about to advocate here was unforgivable. Now I'm not sure - a side effect of test-infection.

I'm assuming OO here along with SOLID and DRY, and using the word "mock" because it's shorter than "test double", but not excluding "fake".

The controversial assumption: that tests are first class citizens and are therefore not forbidden to have an impact on production code.  In mechanical and electronic engineering, products are built to run "self-tests" long after they leave the factory: these tests are an integral part of the product and must be accommodated. Jordi LaForge ran Level 3 diagnostics in the middle of critical missions.  Freakin' Level 3, for Pete's sake! No controversy there.  But in software?

Suppose you have an object A that uses an object B. You want to verify with a test that A uses B appropriately. (Actually, because you're a smart programmer, you test-drive A to do the right thing.) You inject B as a constructor argument for A (no setter, because you understand the value of immutability).

So C, which instantiates A (whether C is a factory or a POLO [Plain Old Language Object]) now has to know how to provision/acquire/instantiate a B.  Maybe C is a container or a Springy framework, in which case you figure this is just part of its job.  But even in that case there's a dependency, no matter how cheap it is to create (say, with attributes/annotations).

If B is not part of a strategy pattern - if there's no "production reason" for injecting it - you're only doing it for the test.

What I've started doing is implementing a test-only constructor on A that takes a B argument so that I can inject a mock B. The production constructor instantiates B.

Frameworks like Hibernate make you create a default constructor so they can use reflection to set what should otherwise be private members.  That's nasty. Then there are the "beans" that require setters for every instance member when you really wanted an immutable value object. That's obscene.

Just sayin' - the test-only constructor is a microevil because nothing else has to know about it or use it.  Its visibility can be minimal, as long as tests can get at it.  For example, in a Java project where test source resides in a package structure parallel to but completely separate from production source, the test-only constructor can have default (≅ package) visibility. Similarly: assembly visibility in C#.

I'm not losing sleep over it.

Mandala for Developers

From Dead C++ Scroll 4762A - #DevelopersAreNotFreakinEngineers

(Note misspelling in lower left quadrant.)

Cf. Field notes XK7-2015 and JL9-2015