[thu]

That didn't seem his point. He didn't say at all that the person providing the answer was not competent or being imprecise or whatever negative. The example he gave was different that yours: it was about the software the team is responsible for and about the fact that technical debt has been formed. In dysfunctional organizations, dysfunctional software happens despite of the bright people.

[a3n]

"In dysfunctional organizations, dysfunctional software happens despite of the bright people."

A variation of Conway's law. https://en.wikipedia.org/wiki/Conways_Law

[zachrose]

The potential corollary: "In functional organizations, functional software happens even when the people aren't that bright."

Exciting or sad, or both?

[quanticle]

>"In functional organizations, functional software happens even when the people aren't that bright."

It could happen, but I've never seen it, nor have I even read about it the literature. The sum conclusion of 20 years of software engineering literature is that two things matter: the quality of your programmers and the stability of your requirements. Of those two, the first matters more than the second. Get those two, and it doesn't matter what methodology you use, you'll have functional and elegant software. Miss those two, and it doesn't matter what methodology you use, your software will be crap.

[a3n]

> the quality of your programmers and the stability of your requirements. ... Get those two, and it doesn't matter what methodology you use, you'll have functional and elegant software.

I've always believed that when excellent programmers advocate whatever methodology they use (e.g. Beck et al.) they themselves are missing the fundamental fact that they could produce excellent software using three sea shells.

I'm really glad that those excellent and public programmers don't have a more perverse sense of humor.

... or, maybe they do ...