From: Arved Sandstrom on
Seebs wrote:
> On 2010-02-16, James Kanze <james.kanze(a)gmail.com> wrote:
>> On Feb 14, 4:56 pm, Seebs <usenet-nos...(a)seebs.net> wrote:
>>> On 2010-02-14, James Kanze <james.ka...(a)gmail.com> wrote:
>>>> To be really effective, design and code review requires a
>>>> physical meeting. Depending on the organization of the project,
>>>> such physical meetings are more or less difficult.
>
>>> Nonsense.
>
>> The more channels you have available, the better communication
>> works.
>
> Not so. Some channels can swamp others. If you're busy picking up
> facial expressions, instead of properly processing the raw data, the
> extra channel has HARMED your quality of communication.
>
>> There are probably some special exceptions, but other peoples
>> expressions and gestes are a vital part of communications.
>
> They may well be -- but my experience has been that you can communicate
> some things much better without them.
>
>> Not to mention the informal communications which occur when you
>> meet at the coffee pot. I've worked from home, and in the end,
>> I was frustrated by it because I was missing so much of the
>> informal communications which make things go.
>
> I would miss that, except that in my workplace (which spans several
> continents), the "coffee pot" is IRC.
>
>> That sort of thing is essential for any review. You do it
>> before the face-to-face meeting. But the reviewer isn't God,
>> either; the purpose of the meeting is to discuss the issues, not
>> to say that the coder did it wrong.
>
> If you do it well enough, I don't think the face-to-face meeting does
> anything but cater to superstition.
>
>> Almost universally. Ask any psychologist. We communicate
>> through many different channels.
>
> I do, in fact, have a psych degree. And what I can tell you is that, while
> there are many channels, sometimes you get better or more reliable
> communication by *suppressing* the non-analytic channels. Say, if you
> were trying to obtain accurate data about a thing subject to pure analysis,
> rather than trying to develop a feel for someone else's emotional state.
>
> The goal is not to have the largest possible total number of bits
> communicated, no matter what those bits are or what they communicate about;
> it's to communicate a narrowly-defined specific class of things, and for
> that plain text can have advantages.
>
> Most people I know have had the experience of discovering that a particular
> communication worked much better in writing than it did in speech. Real-time
> mechanisms can be a very bad choice for some communications.
[ SNIP ]

There is absolutely no question but that some things - many things -
work better in written form than in speech. Requirements specifications,
design documents, test plans and code itself are good examples.

As for code reviews I believe those can go either way. It depends on
skill levels overall, skill level differences, personalities, and
problems (or lack thereof) with prerequisite artifacts like design and
requirements. A code review that involves dysfunctional prerequisites,
dubious skill levels amongst the coders, and lots of ego - sort of a
common situation actually - is probably best handled f2f. IMHO.

But I've certainly seen code reviews that were handled nicely with no
personal interaction other than email or chat. This usually happened
when good requirements and design informed the whole discussion, all the
programmers were skilled, and the egos weren't too large.

A lot of times in a real code review you most definitely are managing
emotional state. That requires developing a feel for it, which you can't
do over chat. Seeing those blank expressions, or looks of anger, is
quite helpful in steering the review towards a somewhat productive
conclusion.

AHS
From: Richard Heathfield on
Nick Keighley wrote:
<snip>

> try dictating hex patches down a phone line.

Done that. Well, kind of. I once had to dictate assembly language
instructions down a phone line to a non-techie (broker), for him to type
into DEBUG, and then assemble and run. Fortunately, the program was very
short. (Although email and the Web both existed at the time, neither of
us had access to either of them, and the broker needed an instant
solution, so I couldn't just snail him a diskette.)

It wasn't easy!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
From: Seebs on
On 2010-02-16, Arved Sandstrom <dcest61(a)hotmail.com> wrote:
> A lot of times in a real code review you most definitely are managing
> emotional state. That requires developing a feel for it, which you can't
> do over chat. Seeing those blank expressions, or looks of anger, is
> quite helpful in steering the review towards a somewhat productive
> conclusion.

You make a good point here. With some experience, you can learn to preempt
a lot of that by attention to wording. At $dayjob, we have a couple of
techniques applying to this:

1. Code review is done on a list everyone sees. (We're still small enough
to get away with that, for now.)
2. Everyone's code is reviewed, even the "senior" people.
3. Over time, anyone watching the list will see enough people, some of them
quite senior, caught in mistakes or oversights, that they'll develop a
good feel for how to handle that.

It works surprisingly well. When you've seen a couple of the senior staff
say "whoops, yeah, I totally missed that, nevermind, I'll submit a V2 in a
day or two", it becomes much less worrisome to be asked to fix something.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Branimir Maksimovic on
Richard Heathfield wrote:
> Nick Keighley wrote:
> <snip>
>
>> try dictating hex patches down a phone line.
>
> Done that. Well, kind of. I once had to dictate assembly language
> instructions down a phone line to a non-techie (broker), for him to type
> into DEBUG, and then assemble and run. Fortunately, the program was very
> short. (Although email and the Web both existed at the time, neither of
> us had access to either of them, and the broker needed an instant
> solution, so I couldn't just snail him a diskette.)
>
> It wasn't easy!
>
That guy was pretty techie, because it contradicts my experience.
For example one guy was not capable to just find and change
parameter in config file, and I mailed him that.
Problem was that config file had about 1000 lines and
he didn;t knew how to apply case insensitive search.
In my experince lot of them don;t even know what is text
editor let alone debugger. So that guy was techie for, sure....

Greets
From: Richard Heathfield on
Branimir Maksimovic wrote:
> Richard Heathfield wrote:
>> Nick Keighley wrote:
>> <snip>
>>
>>> try dictating hex patches down a phone line.
>>
>> Done that. Well, kind of. I once had to dictate assembly language
>> instructions down a phone line to a non-techie (broker), for him to
>> type into DEBUG, and then assemble and run. Fortunately, the program
>> was very short. (Although email and the Web both existed at the time,
>> neither of us had access to either of them, and the broker needed an
>> instant solution, so I couldn't just snail him a diskette.)
>>
>> It wasn't easy!
>>
> That guy was pretty techie,

Nope.

> because it contradicts my experience.
> For example one guy was not capable to just find and change
> parameter in config file, and I mailed him that.
> Problem was that config file had about 1000 lines and
> he didn;t knew how to apply case insensitive search.
> In my experince lot of them don;t even know what is text
> editor let alone debugger.

Neither did this guy. If it hadn't been for the fact that this was in
MS-DOS days, I'd have had to talk him through opening a console.
Fortunately, he was already in the console because that was all his
system had!

I literally had to dictate every single thing I wanted him to type,
starting with Dee Ee Bee Yew Gee...

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within