Architecture is contextual, but don't play dumb

A great post from Jacob on the contextual nature of architectural choices. Shock news: he doesn't think that dependency injection frameworks are right for him and his business.

He makes a good case for in-house development being the place where YAGNI is the primary principle, at least so far as the choice to spend effort (= money) on technology choices like that. I sympathize: I've seen in-house teams (with a declared adoption of XP, no less) get into huge rows with their business sponsors because their devotion to a certain architectural stance cost them productivity. They burned up man-decades on trying to get the damn thing to work, ended up with an incomprehensible codebase and then, because it was the right thing, started all over again, only with a determination to get it right this time. IIRC, they eventually ended up implementing this framework three times. Productivity went down and down. The "coach" and "customer" couldn't be in the same room at the same time. So sad. Key to this falling-out was the idea that the (paying) customer isn't entitled to an opinion about how the work is done.

Meanwhile, a side discussion at one XPDay session this year touched on the question of taking into account a need that the customer has told you they have, but that they haven't given a high enough priority to for it to be in the current release. It would be wrong, according to one understanding of YAGNI, to implement this release in a way sympathetic to that upcoming goal. But why? If the customer has told you that some need is coming (soon, that is, as in "next release", and not "in the next five years"), and this lets you make a smarter choice about implementing the nearer-term goals...well, it would be foolish to ignore that information, wouldn't it?

YAGNI means "don't spend six months building a framework to support six days development", it doesn't mean ignore highly certain knowledge about the immediate future direction of the system.


Jacob said...

It's a good point about future updates you know are coming. You have a lot of key qualifiers that are pretty important, though. I'll highlight them:

"If the customer has told you that some need is coming [soon], and this lets you make a smarter choice about implementing the nearer-term goals..."

Given those qualifiers, I think you would indeed be foolish to ignore that information, though I'd add an additional qualifier for the amount of added work needed to prepare. The more I dig, the more YAGNI seems analog rather than binary. Which is why the need for professional software developers isn't going away any time soon...

keithb said...

Hi Jacob,
You are right to highlight those qualifiers.

Pretty much all engineering principles are about qualifiers, compromise, variability within tolerances, hedging, contingencies and all the other ways that the world is a messy, imprecise place.

It sees to be a collective personality defect of the IT industry that we want universal absolutes.