Here's what I've changed.

N

Noah Roberts

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?
 
N

Noah Roberts

Noah said:
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.
 
I

Ian Collins

Noah said:
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.
 
M

Michael Doubez

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

Pascal J. Bourguignon

Noah Roberts said:
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...
 
M

Michael Doubez

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.
'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.
 
J

James Kanze

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.

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.)
'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.
 
J

James Kanze

On 4 août, 11:17, (e-mail address removed) (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.)
 
R

Rafael Anschau

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
 
R

Rafael Anschau

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
 
K

Keith H Duggar

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.

As you and your team gain experience with Early Review, you will
become more efficient and effective. Over time less and less will
slip through the combined dragnet of Early Review, Peer Review,
and testing.
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.

To make sure we are on the same page, is the "plan" you speak of
above the Daily Plan or Clear Spec notion? Or something else? If
it is the Daily Plan notion can you post an example Daily Plan
from one of your team?
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.

Hmm, the above makes me thing the "plan" above is the Clear Spec
notion; but, I'll wait for you to confirm. Have you implemented
the Daily Plan yet?
What do you think?

KHD
 
N

Noah Roberts

Keith said:
To make sure we are on the same page, is the "plan" you speak of
above the Daily Plan or Clear Spec notion? Or something else? If
it is the Daily Plan notion can you post an example Daily Plan
from one of your team?


Hmm, the above makes me thing the "plan" above is the Clear Spec
notion; but, I'll wait for you to confirm. Have you implemented
the Daily Plan yet?

It's not a daily plan, I've asked for an overview of how they intend to
address a particular problem once they've figured it out. Many of us
may not work with up-front design but none of us works in a vacuum and
just starts changing code willy-nilly. At some point you get an idea of
what is going to be necessary to get the job done and it is there that
I've asked to hear from them.

I hope this will give me a chance to be involved in that process a bit.
For example, had the one guy come to me and said he plans to just add
all the logic for a new feature in a function within the 'document' I
would have had a chance to explain why that's not such a great idea
instead of later after it's done having to say, "This is not good." I
am hoping that the process of talking about the planned approach will
give me better mentoring opportunities and be a more positive feedback
mechanism than having to tell someone they need to throw away everything
they just did...and unfortunately I have felt the need to do this a
couple times and no matter how well you word it...

I also really think some of my team needs to start looking at the
problem first rather than just code until it works. If I can get them
to think about it more then I think I could also get better design and
code from them. It's not like any of them are unintelligent or bad
programmers, they just are too focused on code and don't have enough
experience working with design to even consider what is going to cause
problems later.
 
R

Rafael Anschau

Noah, I know what you mean. Large projects need a well defined
architecture in order
to grow from a solid base, or else the software becomes an
unmanageable mess. Do they
know what the system´s main goal is, what the basic architecture or
the system is, and how to grow from there on ? Because all of those
imposes restrictions that they don´t seem to be getting.

Rafael
 
M

Michael Doubez

On 4 août, 11:17, (e-mail address removed) (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?

The design document was passed around and improvement were done from
comments and informal discussions.
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).

It was creative work and part of the specs were functional specs. The
CTO or the architect had to have a look into it in order to validate
the strategy and the QA role ensured it was up to standard in the form
and in the content (naming, glossary, reference ...).

The main review was performed with the peer.
Another thing which helps junior employees a lot is having them
act as part of the review team.

Yes. For the particular case I speak about, we were all junior. In
practice, we shared a lot about our current work and everybody had a
look to what others were up to which mean a lot of eyeballs had seen
the design.
 [snip]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.

And IMO, also importantly, it allows to show up work and get feedback:
the designer feel less alone knowing that somebody else appreciated
his work and get opportunities to improve or to discuss in-depth a
design decision.
 
J

James Kanze

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

In that case, you have a serious problem. Code reviews haven't
been introduced correctly, and will not be effective.
 
J

James Kanze

[snip]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.
And IMO, also importantly, it allows to show up work and get
feedback: the designer feel less alone knowing that somebody
else appreciated his work and get opportunities to improve or
to discuss in-depth a design decision.

That "someone else appreciated his work" is really the key to
good code review. When done correctly, programmers obtain a
real sense of satisfaction ("Erfolgserlebnis"---one of those
beautiful German compounds which simply aren't translatable) and
pride when the review comments says things like "this is really
well written" or "I had no problem understanding it". And end
up writing code with this in mind, with the goal of obtaining
such comments.
 
J

James Kanze

Yes, but the problem is that software development is a
creative process involving insight, it´s not a simply
deductive process.

So? Lot's of creative processes are subject to a budget.
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.

And yet, no responsible organization will let you even start
without some sort of reasonable estimate.
Think about it, before writing a book, would you be able to
tell in advance how many sentences are you going to use?

Not exactly, but editors are known to request specific word
counts. And delays. Software isn't like a novel, it's more
like a technical book, and these often have specific delivery
dates, set in advance.
 
R

Rafael Anschau

And yet, no responsible organization will let you even start
without some sort of reasonable estimate.

Straw man. This was said in the context of conformance to plans, not
with estimates. Even so, you know very well the there are usually
unexpected issues in the middle of the process that make most projects
say bye bye to deadline.

Rafael
 
M

Michael Doubez

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

You can reverse the comment:
By looking at your code, juniors will have the opportunity to learn
from you.

If the junior is smart enough to ask question and not comment on the
code. It should go well with any proud programmer.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top