Questioning DRY

tl;dr

Recently, I’ve been in conversations where people throw some doubt on DRY. In the cloud native, microservices mode of operating where independent teams are chugging along, mostly decoupled from other teams, duplicating code and functionality tends to come more naturally, even necessarily. And the benefits of DRY (reuse and reducing bugs/inconstancy from multiple implementation of the same thing), theoretically, no longer are more valuable than the effort put into DRYing off.

That’s the theory a handful of people are floating, at least. I have no idea if it’s true. DRY is such an unquestionable tenant of all programming think that it’s worth tracking it’s validity as new modes of application development and deployment are hammered out. Catching when old taboos flip to new truths is always handy.
Continue reading Questioning DRY

Bimodal IT leads to technical debt that must be paid, with interest

Instead, it has created a great divide, said Pucciarelli. “This siloed, divided approach brings frustration, disappointment and failure in multiple ways.” For one thing, it doesn’t support healthy team spirit, he said, and the innovation side tends to operate fast to deliver business solutions without the accountability around reliability, quality and security that is expected from the traditional IT side. “It leads to redundancy and inefficiency.”

Source: Bimodal IT leads to technical debt that must be paid, with interest

Maybe “bi-modal” is about temperament, not just enabling “sad IT”

More for the “I don’t think bi-modal is that far from what all us methodology hipster talk about” file here:

Q. Have you seen organizations that have officially reorganized around a Bimodal approach? What kind of job titles/job descriptions are you seeing?

It’s much less an organizational structure change, and much more about culture, process and method. But yes, it is not unusual in the short to mid-term to differentiate teams. Mode 2 usually starts life as being quite small, and often needs “protection”, to prevent the organizational anti-bodies killing it off. It is better to go narrow and deep and focus the capability on a particular part of the enterprise, or on particular domains like mobile for example. Small IT organizations (<50) don’t have the option to create any kind of split of course).

I'd still wager that most people who complain about bi-modal haven't read up on it too much (it's hard to do, and there's bat-shit expensive paywalls around it). Also, I think Gartner has been filling out the nuance of the original, clear idea: softening it and making it more practical, which makes it more ambiguous.

My theory here – based on conversations with people transforming large organizations – is that the focus here should be on the temperament of the people, not the process. For any given project, the proven process of small batches applies, but you’ll often want “cow-pokes” (risk takers who hate long term commitment) for new projects and “city-folk (enjoy stability) for post-1.0 projects.

There’s a chance for judgement about who the cool kids are vs. the old folks there, but I’d suggest finding that distinction is all about the perceiver. In my career, I’ve found people who are perfectly happy being in one of those two boxes. Problems arise (I think Apple’s negligence for apps their no longer interested in is a good bad result to ponder here), but I feel like it fits the staffing and prioritization needs of most large organizations.

But, I don’t call it “theory” for nuthin’.