«

So I am walking by the desk and actually asking for more than, "Fine,"
now. I ask how it's going and try to actually get them to start showing
me some code if they have any. This has helped somewhat but some things
have slipped through still. Don't think it can be perfect.

Second thing I've done is that I've asked for a plan before code. I
told them they can branch the code, play with the code, etc... but that
I want to see a plan before anything is done in the trunk. So far this
hasn't actually happened, must have been a miscommunication or
something. However, it's a weird change so I expect a little backlash.

I hope that this second part will help me catch whether they understand
the problem, the code, and have a relatively decent solution before they
do a bunch of stuff I have to make them redo.

What do you think?

Noah Roberts wrote:
> So I am walking by the desk and actually asking for more than, "Fine,"
> now. I ask how it's going and try to actually get them to start showing
> me some code if they have any. This has helped somewhat but some things
> have slipped through still. Don't think it can be perfect.
>
> Second thing I've done is that I've asked for a plan before code. I
> told them they can branch the code, play with the code, etc... but that
> I want to see a plan before anything is done in the trunk. So far this
> hasn't actually happened, must have been a miscommunication or
> something. However, it's a weird change so I expect a little backlash.
>
> I hope that this second part will help me catch whether they understand
> the problem, the code, and have a relatively decent solution before they
> do a bunch of stuff I have to make them redo.
>
> What do you think?

This was meant to go in the thread about junior programmers. Something
got munged.

Noah Roberts wrote:
> So I am walking by the desk and actually asking for more than, "Fine,"
> now. I ask how it's going and try to actually get them to start showing
> me some code if they have any. This has helped somewhat but some things
> have slipped through still. Don't think it can be perfect.

It really does sound like you have a serious communication problem in
your team. The fact that standup meetings didn't work is a bad sign.
Did you read Martin's paper (the link)? There are some good tips there
on good and bad standup meetings.


I suggest you spend some time pairing with them to see what they are
really up to and make an effort to get good standup meetings going.


--
Ian Collins

On 3 août, 18:07, Noah Roberts <roberts.n...@gmail.com> wrote:
> So I am walking by the desk and actually asking for more than, "Fine,"
> now. *I ask how it's going and try to actually get them to start showing
> me some code if they have any. *This has helped somewhat but some things
> have slipped through still. *Don't think it can be perfect.
>
> Second thing I've done is that I've asked for a plan before code. *I
> told them they can branch the code, play with the code, etc... but that
> I want to see a plan before anything is done in the trunk. *So far this
> hasn't actually happened, must have been a miscommunication or
> something. *However, it's a weird change so I expect a little backlash.
>
> I hope that this second part will help me catch whether they understand
> the problem, the code, and have a relatively decent solution before they
> do a bunch of stuff I have to make them redo.
>
> What do you think?

I have skimmed through the old thread (it is so big) and you have my
sympathy.
One question nobody raised was:
do you want compliance or do you want to change/introduce methods ?

In the first case, you can simply set the tools and the rolee:
activate access control in the svn and create a integrator role that
review the code before comitting it to the main line. A perverse
effect can be that a parallel trunk can start to exists (everybody
using it) so it takes some checking.

If you want to introduce change or new practices, it is hard work. The
first step is to convince them. You may find some help from
"Peopleware" (Tom DeMarco and co) and more recently "Fearless
Change" (Linda Rising and Mary Lynn Manns) which introduce a pattern
language for changing organization. I have heard of a new book from
Tom DeMarco and co "Adrenaline Junkies..." that seems to also address
teamwork patterns but I have not (yet) put my hands on it.

As for your immediate concern, IMHO you'd better have compliance for
the short term until the junior got some more experience and use
tutoring on the open-minded ones (on a voluntary basis).
Introducing change for a short term such as standup meeting (as you
did IIRC) should be short in time (2 weeks) before a review of the
process (retrospective) where you ask them how they feel about it and
how they think it can be improved (i.e. they build their own ways that
work best for them). Retrospective is subtle management and orienting
this kind of meeting can be challenging, if you have not yet read
about it, you'd better do it before.

--
Michael

Noah Roberts <> writes:

> So I am walking by the desk and actually asking for more than, "Fine,"
> now. I ask how it's going and try to actually get them to start
> showing me some code if they have any. This has helped somewhat but
> some things have slipped through still. Don't think it can be
> perfect.
>
> Second thing I've done is that I've asked for a plan before code. I
> told them they can branch the code, play with the code, etc... but
> that I want to see a plan before anything is done in the trunk. So
> far this hasn't actually happened, must have been a miscommunication
> or something. However, it's a weird change so I expect a little
> backlash.

As a programmer, I find it extremely difficult to "plan" a design
process. The problem is that some parts that seems difficult before
hand, and for which you'd plan a lot of time or subtasks, may once
you've thought about them resolve to a simple and elegant solution,
while some other parts that seem easy and straightforward will finally
need a lot of grunk work, or even more thinking before an elegant
solution can be found.

See also: http://c2.com/xp/TheSourceCodeIsTheDesign.html


> I hope that this second part will help me catch whether they
> understand the problem, the code, and have a relatively decent
> solution before they do a bunch of stuff I have to make them redo.
>
> What do you think?

'redo'. That's also something that you should plan to do anyways.
http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway

Well, unless you have a spiral project life cycle, in which case you
will be constantly redoing parts...

--
__Pascal Bourguignon__

On 4 août, 11:17, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Noah Roberts <roberts.n...@gmail.com> writes:
> > So I am walking by the desk and actually asking for more than, "Fine,"
> > now. *I ask how it's going and try to actually get them to start
> > showing me some code if they have any. *This has helped somewhat but
> > some things have slipped through still. *Don't think it can be
> > perfect.
>
> > Second thing I've done is that I've asked for a plan before code. *I
> > told them they can branch the code, play with the code, etc... but
> > that I want to see a plan before anything is done in the trunk. *So
> > far this hasn't actually happened, must have been a miscommunication
> > or something. *However, it's a weird change so I expect a little
> > backlash.
>
> As a programmer, I find it extremely difficult to "plan" a design
> process. *The problem is that some parts that seems difficult before
> hand, and for which you'd plan a lot of time or subtasks, may once
> you've thought about them resolve to a simple and elegant solution,
> while some other parts that seem easy and straightforward will finally
> need a lot of grunk work, or even more thinking before an elegant
> solution can be found.
>
> See also:http://c2.com/xp/TheSourceCodeIsTheDesign.html

As a junior, I've had to write documentation before code; it was
reviewed and signed by a peer, the manager and the QA manager. It was
not a perfect process and I can't say it caught a lot of design issue
but but I got a lot of value from it from the design perspective.

> > I hope that this second part will help me catch whether they
> > understand the problem, the code, and have a relatively decent
> > solution before they do a bunch of stuff I have to make them redo.
>
> > What do you think?
>
> 'redo'. *That's also something that you should plan to do anyways.http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway

But the key is in:
[...]rebuild what has to be a better version, *given the advantages of
hindsight*.

If the junior hasn't sweat a bit over the issue and simply follow the
advice, he won't get an hindsight. He will simply say "Ok! let do it
your way".

As they say in Zen: the finger is not the moon.

> Well, unless you have a spiral project life cycle, in which case you
> will be constantly redoing parts...

Spiral project (does it have the same name in english ?) involves a
refinement of functional specs at each iteration, this is not the case
here: it is within an iteration.

--
Michael

On Aug 4, 11:17 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Noah Roberts <roberts.n...@gmail.com> writes:
> > So I am walking by the desk and actually asking for more
> > than, "Fine," now. I ask how it's going and try to actually
> > get them to start showing me some code if they have any.
> > This has helped somewhat but some things have slipped
> > through still. Don't think it can be perfect.

> > Second thing I've done is that I've asked for a plan before
> > code. I told them they can branch the code, play with the
> > code, etc... but that I want to see a plan before anything
> > is done in the trunk. So far this hasn't actually happened,
> > must have been a miscommunication or something. However,
> > it's a weird change so I expect a little backlash.

> As a programmer, I find it extremely difficult to "plan" a
> design process.

Or a coding process, or much of anything else. This is
something beginning programmers have to learn, and they need
help learning it from the experienced programmers. The problem
is that many experienced programmers (myself included) never
really learned it well, either. In a commercial environment,
however, it's essential---good management has a nasty tendency
to want to know how much something is going to cost before they
approuve the budget for it. (Stop and think about it: would you
sign a contract to have a house built, and to pay for it,
without any mention of the cost, or what the house will look
like when it's done?)

> The problem is that some parts that seems difficult before
> hand, and for which you'd plan a lot of time or subtasks, may
> once you've thought about them resolve to a simple and elegant
> solution, while some other parts that seem easy and
> straightforward will finally need a lot of grunk work, or even
> more thinking before an elegant solution can be found.

> See also:http://c2.com/xp/TheSourceCodeIsTheDesign.html

Note that pretty much anyone can (and does) post at that site.
Whether they know what they're talking about or not. (Note too
that being an expert in OO design does not qualify one as an
expert in software process. Or vice versa.)

> > I hope that this second part will help me catch whether they
> > understand the problem, the code, and have a relatively
> > decent solution before they do a bunch of stuff I have to
> > make them redo.

> > What do you think?

> 'redo'. That's also something that you should plan to do
> anyways.http://c2.com/cgi/wiki/wiki?PlanToThrowOneAway

It's often useful to budget a prototype. But you still have to
budget it---define how much it's going to cost, and what you
expect to learn from it.

> Well, unless you have a spiral project life cycle, in which
> case you will be constantly redoing parts...

That's pretty much the case everywhere.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Aug 4, 2:06 pm, Michael Doubez <michael.dou...@free.fr> wrote:
> On 4 août, 11:17, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:

[...]
> As a junior, I've had to write documentation before code; it
> was reviewed and signed by a peer, the manager and the QA
> manager. It was not a perfect process and I can't say it
> caught a lot of design issue but but I got a lot of value
> from it from the design perspective.

How was the review process carried out? I've found good reviews
catch a lot of errors (but the manager and the QA manager are
never part of the review team---that's not their role).

Another thing which helps junior employees a lot is having them
act as part of the review team. They may not catch many errors
(although one never knows---one of the most difficult errors
I've ever seen was found by a "stagiaire" (not sure of the
English word)), but they sure do learn a lot that way. (A good
review process helps at several different levels: it catches
errors, of course, but it also ensures that the code is easily
readable, it teaches less experienced programmers what is
expected, and it helps build a consensus with regards to what is
needed, and creates a community feeling.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Aug 4, 1:22*pm, James Kanze <james.ka...@gmail.com> wrote:

> Or a coding process, or much of anything else. *This is
> something beginning programmers have to learn, and they need
> help learning it from the experienced programmers. *The problem
> is that many experienced programmers (myself included) never
> really learned it well, either. *In a commercial environment,
> however, it's essential---good management has a nasty tendency
> to want to know how much something is going to cost before they
> approuve the budget for it. *(Stop and think about it: would you
> sign a contract to have a house built, and to pay for it,
> without any mention of the cost, or what the house will look
> like when it's done?)

Yes, but the problem is that software development is a creative
process involving insight, it´s not a simply deductive process. My way
of developing goes: My goal is a software that does this and that. My
restriction is I must use C++ and this operating system. Ok, it´s
possible, let´s go. As I focus on it I start thinking, "ok I need a
form here". That´s an iteration. 'Now I need this", another iteration.
I find it usually impossible to tell in advance how many iterations
will it take. Think about it, before writing a book, would you be able
to tell in advance how many sentences are you going to use ? I´ve seen
problems occur when a manager divided a problem in chunks in which he
thought his subordinates could do it in a one-only waterfall process
(perhaps he could) and asked him to write the documentation for it. In
the process, however, the guy needed a few other iterations which he
hadn´t predicted, and had to add things that were not in the original
document causing a little stress.

Rafael

On Aug 4, 1:28*pm, James Kanze <james.ka...@gmail.com> wrote:

> Another thing which helps junior employees a lot is having them
> act as part of the review team.

Very effective, but pride usually gets in the way.
"Junior programmers reviewing *my code* ? How dare them!"

Sad.

Rafael