[OT] dealing with lower level programmers

[Pascal J. Bourguignon]

And you have tried this firsthand? I have. email and instant
messaging are extremely limited forms of communication compared to
working with someone face-to-face sitting at the same machine.

I mentionned Skype also, for non-verbal communication.

Otherwise, yes, from the free-lance developer or system admin side of
the equation. Works very well.

The number of horror stories about getting programming done via
telecommuting totally overshadow the few cases where it has worked.

Further, this dreamworld workflow of (a) writing a spec, (b) sending
it off, (c) waiting, and then (d) getting a complete working software
package on-spec, on-time and on-budget. That's the funniest thing
I've heard in a while. This is no series of events that occurs in the
natural world. It's not a technology problem, it's a human
condition problem.

Well as with any project, delocalizing doesn't remove the project
management needs. You can apply the usually spiral development cycle
to get a better idea of the advancement of the project.


But mostly the point here is that you don't have the choice between:
- a good programmer here, and
- a good programmer there,
but between:
- a bad (because you don't have any choice) programmer here, and
- a good (because you have more to choose amongst) programmer there.

 

[James Kanze]

I mentionned Skype also, for non-verbal communication.

Otherwise, yes, from the free-lance developer or system admin
side of the equation. Works very well.

Not if you want anything maintainable, or of usable quality.
Communication is essential for program quality. And nothing
beats face to face communication.

What you can do, of course, *if* you can come up with a detailed
and rigorous specification up front (not the case that often),
is subcontract out to a company elsewhere: all the programmers
are still located together, just not where you are.

(That doesn't mean that certain phases of the implementation
can't be done "at home" by the programmer. I find that for the
actual coding, I work best when I'm absolutely isolated. But
the actual coding is not all of a quality product.)

Well as with any project, delocalizing doesn't remove the
project management needs. You can apply the usually spiral
development cycle to get a better idea of the advancement of
the project.

But mostly the point here is that you don't have the choice between:
- a good programmer here, and
- a good programmer there,
but between:
- a bad (because you don't have any choice) programmer here, and
- a good (because you have more to choose amongst) programmer there.

There are good programmers everywhere. The choice is between a
good programmer here, where you can manage him well, and a good
programmer elsewhere, where you can't manage him, so he can't
perform.

 

[Ian Collins]

There are good programmers everywhere. The choice is between a
good programmer here, where you can manage him well, and a good
programmer elsewhere, where you can't manage him, so he can't
perform.

I don't get that. I've worked for clients on the other side of the world
and we'd both say that they had no trouble managing me (not that they
had to) and that I performed well.

 

[Pascal J. Bourguignon]

^^^^
Here, "here" means at the OP's place.

There are good programmers everywhere. The choice is between a
good programmer here, where you can manage him well, and a good
programmer elsewhere, where you can't manage him, so he can't
perform.

In general. But not at the OP's place, where he just cannot find good
programmers, because there's a scarcity of programmers, good or bad.

 

[mzdude]

In general.  But not at the OP's place, where he just cannot find good
programmers, because there's a scarcity of programmers, good or bad.

There may be several reasons for this. The company doesn't/won't/can't
pay competitive wages.

After HR gets done writing the job description, there is only 1 person
on earth that fills all the requirements, so the only ones that apply
don't match any of the requirements.

Finding good people is tough. A personal reference is usually the best
way. Sometimes a users group focused on specifics is another. Before
the internet, there used to be computer groups, and programming
groups that actually met in person (hard to believe). That was always
an excellent way to maintain a network.

 

[Noah Roberts]

^^^^
Here, "here" means at the OP's place.



In general. But not at the OP's place, where he just cannot find good
programmers, because there's a scarcity of programmers, good or bad.

I should say "experienced" programmers. The guys I have under me are
good, they just lack experience...especially in design.

 

[Ian Collins]

There may be several reasons for this. The company doesn't/won't/can't
pay competitive wages.

After HR gets done writing the job description, there is only 1 person
on earth that fills all the requirements, so the only ones that apply
don't match any of the requirements.

That's easily fixed: don't let HR write the job description!

 

[Keith H Duggar]

I'm rather new to the project management thing with regard to managing a
team and I'm hoping some of the more experienced here can help me. I'm
sort of the technical manager rather than the people manager in that I'm
guiding the design of the project and trying to help the team develop a
project that's going to be maintainable on the other side.

I sympathize with your position and have experience dealing
with exactly the kind of problems you describe. So I'm going
to offer several concrete practical steps and then see how they
would have impacted the cases you described. (These are a bit
rough and it doesn't covering everything. Also there is some
nuance involved obvious. If you need clarification please
ask.) In return, please let me know months down the line if
and how these practices worked out for you

-- Daily Plan : everyone must maintain a Daily Plan text. This
text gives a short description of each work queue item for the
day (and perhaps next few days). Each morning employees update
their Daily Plan and email it to their manager who will review
the plan and if needed discuss it with the employee. This also
serves as a useful focus to help keep everyone on task. Daily
Plan items should be decomposed into chunks they are completed
in at most 1 day so that progress can be clearly observed.

-- Check Tick : one or more times a day the manager will check
with the employee regarding progress on the Daily Plan. Under
"normal" circumstances (no urgent work items or detailed pair
works) I find an after lunch update works well. This gives you
time to help them with problems, steer them on the right path,
etc and still have some hours left to see if progress is made.

-- Home Work : homework doesn't end with graduation. If there
is material they need to learn then assign reading material.
For example, ask that they read a chapter, item, etc and then
discuss it with them the next day.

-- Clear Specs : it is essential that managers write workable
and clear specifications. Code is one of the clearest forms of
communication so provide them with skeletons of what you want
such as interfaces or algorithms where appropriate. All specs
must be written! It's good to verbally explain and discuss the
specs, but ultimately the verbal communication must denoted in
written form and communicated. Employees should take notes in
technical discussions related to work items. If necessary this
fold all the way down to pair programming.

-- Peer Review : all work must be reviewed. Not only does this
help to catch mistakes it also helps to synchronize styles and
techniques increasing the homogeneity of the code. Furthermore
it ensures that more than one person knows the work. Finally
it increases the review skills of the reviewer which will help
them catch errors in their own code while writing it.

-- Early Review : as part of both Check Tick and Peer Review,
start the review process early and it often. You don't want to
let days of work go by only to find out in a final review that
it is far from what you wanted; so star early. Also the only
clear evidence that progress is being made is the work itself!
So when you Check Tick, take a look directly at the work with
your own eyes.

-- Brick Wall : when an employee does not follow clear written
instructions such as a specification, send the work back for
them to fix. Do not fix it yourself. They must learn there is
no option other than doing what they instructed to do and they
also need to see and understand their mistakes to learn from
them. Even fleas stop trying to jump out of a sealed jar ...
eventually. You are the cold Brick Wall that defines the way.

The problem is that I'm having an incredibly hard time communicating
what I need to communicate to the developers on my team. Let me
illustrate a couple examples:

Clear Specs. You need to provide clear written specifications
of want you want.

I've decided upon a project based svn structure so that each individual
project within the source control has the three standard directories:
trunk, tags, branches. To me it seems sufficient to point that out and
say that's what we're doing. I knew this stuff before I ever even
entered college. But I go beyond that and document what these
directories are used for, why they are there, and watch to make sure the
other developers can create their own project structure from scratch.

Well, this guy under me that I figure seems to understand things pretty
well...I let him sort of go for a while without really watching
everything he does trusting that since I've described what to do, why,
and seen him do it at least once...that he can do it again--and I need
to get some stuff of my own accomplished! Today I'm messing around in
those areas and here's a project he created without trunk, tags,
branches in the source control. I can fix that pretty easily but it's
really got me questioning how I can possibly inform my team what I need
and trust that they can do it in the future.

Brick Wall. These instructions are crystal clear. There are no
alternative paths. Make them do it over until they get it right.

Another example: I tell this one guy who's been a developer for like 20
years or something to work on setting up a property editor. I tell him
that I want a type-map based factory that I can request the appropriate
field editing widget from based on a string meant to represent what I
want to edit. He goes off "researching" some boost::fusion based crap
for two weeks and when I go to check on how he's progressed on something
that would take me an hour...he's nowhere. Now, I do encourage some
researching into ideas so that I can get input that I wouldn't have
otherwise but I explained repeatedly to this guy that we're in a hurry
and this just needed to get slapped out.

Daily Plan, Check Tick. Early Review. All of these would have
detected the lack of progress in 1 or 2 days at which point you
would have applied Clear Specs and/or Brick Wall to get things
moving. By the way "Research boost::fusion" would not be an
acceptable work queue item for the daily plan. It is far to
vague and general.

Yet another example: I set up a MVC pattern with the Controller being a
state machine based on what tool is currently activated by the user that
sends commands to a document for processing. MVC, State, Command,
right? These things are central to ANY UI based product (if not exactly
these patterns then ones derived from them) Dude wrote a state
controller for a tool that sent a command (without any checking to see
if it should even be done) that was filled with a call to the
document...where he implemented ALL the logic. Three days later I'm
still struggling to teach him how this stuff works and why doing it the
way he did is going to cause us trouble.

Clear Specs. Home Work. Early Review. Check Tick. I'm guessing
you were not providing clear *written* specs perhaps in the form
of some rough interface/implementation code skeletons. Also, you
might have assigned reading material for Home Work. Finally your
Early Review and Check Ticks would have prevented days of lost
work.

He keeps coming back with completely messed up code asking if it's
correct. Inside I'm screaming as I gently say no and try to explain how
and why.

Clear Specs. Give him code code to work with or if necessary
pair program with him some. He will learn from that activity.

People here must run into this problem. What do you guys do? How can I
make sure the project is done reasonably well without micromanaging,
which is just a waste of my time, or saying to hell with it and doing it
all myself?

Micromanaging *juniors* it not necessarily so bad at least in
the beginning when there is a lot to learn. But Clear Spec can
go a long way without micromanaging in the usual sense.

Saying to hell with it obviously will not allow you to distribute
the work loads. Clear Specs will allow you to do that. Remember,
these specs must be written. If you need to spend a day writing
specs, do it. That is the only way you can parallelize work to
juniors.

How do you mentor a whole team of people and still get
something written?

Well, 3 people is in my opinion about the maximum you can closely
manage and still do other work yourself. I believe the practices I
outlined above will help you.

I'm just frustrated as hell with the situation and sort of dispairing
that I'll ever be able to adequately communicate what I see as basic
stuff to people who don't seem to be getting it. These guys seem
intelligent enough...what am I doing wrong?

Are you using mostly written or mostly verbal communication?

This project is two months
overdue on milestone 1...with a whole festival of features left to add
before we're done. I'm getting really worried that I simply can't get
it accomplished.

Focus on getting the 80% or 90% of essential features that you
know you can finish. Worry about the other spice later.

Well, that's interesting because I did that a few times. Stopped in and
asked how it was going. A couple of the times I answered questions
about the scope of the project that I thought should have cleared things
up. All along the way I hear, "Going good." Then toward the last day I
don't recall exactly how it became apparent...but it hadn't even been
started. Until then I had been under the impression that he was making
progress, albeit slowly.

Early Review. You have to view the work product first hand.

We're all in the same area but I do tend to focus on writing my own
code. I'm also hashing out features myself and trying to design the
architecture of the project so that it doesn't later fall apart. That's
not exactly easy either

Sure. However, you need to assign sufficient time to effectively
distribute the work load as well. If you need to write specs then
write specs. Don't feel like you are wasting time. Also, don't be
afraid to delegate "hard" stuff. With the procedures above you
*will* get the code you want and if not Brick Wall until you do.

Yeah, I've managed to get a lot of books into the office and I see them
access them from time to time. I think I'm the only one in the office
(including my boss who defers to me on technical issues) who has a home
library and reads it. I've encouraged them to take books home and
nobody does.

Don't just encourage, assign them specific concrete Home Work
and discuss it with them the next day.

Part of the latest thing is I took a vacation and gave people a stack of
stuff and tried really hard to provide as much as I could in direction
for the next week while I was gone. I spent two full days preparing.

What exactly were you preparing? Written specs?

It's hard sometimes to accept though that there's obviously something
I'm doing wrong to cause some of this. When I have taken the time to
discuss it with them they seem to try and in some respects catch on.
Sometimes enough to disagree and then I get to explain further.

I sympathize. It is a learning process and sometimes a hard
process. It can also be rewarding though so keep trying.

Try pairing with them for a while.

Yes that sometimes works very well as part of Clear Specs and Early
Review.

It sounds like you may to some extent be leaving your team alone for too
long at a time and giving them a bit too much autonomy. There's a fine
line between delegating to your team and trusting them to do the right
thing, and slightly abdicating your responsibility to lead them by
giving them tasks and then not following them up to make sure they're done.

Precisely. Daily Plan, Check Tick, Early Review.

You said that one of your developers went off researching stuff for a
couple of weeks, when you were keen to get something knocked off as soon
as possible. I understand the frustration - but many developers are very
prone to wandering off to look at something they find interesting/think

Daily Plan helps to maintain focus and progress.

might be useful, and leaving them alone for two weeks does make this
sort of thing likely to happen. If the task's urgent, come back to them
and follow it up - the act of stopping by with a cheery, "How're you
getting on with it?" will make them understand that you're involved with
what they're doing and keen to see results.

Indeed. Check Ticks.

If you leave them alone -
which you see as trusting them to get on with it - they think you've got
better things to do, and won't be committed to the task. It doesn't have
to be a major time sink for you (and it's best not to keep bugging them
the whole time when they need to get on with it), but checking in with
them at the start/end of each day for 5-10 minutes is not unreasonable.

Spot on. I recommend start (Daily Plan), middle (Check Tick),
and end (Check Tick and Early Review).

To manage effectively, you need up-to-date information about what
they're up to and how it's going - and the best way to get that is
face-to-face. If necessary, have a short daily catch-up. Bring cake.

Yes. It also let you help them resolve problems. Sometimes your
superior experience will let you give them a guiding light that
can hours days or weeks of work. In this way you act more as a
mentor than a manager, and that is a very good thing.

On a separate note, what's the physical layout where you are? You say
you "go to check on how he's progressed" - does that mean that you're
not in close proximity office-wise? If there's any way you can get
everyone in the same area, it's probably a good plan. The problem seems
to be partly one of information flow in both directions - and improving
the physical layout can help that.

Yes. And so can very active and efficient use of a fast internal
email system. Email is usually the best for spontaneous but not
urgent communication since it avoids expensive context shifts
that result from interrupting someone.

Re. the chap with the MVC code - it sounds like the problem there is one
of lack of training. If that's the case, it's probably not his fault -
you might want to consider sending him on a course / acquiring a good
book for him to read on his own time.

I think it might have been a lack of Clear Spec.

Re. the svn chap - you might be better off not making it an issue of
trust (implying that you don't trust somebody is corrosive to a working
relationship). It's very unlikely that he's deliberately messing up the
repository structure to disobey you - much more likely is that he didn't
understand how important you believe it to be, or that he simply
forgot/wasn't paying attention. In the first instance, you're probably
best off emphasising its importance to him (firmly but gently), rather
than directing blame/criticism his way, however tempting. If it happens
again, then you have more reason to get annoyed.

The Brick Wall is cold and immovable. It is neither a friend
nor foe neither does it trust nor mistrust. It is simply FACT.

So essentially, I'd say:

* Give a really clear lead (even clearer than you're doing at the moment
- maybe even write it down for them) and check regularly on people you
know have a tendency not to listen/do what you ask them to (and find out
why they don't - occasionally they will have cause)

Exactly. Clear Spec. Must be written.

* Improve communication by regular, *short* catch-up meetings and by
improving the physical layout

Again spot on. Check Tick.

* Recognise skill deficiencies (as opposed to incompetence) and send
people on training courses where appropriate - don't necessarily assume
that people with lots of experience know everything you'd expect

Indeed. Clear Spec and Home Work.

* Be firm when necessary, but give people a chance first

Oh yeah baby, Brick Wall.

And - very important - check, what the guys are doing early. So if you
know, that it would take you only an hour, check back what the guy is
doing after an hour. I have some friends which are real good coders -
and hate to do this - maybe you too ;-)
But: The earlier you detect problems, the cheaper are the costs to fix
them (cost: time and money).

Spot on. Early Review is crucial.

You need to read a book entitled:

The Mythical Man-Month
Frederick P. Brooks
http://bit.ly/gt1t8

Yes, that is a MUST read.

I have suggested it and encouraged it many times.

I don't think I have anything to worry about, unfortunately. I'd be
pleasantly surprised if someone got mad at me for writing the OP.

Home Work.

As a technical lead / manager, I try to limit the management to
8 hours a week, review 8 hours a week and the rest of the time
trying to produce designs and coding.

It takes me at least 12 hours per week to manage a junior.

With the purpose of meeting milestones,

1) you have to accept that not all parts of the code will be done up to
_your_ standards.

Agreed. He needs to focus on the 80% of the requirements that
he can deliver.

2) you should define the interfaces and unit tests checking the
implementation works as you want, then you can let them implement
however they want.

Clear Spec. However, I don't let them implement "however they
want". Early Review and Peer Review will influence (heavily at
times) the implementation of junior members.

3) make a good decomposition of the project in independant subparts.
If you can develop a part as a standalone working program, this is
something that won't regress, so you can further advance the
project. This is the unix approach: simple tools doing simple
minded operations, combined in bigger systems.

Yeah, modularity is one of the coolest concepts ever.

The best you can do for your programmers, is to have good
specifications (use cases and validation tests).

Agreed. Clear Spec is crucial.

Just a thought: How many people are inside your team? I think that
chances are high that they are too many. In our company we have a lot
of students that make a kind of internship. As a rule of thumb one
student take about 25 percent of your time. So if you have four
students, you won't get anything else done. My wife's company has a
project leader that has 10 programmers under him (since they are
professionals, you can give each member a smaller time-slice that
1/4). This project leader had to hire an assistant for managing this
group.

Those rough guidelines are true in my experience.

Personally, I work at a project that has two contributors, one of them
keeps heading off to do "research" like a maniac. Sometimes I feel as
if I should watch him work the whole day just to see some progress. So
I feel a lot of sympathy for you.

Hehe ... I know the feeling.

Maybe you should quit contributing to your project yourself. See your
staff as the extension of your hands: The idea of how everything
should go is inside your head, but you cannot possibly type fast
enough to get it done. Let the others do the typing, concentrate on
making them type the right things. Whenever they get anything good
done, you should be so enthusiastic about it as if you had done it
yourself, and this feeling should be transfered to them.

That is good advice.

Here's another big issue. We're not in an area that holds a lot of
programmers. Almost our entire staff is, or was, interns. I could use
some mentoring myself and there's just none to be had. This group and
the writings of people like Martin, Fowler, Sutter, and Meyers are what
I've got. A while back I mentioned in a company improvement meeting
that, "I'm the best programmer you have, and that's a real problem."

Don't get me wrong, I belong where I am: Sr. Developer. I could just
use someone above me that knows more than I do.

I really do sympathize with you. Perhaps you could form some
contacts in the larger software development community to at
least get some mentoring outside of work. At least you have
some good forums though ;-)

KHD

 

[James Kanze]

I don't get that. I've worked for clients on the other side of
the world and we'd both say that they had no trouble managing
me (not that they had to) and that I performed well.

Were you working alone, or in a group? If alone, how did you do
code reviews, or brainstorming sessions. Good programming is a
team effort---a single individual is incapable of writing a
correct program, regardless of how skilled he is. And team
efforts mean collaboration and communication, which in turn
requires face to face communication.

 

[James Kanze]

^^^^
Here, "here" means at the OP's place.

In general. But not at the OP's place, where he just cannot
find good programmers, because there's a scarcity of
programmers, good or bad.

I don't buy that. It's possible that he can't get the required
staff at his place of work, but that's a budgeting or an
administrative problem, not linked to place---he won't be able
to hire a good programmer regardless of where he finds him:
locally or somewhere else.

 

[James Kanze]

I should say "experienced" programmers. The guys I have under
me are good, they just lack experience...especially in design.

And you can't hire an experienced programmer? In practice,
there are a lot of things inexperienced programmers can do as
well. But you still need a core of experienced programmers for
the critical parts, and for things like mentoring, and bringing
the inexperienced programmers up to speed. (Or is it a
manageerial problem. I've encountered companies where a
software engineer was a software engineer, and all software
engineers were considered "equivalent", with the role of the
personel department being to find the cheepest supplier for this
commodity. Obviously, such companies do end up with teams that
are largely incompetent, since they lower the offered salaries
until the only people who apply are those who no one else would
employ.)

 

[Ian Collins]

Were you working alone, or in a group?
Alone.

If alone, how did you do code reviews, or brainstorming sessions.

Acceptance testing and any reviews where done by the clients.
Brainstorming sessions where done over the phone.

Good programming is a
team effort---a single individual is incapable of writing a
correct program, regardless of how skilled he is.

Maybe, but I've written a lot of programmes for clients incapable of
reviewing the code. "Correct" behaviour can be determined with
sufficient developer and client testing.

And team
efforts mean collaboration and communication, which in turn
requires face to face communication.

True, but the collaboration and communication doesn't have to be between
programmers. Programmer - client communication is at least as
important as programmer - programmer communication.

 

[Pascal J. Bourguignon]

Were you working alone, or in a group?

Alone too.

If alone, how did you do code reviews, or brainstorming sessions.

Group work is not a guarantee of implementing code reviews.

Basically, you can do code reviews alone, by just forgetting your
code, and then reviewing it.

Good programming is a team effort

AFAICSITRL, this is completely wrong. Team programming leads to huge
quasi unmaintenable, bug-ridden programs that nobody can understand
completely, and that work only by miracle (and thanks to
encapsulation).


Mostly, where there's something wrong in a program by one, the one
will pause and correct the wrong thing. When there's something wrong
in a program by many, there is a lot of red tape, and group psychology
to overcome before being able to correct it. In practice most
problems in team programs never get corrected, just wrapped over as
far as there's a customer crying for a bug correction.

a single individual is incapable of writing a correct program,
regardless of how skilled he is.

This is obviously wrong, there are several example.

What may be true is that the scope and size of a program written by an
individual might be smaller, but how would that be a bad thing? At
least an individual will produce programs that are understandable and
manageable.

And team efforts mean collaboration and communication, which in turn
requires face to face communication.

"Mythical Man Month".

 

[Christof Donat]

Hi,

I've been leading a team in another company a while ago. Since I have
started my own business six years ago, of course I do all the management
as well. Actually I have to admit, that I never had these kind of
problems, because people always very much respected me as their manager
soon. It seems, that you already fell into the trap of not beeing
respected. Now things are a lot harder for you. You have to get your
team to accept you as their manager.

I've decided upon a project based svn structure so that each
individual project within the source control has the three standard
directories:
trunk, tags, branches. To me it seems sufficient to point that out
and
say that's what we're doing. I knew this stuff before I ever even
entered college.

So you entered college, when svn was allready in a usable state. This
kind of project structure is not typical with most other VC Systems. I
guess your programmers grew up with cvs or even rcs as a VC System if
one at all.

The structure you describe is really a good idea with svn. Don't move
away from it. I'm just saying, maybe they don't accept beeing lead by
such a young guy - compared to them self. I don't know how you came to
that position and what was up before you got there. Maybe some of the
team members originally hoped to get your current position or they think
you got there not because of your qualification but because your uncles
neighbour had a friend, etc.

My advice:

Show them you don't really need them, you can do everything they do at
least as good as they can. They are just there because you don't have
the time to do everything yourself. That will make them respect you as a
"real man". This is tough for you and really hard work, but if you can
do what they are doing, do it and show it to everyone in the team.

Listen to them. When your team members say, that your work is not good
ask them how you can improve it. That will give them the feeling that
you are respecting their experience. Diskuss their suggestions with them
to show them, that you really want to unterstand and improve your
skills. This seems a bit like the opposite to the above advice, but it
really isn't. In the summ you show them that you are one of them. Be the
primus inter paris.

If someone in the team is cooperating, give interesting projects to him.
Tell the whole team, that guy XY gets the interesting project, because
last time he did such a good work. As soon as one of the non cooperating
people starts cooperating give him an interesting project as soon as
possible. Let him be the lost son that comes back and tell all the other
how good his work was.

Never ever citisize the work of one of yout team members when someone
from outside is listening. Any critics always stays in the team. If some
of the team members starts doing that with one of his collegues, cut
him.
The team should be kind of the inner circle and internal discussions
should stay internal. This gives the team members the feeling like being
a kind of tribe and you are the chief of the tribe. You fight for them
against the bad outside world and they have to support you in this
heroic fight - kind of.

And of course talk to your manager and discuss with him what you are
planing to do. I guess he is a more experienced manager than you are and
he can give you good advice. I also guess,he knows the team members
longer than you do. He can give you some hints about them.

If you can't avoid talking to him about people doing bad work in your
team try not to name them. If you can not avoid doing that, make shure,
that the information stays confidential. When your team members learn
that you have done that, you are no longer the chief of the tribe, but a
traitor.

Christof

 

[Alf P. Steinbach]

* James Kanze:

Were you working alone, or in a group? If alone, how did you do
code reviews, or brainstorming sessions. Good programming is a
team effort---a single individual is incapable of writing a
correct program, regardless of how skilled he is.

Donald Knuth: LeX.

As I understand it and vaguely recall it was an interesting exercise in
"literate programming", a kind of far more sophisticated and powerful version of
today's doc comments (like //@), with the code just part of the documentation.

However I've never seen the code.


- Alf

 

[Pascal J. Bourguignon]

* James Kanze:

Donald Knuth: LeX.

As I understand it and vaguely recall it was an interesting exercise
in "literate programming", a kind of far more sophisticated and
powerful version of today's doc comments (like //@), with the code
just part of the documentation.

However I've never seen the code.

A lot of Open Source software are the work of single men, even if
later the original authors are able to aggregate contributors. But
notice that then, all the work is done remotely, with absolutely no
"management".

 

[Brian Wood]

Alone too.


Group work is not a guarantee of implementing code reviews.

Basically, you can do code reviews alone, by just forgetting your
code, and then reviewing it.


AFAICSITRL, this is completely wrong.  Team programming leads to huge
quasi unmaintenable, bug-ridden programs that nobody can understand
completely, and that work only by miracle (and thanks to
encapsulation).  

Mostly, where there's something wrong in a program by one, the one
will pause and correct the wrong thing.  When there's something wrong
in a program by many, there is a lot of red tape, and group psychology
to overcome before being able to correct it.  In practice most
problems in team programs never get corrected, just wrapped over as
far as there's a customer crying for a bug correction.

I think this is a growing problem. Even some of the "good
companies" are poorly run.


It may help to recall how Noah and his three sons built the
ark. In that case a single family worked out their salvation
while others were lost to the flood. That family was able to
produce a vessel capable of saving both them and a bunch of
animals including some birds that eventually helped them find
land.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

"As iron sharpens iron, so one man sharpens another."
Proverbs 27:17

 

[Default User]

Were you working alone, or in a group? If alone, how did you do
code reviews, or brainstorming sessions. Good programming is a
team effort---a single individual is incapable of writing a
correct program, regardless of how skilled he is. And team
efforts mean collaboration and communication, which in turn
requires face to face communication.

The past 2-1/2 years I've been working with groups half-way across the
country. I've had next to no face-to-face with them. We use online
meetings, telecons, email, instant messaging, all the modrun stuff.

Now, it would be convenient it they were here, don't get me wrong, but
it's certainly not impossible.





Brian

 

[Andrew Tomazos]

It may help to recall how Noah and his three sons built the
ark.  In that case a single family worked out their salvation
while others were lost to the flood.  That family was able to
produce a vessel capable of saving both them and a bunch of
animals including some birds that eventually helped them find
land.

Now tell the story of the Titantic, where a large team of the worlds
best engineers worked together in a flawless professional process to
produce an unsinkable ship.
-Andrew.

 

[James Kanze]

[...]

Acceptance testing and any reviews where done by the clients.

I would take that as a given. But if I were a client, the code
would either pass or fail the review, and if it failed, you
won't be paid. As a client, the reason I pay is to not have to
do all of the work.

Brainstorming sessions where done over the phone.

My experience is that often, the most important "brainstorming
sessions" are the impromptu ones. You cross someone working on
a different component at the coffee machine, and get to talking,
and you end up setting up a brainstorming session.

I'm not saying that with such modern tools as teleconferencing,
it is completely impossible, but I'm very, very sceptical. In
my experience, so much essential communication is impromptu---a
result of discussions with people you meet at the coffee
machine, and not a direct result of concrete planning.

Maybe, but I've written a lot of programmes for clients
incapable of reviewing the code. "Correct" behaviour can be
determined with sufficient developer and client testing.

Testing can never prove correction; it can only prove that the
code is incorrect. Depending on the application, stricter
proofs may be necessary (in which case, the client will have
someone competent, or employ a competent third party, to
validate them), or the client may simply depend on you to ensure
a certain level of correction.

True, but the collaboration and communication doesn't have to
be between programmers. Programmer - client communication is
at least as important as programmer - programmer
communication.

Certainly. And programmer--management communication as well.
Generally, the client--implementer communication will be
somewhat structured, but the programmer--programmer, and to a
degree, the programmer--management, communication entails a
significant amount of impromptu communication (as well as some
structured communication).