I've heard this a lot. "The objections you raise are because the company isn't doing it according to Hoyle."

And in the end, what does that matter? I was talking about TDD for TEN YEARS before someone told me that you're not supposed to write all the tests for the entire project before writing any code. But that was precisely what everyone had told me, as they mocked me for writing design documents and for thinking there was no advantage in writing tests first.

First of all, younger developers don't read books. They've grown up with channel surfing and graduated to games and other short-attention-span junk. They don't know what Beck actually wrote.

So what does it matter? And even if I found myself on a "team" (sorry I hate that metaphor) that followed it exactly I don't think I would find is a lot more useful. All the methodologies require extra meetings.

The last company I worked for had their daily at 11AM in England which for me was 6PM. But the last time I worked onsite it was 8:30 AM and I hated everything about it. I asked that it be morved to an hour that would spare me a rush hour drive and they got frosty with me: "it's a *morning* standup" Uh, we don't stand up. They wouldn't change the time.

Everyone talks about backlogs, "technical debt" (sorry I hate Agile Newspeak); we didn't have such problems before the methodologies. On-time completion was common. It isn't now, because nobody can concentrate.

And the reason nobody can concentrate is because of all the interruptions.

And the reason for the interruptions is the methodologies. And programming as a social activity.

American Software Developer living in Vietnam. Classical musician (guitar, woodwinds), weightlifter, multilingual, misanthrope • XY

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store