[ef47d35620c1]

The 'it depends' answers are good and I would not cite them as evidence of a problem. You employee people who understand what they are talking about and who also understand the importance of an accurate answer. They are probably very good engineers.

How does X close a TCP connection... it depends on the operating system in question. What cipher does my browser use when talking to X website... it depends on what ciphers are supported/available and how the client/server are configured. Which router do these packets go through... it depends. Is my password secure... it depends on the string you chose, the hash type used to store the password and who the attacker is and what their resources and time frames are.

There is hardly anything absolute in technology/software. And, people who want an absolute answer are only indicating that they do not understand the fundamental complexity issues that we deal with as technologists.

[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 ...

[jodrellblank]

The 'it depends' answers are good and I would not cite them as evidence of a problem.

They might be the best answers you could get in that company, but it would be better still to get:

"Use this library feature"

"Ok; are there any weird exceptions?"

"No, this is it. We rolled all that company's accounts into this system when we merged, all old accounts in when we upgraded, and planned and designed this to be good enough for the high risk accounts too. There's only a handful of other accounts kept separately and there is no way to verify those from here, by design."