Comments on SandyWalsh.com: Should You Always Explain Why?

@Shawn, you're absolutely correct. You do need...

2010-06-09T08:18:13.114-03:00

@Shawn, you're absolutely correct. You do need to give your rationale for applying a process. I should have made it more clear in the post that this was done ... probably not well enough. :-)

It's hard to illustrate the impact of fragile tests until they've been bitten by a false positives or long running tests. You can show what a false positive is, but not the anguish of having to find them during a pre-release iteration.

I'm not implying the developers don't want to learn. They certainly do ... otherwise they wouldn't have been hired. But coming into a new environment and getting a fire-hose of knowledge in the face can tend to make these sorts of things get lost.

It's why I think the "hold off on commit bits" (older post) rule is so important. It forces you to take the time, review the code and impart the knowledge so that hopefully it doesn't take 3yrs for the important stuff to sink in.

Thanks for the thoughtful feedback.

@Mike, I like the idea of making them think the idea was theirs. Always a good negotiation tactic!

Although I think I agree with you in this case, I ...

2010-06-09T07:49:30.171-03:00

Although I think I agree with you in this case, I would have difficulty applying this in general terms, especially when it comes to developers. Good developers are, or at least should be driven by "why" and "what"...they study "how" but that may be another post.

In my (humble) opinion, developers that dig for "why" will usually build useful things since people tend to be vague with the "what" part of exactly what they want. "Why" is a clarifier for "what" and unless developers start asking "why" then they just work on like drones and never really produce the result that people are looking for.

I often find myself working with junior developers that don't "get it" when it comes to testing in particular. I think preaching is the natural reaction, but if you take the time to think about the "why" for testing in real terms: stable code, cleaner code, understandable code; you can come up ways to measure these outcomes and then hold developers to these measurable standards while enforcing the "test first" way of doing things.

At the end of the day, if it comes to it, you may have to resort to "just do it!" but I think taking the time to be able to articulate the "why" in measurable terms yields pretty good results.

Well, it's like a well-known psychologist says...

2010-06-08T11:58:55.469-03:00

Well, it's like a well-known psychologist says, "your kids may roll their eyes or pretend to not hear you, but they're always listening."

I think the same is true for Software Developers. Eventually,when the light bulb comes on, they will think it was their idea.