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.

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:

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.

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.

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.

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.

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?  How do you mentor a whole team of people and still get 
something written?

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

* Noah Roberts:
> 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.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?  How do you mentor a whole team of people and still get 
> something written?
> 
> 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?  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.

Hm, I've guided and mentored people and had charge of hundreds of students, and 
  of student lab staff, but in developing work I've always either been in a 
small team or directly under a technical manager (helping others as needed but 
except for a few single persons not directly supervising them). So I can't give 
you advice from your point of view. However, I've been at the other end. :-)

Some of what you describe may be due to incompetence, unclear or lacking 
communication and/or resentment of your leadership (like, I'd rather be the 
lead, and I'll make sure you're doing badly). It does sound like some 
incompetence + communication, i.e. faults at both ends. Although with good 
people they'll just ask if it's unclear, and keep you informed.

Regarding resention, at all places I've worked there have been people with a 
negative-sum way of thinking, that what's bad for others must be good for me. At 
two places of work, one a vocational school in Bod�, and the other Accenture 
(then Andersen Consulting), there were even people stealing odds and ends from 
around everywhere. At AC when my stuff started to disappear I was a bit afraid 
I'd started to forget, or my mind was going. Happily, or sadly, later on, 
working in another firm, it was not far away, the AC people I met told me that 
thing was still going on. Ah, not me! I think, based on my personal experience, 
that in any large workplace there are Bad People. Also, latest news in Norway 
today was about a fire station in Kristansand, I think it was. Resentment of the 
new management was so acute that one worker who came back after sick call found 
his boots filled with gypsum (I think that's it in English), and others 
experienced various other sabotage. He was on "wrong side" of the conflict.

But as I wrote, I don't think the problem you describe is resention or active 
sabotage, rather, some incompetence, and some unclear communication, and too 
little communication, and then Murphy's law sort of exponentiates the whole 
thing. ;-)

A bad manager (from my point of view as underling) sees that as a control 
problem; how to better control these screw-it-ups.

A good manager (still from my point of view) *communicates*, and *listens*, and 
the best ones also *inspire*. And communication is two-way. So do not despair: 
talk with your people (and also your boss), explain the dire straits of the 
project, ask for suggestions, take them seriously, make them feel responsible 
for the project and individual tasks, and praise them when they do something 
good (but not otherwise, no false praise). But perhaps not ask them directly 
about your leadership style (just change it if this isn't what you already do), 
because, and I'll probably draw a lot of heat for saying this, as I view it most 
people react primarily or instinctively to surface appearance, and an appearance 
of weakness invites all sorts of counter-productive behavior.

That's as far as the general goes.

Regarding the dude who's asking about correctness all the time, it may be that 
he's received (what he has perceived as) contradictionary signals. Perhaps not 
from you, perhaps from others, it doesn't matter. But when the good/bad signals 
aren't perceived as consistent then just about anybody, including dogs :-), will 
ask for correctness all the time, trying to deduce what-the-heck is this "hidden 
factor" that I've not grokked, or simply because they've got the impression that 
that's what you want them to do. At the end he may give up on understanding and 
just do it his way. So again, if I'm right, it's about communication.

In short, if you don't do it already, communicate, that's my advice  --  from 
down below. ;-)


Cheers & hth.,

- Alf

PS: Communication can be overdone. E.g. your staff may be reading this, and 
you're writing under your own name. The point is that if so, then they'll know 
that your boss and others in the firm will be reading this, about them, and able 
to identify them, and they may resent that, and anyway if you are in a larger 
firm it was very thoughtless of you, albeit understandable. So while it is a 
good idea to ask for help, I think you've done it, perhaps exasperated and 
desperate, in a possibly sort of counter-productive way. The Norwegian solution 
to this kind of problem is what we call "lay down flat", to admit to the blunder 
and apologize and outline how you're going to deal with things. :-)

On 9 July, 20:54, "Alf P. Steinbach" <al...@start.no> wrote:
> * Noah Roberts:
> > The problem is that I'm having an incredibly hard time communicating
> > what I need to communicate to the developers on my team.

I'm not exactly an expert at this, but it might help if you tell them
what you want their code to achieve - not necessarily how it should
achieve it - and make sure they are clear about that. Then ask them if
they know how to achieve this. If they say yes, then leave them to it
for a bit, if they say know, then they have at least agreed to listen
to you.

Then, after they have supposedly written their code, test it against
what it is supposed to achieve. Get them to demonstrate to you that it
does do it. If it does, then hopefully all is well and good; if not,
ask them to justify why it doesn't. Hopefully this will make them
realise what it is they need to hear from you. They'll be more
receptive of what you say if they first realise that they need to
listen to it.

(snip)

> A bad manager (from my point of view as underling) sees that as a control
> problem; how to better control these screw-it-ups.
>
> A good manager (still from my point of view) *communicates*, and *listens*, and
> the best ones also *inspire*. And communication is two-way. So do not despair:
> talk with your people (and also your boss), explain the dire straits of the
> project, ask for suggestions, take them seriously, make them feel responsible
> for the project and individual tasks, and praise them when they do something
> good (but not otherwise, no false praise).

Indeed.

> But perhaps not ask them directly
> about your leadership style (just change it if this isn't what you already do),
> because, and I'll probably draw a lot of heat for saying this, as I view it most
> people react primarily or instinctively to surface appearance, and an appearance
> of weakness invites all sorts of counter-productive behavior.

I think there's more to it than that; I think your conclusion is right
even where your premise is wrong :-) There may well be people who will
take advantage if they see you as weak. But also, until you know
people well, a manager has to create a bit of an illusion, be clear
about certain things and shield their subordinates from certain harsh
realities. Your staff will probably be happier knowing that you
require X, exactly, than if they think that Y (which is a bit easier)
is *probably* acceptable but might not be.

Just a few off-the-cuff thoughts. Hope it is useful.

Noah Roberts wrote:
> 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.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?  How do you mentor a whole team of people and still get 
> something written?
> 
> 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?  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.

Disclaimer: Everything I'm saying here can be considered to be expressed 
tentatively, since I'm only a graduate student rather than a manager.

So - as with Alf (but with less experience than him), I can't speak from 
experience of managing people here, but for what it's worth from a 
"being managed" perspective:

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.

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

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.

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.

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.

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)
* Improve communication by regular, *short* catch-up meetings and by 
improving the physical layout
* 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
* Be firm when necessary, but give people a chance first

Hope that helps a bit!

Best wishes,
Stu

On Jul 9, 8:38=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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. =A0I'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.
>
> The problem is that I'm having an incredibly hard time communicating
> what I need to communicate to the developers on my team.

I have worked at various levels with programming teams of 1 to 200 for
about 15-20 years, including in and around many of the common NASDAQ
software companies.  The last large team I worked with was a startup
in Intel Corp's capital portfolio, where PhDs were scattered around
the engineering floor liberally.

My first comment is that I hope your staff don't read comp.lang.c+
+. :)

My second comment is that it sounds like you have a lot of juniors.
Hiring standards are absolutely key.  There are an endless parade of
people that think they know something about programming, just like
there are many people that fancy themselves as writers or painters.
When you try for a software engineering job at Google for example, you
can count on about 9 different interviews, each with a different
engineer - where you will have to work through a total of about 20 or
so software engineering and computer science problems of 30 mins each.

The problem is that a good programmer is not just 20% more productive
than an average one.  A good programmer is orders of magnitude more
productive than an average one.

You need to read a book entitled:

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

Embarrassingly, in the 33 years since it was first published in 1975,
things have not changed all that much in software engineering.  I
suspect even though our technology has gotten better - the bottleneck
is still the bottleneck - specifically us, the piddly humans, with our
inherit fallibility.

Finally, if firing them and hiring better programmers is not an
option, than you need to spend money and time on training.  If they
don't know how to use subversion, or write a simple inhouse UI tool or
what MVC is - than it sounds like you are going to have to wait over 2
years (if they ever pop) before they are cash flow positive resources.

I wish there was better news.  Unfortunately good programmers dont
grow on trees, and it takes a long time to teach.
  -Andrew.

Stuart Golodetz wrote:

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

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.

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

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

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.

I have sent a message to my boss about this and hope to see some 
training for these guys.  Economy is tanking us a bit though.  I'm on 
reduced hours.

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.  I 
came back and it was all ignored.  Not a single suggestion I had given 
was used, which wouldn't be bad if the thing actually did do what it was 
supposed to.  Problem is that it only appeared to on first examination.

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.

Andrew Tomazos wrote:
> My first comment is that I hope your staff don't read comp.lang.c+
> +. :)

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.

Thanks for the input guys.  I've got lots to think over.  Can't really 
do anything about the fact that we hire junior programmers; we can't 
afford otherwise.  To tell the truth it's almost impossible to find 
good, dedicated developers of any level.  At least the people we have 
are willing to learn and may someday be good.

I'll grind over the input you've given me.  Thanks.

Noah Roberts <roberts.noah@gmail.com> writes:

> [interesting cases]
>
> 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?  How do you mentor a whole team of people and still get
> something written?
>
> 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?  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.

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.

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.

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.

4) Repeatition is the base of pedagogy.  Also, repeating with variants
   may help: when somebody doesn't understand twice the same
   explanation, try other kinds of explanation, until you identify the
   kind of explaining he understands.  Some understand theories (give
   them axioms and deduction rules, and they'll deduce everything by
   themselves).  Others need examples to infer the rules themselves.
   It's often good to have a mix.  Some also understand better by
   seeing other doing, hence the idea of letting couples of
   programmers working together.

5) read The Mythical Man Month. 

6) read about mappers and packers.
   http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/


The second point can be applied at different levels.  If there's no
light bulb about MVC and you're in a hurry, you could define the
classes and their interface, and have him implement them in this
frame.


Points two and three combine to save your life: if something is wrong,
you should be able to rewrite the bad module quickly enough, because
they should be small, and independant from the others (communicating
only thru the interfaces you defined).


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


-- 
__Pascal Bourguignon__

On Jul 9, 7:18=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Thanks for the input guys. =A0I've got lots to think over. =A0Can't reall=
y
> do anything about the fact that we hire junior programmers; we can't
> afford otherwise. =A0To tell the truth it's almost impossible to find
> good, dedicated developers of any level. =A0At least the people we have
> are willing to learn and may someday be good.
>
> I'll grind over the input you've given me. =A0Thanks.

Biggest problem in our field is that **management** has decided
that **programmers** will make $X. When you are a good programmer
and you want to make $(X + delta) you must then become a **manager**.
It is an evil plot to eliminate all good programmers :^)

I currently manage other software types. We only have 1 rule.
**Everything** you do must be checked by someone else. If you create
the source tree, someone else must use it. If you check in code,
someone
else must review. We have a build manager, but from time to time, on
a whim, I'll assign someone else to do the build. It ensures good
communication and traceability.

This did not come easily, nor is it without friction at some times.
This is where you earn the $(delta). I've had some people quit,
and I've had to let others go who just didn't want to buy into the
team concept. What has emerged is a fast well integrated team that
appreciates what other team members contribute.

I've often heard that managing software people is like trying to
herd cats (I think there's a book by that title). Once you get the
group co-operating, realize not every idea you have is great, and
sometimes the ones working in the trenches really do have a better
way.

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.

On Jul 10, 2:13=A0pm, mzdude <jsa...@cox.net> wrote:
> I've often heard that managing software people is like trying to
> herd cats (I think there's a book by that title).

There is an old superbowl commercial where some cowboys actually try
to herd a group of about 2000 cats over some hills:

   http://www.youtube.com/watch?v=3DPk7yqlTMvp8

It's fracking hilarious.
  -Andrew.

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

Maybe don't ask 'how its going?' - everyone will answer 'good'. Instead 
ask 'What are you doing at the moment and where are problems?' (or 
something like that).

The first questions allows the simple answer 'good' - the second answer 
can't be answered with a single word. So the developer you ask has to 
form a complete sentence. That make it easier for you to figure out, 
whats going on and if there are some problems.

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

What I would try: Explain what it needed and what the developer is 
supposed to do - and then let the developer explain the same thing with 
his OWN words and how he is going to implement this. If he has 
completely no clue how to do this, you can give him further information 
/ instructions and/or tell him where he can get the information he needs 
(code sample from other project, a book, web page).

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

Best wishes,
Ferdinand

Noah Roberts wrote:
> Stuart Golodetz wrote:
> 
>> 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 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.
> 
> 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.

Try pairing with them for a while.

-- 
Ian Collins

On 9 Jul., 20:38, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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. =A0I'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.
>
> The problem is that I'm having an incredibly hard time communicating
> what I need to communicate to the developers on my team.

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.

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.

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.

Regards,
Stuart

Stuart Redmann wrote:
> On 9 Jul., 20:38, Noah Roberts <roberts.n...@gmail.com> wrote:
>> 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.
>>
>> The problem is that I'm having an incredibly hard time communicating
>> what I need to communicate to the developers on my team.
> 
> Just a thought: How many people are inside your team?

Well, now there's just the one.  There was two but I had one guy moved 
to another team; I just could not get him to do what I needed.  Don't 
know or care who's fault that was, it was just necessary.  He's doing 
great on the other team so maybe it was mine.

The projects are very different too though.  I'm working on one that is 
meant to implement many of my ideas for process improvement.  The other 
project does not have the same focus on design, unit testing, etc.

  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.

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.

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

Yeah, it's the getting them to write the right things I'm having trouble 
with.  It does appear there are some focus things I can do though that 
can improve that I hope.

The other member is gone for a while so maybe I can use this time to 
document things better and when he comes back there will be easier ways 
to discuss what's needed.

On Jul 14, 5:35 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Stuart Redmann wrote:
> > On 9 Jul., 20:38, Noah Roberts <roberts.n...@gmail.com> wrote:

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

Probably not for the programming, but for the process management
issues.

I've not followed this thread in detail, because any real
answers would take more time than I can give right now.  But the
important thing to keep in mind is that you can't do it
yourself.  You need help.  You need help from the people above
you, to create an atmosphere which encourages open communication
and a striving to improve (which means e.g. that people feel
safe going up to there boss and saying they've made a
mistake---until you've acknowledges a mistake, you can't correct
it).  And you need help from those below you, to buy into this
philosopy.  In my experience, the problem is usually above you,
not below you: most people I've worked with have been quite
competent, and most would be very happy improving the quality of
their work, IF they felt that it was safe, given the attitudes
of management.  But until these people feel safe, not just with
regards to you, but with regards to everyone who might be called
on to judge their work, nothing's going to happen.

Once you've gotten past that hurdle, of course, the next problem
is selling your ideas concerning quality.  Most people don't
like being told outright that they have to change the way
they've been doing things.  One of the reasons the SEI programs
work so well is that they don't come in, and just say, do it
like this and like this.  Rather, they start by proposing
various ways of measuring productivity and quality (which also
have to be sold---not every programmer will accept off-hand that
the measurements are valid).  Only then to they start trying to
improve productivity and quality.  And you start by asking the
individuals what they think should be done.  And trying it, even
if you're convinced the effects will be negative.  (That's why
the importance of measuring.)  And maybe suggesting a few other
things that they might like to try.

Add to this a notion of personal responsibility---each
programmer is expected to (measurably) improve his code, and
you're just there to offer suggestions and aid in his attempts
to do this, and the results usually end up what is wanted.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 9, 1:38=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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. =A0I'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.
>
> The problem is that I'm having an incredibly hard time communicating
> what I need to communicate to the developers on my team. =A0Let me
> illustrate a couple examples:
>
> 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. =A0To me it seems sufficient to point that out and
> say that's what we're doing. =A0I knew this stuff before I ever even
> entered college. =A0But 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. =A0I 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.
>
> 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. =A0I 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. =A0He 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. =A0Now, 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.
>
> 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. =A0MVC, State, Command,
> right? =A0These things are central to ANY UI based product (if not exactl=
y
> these patterns then ones derived from them) =A0Dude 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. =A0Three 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.
>
> He keeps coming back with completely messed up code asking if it's
> correct. =A0Inside I'm screaming as I gently say no and try to explain ho=
w
> and why.
>
> People here must run into this problem. =A0What do you guys do? =A0How ca=
n 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? =A0How do you mentor a whole team of people and still get
> something written?
>
> 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. =A0These guys seem
> intelligent enough...what am I doing wrong? =A0This project is two months
> overdue on milestone 1...with a whole festival of features left to add
> before we're done. =A0I'm getting really worried that I simply can't get
> it accomplished.

There's a guy at my work who won't even use a debugger.  Ever.  For
anything.  I'm not kidding.  It's pretty much the most frustrating
thing ever, and it takes him days to find bugs that I can find in 10
minutes.  And even then, memory corruption bugs, double deletes, race
conditions, forget about it.  Someone else usually has to find those
types of bugs.  Furthermore, if you mention to him that there's a bug
in his code it turns into a 1-hour argument that keeps changing every
5 minutes when it's apparent he doesn't know what he's talking about
with respect to the first point.  And the whole time he'll be staring
at his screen instead of looking at you while arguing, and you can
kind of see from around the back of his head that he's smiling because
he knows he's being a complete doofus but just doesn't want to look
bad.

Everybody knows this guy is a problem, but the company is small and
it's just "one of those situations".  I like the guy in some respects
but honestly I just want stuff to get accomplished sometimes you know?

Anyway I don't suppose this gives you any advice on how to deal with
your situation, since we certainly haven't figured out a way to deal
with ours (the obvious solution won't happen for management reasons).
But at least you know other people deal with similar frustrations.

Noah Roberts <roberts.noah@gmail.com> writes:

> Here's another big issue.  We're not in an area that holds a lot of
> programmers.  

Hey look, it's your lucky day!

Computer geeks invented something to solve your problem, it's called
"The Internet".

With "The Internet", you can send specifications to highly qualified
programmers located elsewhere, and get back good quality code along
with an invoice.  You pay the invoice and you may send back
specification patches, to get program patches.  You may have
"meetings" with these highly qualified programmers, thru "The
Internet", using programs such as Skype, so you can see how grumpy or
professionnal they look.  If you hire several of them you could even
display a row of Skype windows on your screen, so your manager would
know that you manage a row of programers...


-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:
> Noah Roberts <roberts.noah@gmail.com> writes:
> 
>> Here's another big issue.  We're not in an area that holds a lot of
>> programmers.  
> 
> Hey look, it's your lucky day!
> 
> Computer geeks invented something to solve your problem, it's called
> "The Internet".
> 
> With "The Internet", you can send specifications to highly qualified
> programmers located elsewhere, and get back good quality code along
> with an invoice.  You pay the invoice and you may send back

This also depends on how lucky you are, and how "highly qualified 
programmers" are really qualified, no?

Vladimir Jovic <vladaspams@gmail.com> writes:

> Pascal J. Bourguignon wrote:
>> Noah Roberts <roberts.noah@gmail.com> writes:
>>
>>> Here's another big issue.  We're not in an area that holds a lot of
>>> programmers.  
>>
>> Hey look, it's your lucky day!
>>
>> Computer geeks invented something to solve your problem, it's called
>> "The Internet".
>>
>> With "The Internet", you can send specifications to highly qualified
>> programmers located elsewhere, and get back good quality code along
>> with an invoice.  You pay the invoice and you may send back
>
> This also depends on how lucky you are, and how "highly qualified
> programmers" are really qualified, no?

Yes, of course, you have to make your selection, but at least you're
not restricted to the locally available pack.

-- 
__Pascal Bourguignon__

On Jul 15, 11:04=A0am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> With "The Internet", you can send specifications to highly qualified
> programmers located elsewhere, and get back good quality code along
> with an invoice.

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

Andrew Tomazos <andrew@tomazos.com> writes:


> On Jul 15, 11:04�am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> With "The Internet", you can send specifications to highly qualified
>> programmers located elsewhere, and get back good quality code along
>> with an invoice.
>
> 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.


-- 
__Pascal Bourguignon__

On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Andrew Tomazos <and...@tomazos.com> writes:
> > On Jul 15, 11:04 am, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> With "The Internet", you can send specifications to highly qualified
> >> programmers located elsewhere, and get back good quality code along
> >> with an invoice.

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

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

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

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.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> 
>> 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.

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.

-- 
Ian Collins

James Kanze <james.kanze@gmail.com> writes:

> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> But mostly the point here is that you don't have the choice between:
                        ^^^^
Here, "here" means at the OP's place.


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

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.


-- 
__Pascal Bourguignon__

On Jul 16, 6:30=A0am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
>
> In general. =A0But 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.

Pascal J. Bourguignon wrote:
> James Kanze <james.kanze@gmail.com> writes:
> 
>> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>> But mostly the point here is that you don't have the choice between:
>                         ^^^^
> Here, "here" means at the OP's place.
> 
> 
>>>     - 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.
> 
> 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.

mzdude wrote:
> On Jul 16, 6:30 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> 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.

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

-- 
Ian Collins

On Jul 9, 2:38 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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.

On Jul 9, 7:06 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Stuart Golodetz wrote:
> > 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
> > 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.
>
> 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.

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

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.

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

Ian Collins wrote:
> Try pairing with them for a while.

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

On Jul 9, 5:10 pm, Stuart Golodetz
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
> 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.

On Jul 12, 7:07 am, Ferdinand Mitterbauer
<ferdinand.mitterba...@gmx.at> wrote:
> 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.

On Jul 9, 5:57 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> You need to read a book entitled:
>
>     The Mythical Man-Month
>     Frederick P. Brooks
>    http://bit.ly/gt1t8

Yes, that is a MUST read.

On Jul 9, 7:10 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Andrew Tomazos wrote:
> > My first comment is that I hope your staff don't read comp.lang.c+
> > +. :)
>
> 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.

On Jul 10, 8:13 am, mzdude <jsa...@cox.net> wrote:
> 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.

On Jul 10, 5:32 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> 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.

On Jul 14, 4:58 am, Stuart Redmann <DerTop...@web.de> wrote:
> 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.

On Jul 14, 11:35 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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

On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:

> >> 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 ther=
e.

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

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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 16, 12:30 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> But mostly the point here is that you don't have the choice between:

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

> >>     - 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 ther=
e.

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

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 (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 16, 5:23 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Pascal J. Bourguignon wrote:
> > James Kanze <james.ka...@gmail.com> writes:

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>>> wrote:
> 
>>>> 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.
> 
>> 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?  

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.

-- 
Ian Collins

James Kanze <james.kanze@gmail.com> writes:

> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>> > wrote:
>
>> >> 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.
>
>> 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?  

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


-- 
__Pascal Bourguignon__

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

* 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

"Alf P. Steinbach" <alfps@start.no> writes:

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

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

-- 
__Pascal Bourguignon__

On Jul 17, 4:35=A0am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> >> > wrote:
>
> >> >> But mostly the point here is that you don't have the choice between=
:
> >> >> =A0 =A0 - a good programmer here, and
> >> >> =A0 =A0 - a good programmer there,
> >> >> but between:
> >> >> =A0 =A0 - a bad (because you don't have any choice) programmer here=
, and
> >> >> =A0 =A0 - a good (because you have more to choose amongst) programm=
er there.
>
> >> > There are good programmers everywhere. =A0The 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.
>
> > Were you working alone, or in a group? =A0
>
> Alone too.
>
> > If alone, how did you do code reviews, or brainstorming sessions. =A0
>
> 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. =A0Team programming leads to huge
> quasi unmaintenable, bug-ridden programs that nobody can understand
> completely, and that work only by miracle (and thanks to
> encapsulation). =A0
>
> Mostly, where there's something wrong in a program by one, the one
> will pause and correct the wrong thing. =A0When 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. =A0In 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.


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

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

James Kanze wrote:

> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:

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

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

On Jul 17, 9:27=A0pm, Brian Wood <c...@mailvault.com> wrote:
> It may help to recall how Noah and his three sons built the
> ark. =A0In that case a single family worked out their salvation
> while others were lost to the flood. =A0That 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.

On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:

    [...]
> >> 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?

> Alone.

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

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

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

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.

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

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

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 17, 11:35 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >> > On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
> >> > wrote:

    [...]
> >> > 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.

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

Working along is a guarantee that they aren't implemented,
however.

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

I do that too, when I have to work alone.  It's still far from
being as effective as having other people do the review.

There's also all of the ad hoc discussions that occur (or should
occur) when you're working in a team.  You discuss what you're
doing with someone else at the coffee machine, and he points out
a potential problem.  That you then fix, before formel review.

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

No doubt that's why all of the companies implementing critical
systems insist on team programming, and why it is required in
such cases.

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

That's just bullshit.  Mostly, programmers are human beings, and
as such, imperfect.  They all make mistakes.  And they don't see
their own mistakes---that takes someone else.

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

> This is obviously wrong, there are several example.

Such as?

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

Irrelevant here.  You're not adding additional people (beyond
the optimal) in the middle of a project, to hopefully make the
project go faster.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
> On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:

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

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

That family wasn't a single individual.  And in the version I
heard, they had some significant outside help, especially with
regards to design and management.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 17, 2:29 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * 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.

That's probably the closest, but don't forget that he was a
professor, and supervised a number of doctorat theses.  I don't
think that anyone in accademia really can be said to be working
alone.  (I seem to recall reading somewhere that in fact,
something like 80% of TeX was actually coded by one of his grad
students.  I can't find the reference, and I'm not really 100%
sure, but it certainly sounds likely, based on what little I
know of accademia.)

Most teams, of course, don't have anyone nearly that skilled,
and most projects today are significantly larger, as well, so
even if he did do it alone, that would be the exception that
confirms the rule.  But if it makes you happier, I'm willing to
modify my statement to the effect that "a single individual is
incapable of writing a correct program, unless he is at least as
skilled as Donald Knuth."  I still think my original wording is
more exact, but since I don't have any concrete experience
working with people as skilled as Knuth, I can't be 100% sure.

> 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. :-)

A far more sophisticated and powerful version, yes.  One which
starts from the correct philosophy: you write the documentation
first, and extract the code from it, rather than vice versa.

> However I've never seen the code.

I have.

The real problem is that it is still "source code".  TeX source
code, rather than Pascal source code, but the TeX markup is
there, embedded in the document.  It's still an order of
magnitude better than most other things I've seen (since the
markup isn't that invasive), and later adaptations seem to have
improved it even more, but you're still writing to be read at
two levels: a generated document (where the markup handles
sectionning and other details) and the actual document the
maintenance programmer sees (which contains markup, and whose
formatting depends on what you've entered directly, e.g. spaces,
new lines, etc.).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 17, 2:40 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> "Alf P. Steinbach" <al...@start.no> writes:

> > * James Kanze:

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

Which explains why so much of it is total junk.  There are a few
exceptions, like g++, but 1) they do have some sort of
management, and 2) they're only "good" compared with the
commercial equivalents, which often don't have any decent
management either.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jul 17, 11:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> James Kanze <james.ka...@gmail.com> writes:
>>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> James Kanze wrote:
>>>>> On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
>>>>> wrote:
> 
>     [...]
>>>>> 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.
> 
>>> 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.
> 
> Working along is a guarantee that they aren't implemented,
> however.
> 
>> Basically, you can do code reviews alone, by just forgetting
>> your code, and then reviewing it.
> 
> I do that too, when I have to work alone.  It's still far from
> being as effective as having other people do the review.
> 
> There's also all of the ad hoc discussions that occur (or should
> occur) when you're working in a team.  You discuss what you're
> doing with someone else at the coffee machine, and he points out
> a potential problem.  That you then fix, before formel review.
> 
>>> 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).
> 
> No doubt that's why all of the companies implementing critical
> systems insist on team programming, and why it is required in
> such cases.
> 
>> 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.
> 
> That's just bullshit.  Mostly, programmers are human beings, and
> as such, imperfect.  They all make mistakes.  And they don't see
> their own mistakes---that takes someone else.

There's a valid point in there to be fair - namely that if you decide 
you've gone down the wrong path with a system which you've written 
entirely yourself, you're generally more in a position to go back and 
rewrite it than you are if you're working in a team. In a team, you have 
to first convince all the other people working on the system that you've 
gone down the wrong path and that it's worth fixing.

It's not a question of whether programmers are perfect or otherwise -- 
clearly they're not. There can definitely be advantages to team working 
in terms of spotting mistakes, provided you go about it in a sensible 
way. None of this greatly impacts on the point just made however.

In terms of programmers not seeing their own mistakes -- I guess you 
could divide it up into unforced errors and forced errors, rather like 
in tennis. The forced errors (the ones you made because you lacked 
knowledge/understanding of the issues) are ones you probably won't spot 
yourself (unless your knowledge/understanding increases in the interim, 
or you happen across a similar issue whilst e.g. reading newsgroups, 
browsing the web, etc.) The unforced errors (the ones where you just did 
something silly which you should have spotted the first time) are ones 
you've got a reasonable chance of finding yourself.

>>> a single individual is incapable of writing a correct program,
>>> regardless of how skilled he is.
> 
>> This is obviously wrong, there are several example.
> 
> Such as?

Here's an example: suppose my spec says "write a program which is valid 
C++ but does absolutely nothing". My implementation looks like:

int main()
{
	return 0;
}

That's a correct program (although I look forward to somebody 
challenging that assertion :-)) which meets its specification. I'm a 
single individual, and I wrote it. Surely that makes the statement above 
false? We can change the terms of debate to "correct *non-trivial* 
program" if you like, but even then it's still doable to write some such 
program on your own (not every non-trivial program can be written 
correctly by an individual, evidently, but it suffices to demonstrate at 
least one such program).

>> 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".
> 
> Irrelevant here.  You're not adding additional people (beyond
> the optimal) in the middle of a project, to hopefully make the
> project go faster.

The Mythical Man Month had other stuff in it besides that. See e.g. p.78 
"Organization in the Large Programming Project":

"If there are n workers on a project, there are (n^2-n)/2 interfaces 
across which there may be communication, and there are potentially 
almost 2^n teams within which coordination must occur..."

Cheers,
Stu

> --
> James Kanze (GABI Software)             email:james.kanze@gmail.com
> 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

James Kanze wrote:
> On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> James Kanze wrote:
> 
>     [...]
>>>> 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?
> 
>> Alone.
> 
>>> If alone, how did you do code reviews, or brainstorming
>>> sessions.
> 
>> 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.

The code either pass or fails the tests.

>>> 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.
> 
> Testing can never prove correction; it can only prove that the
> code is incorrect.  

Correctness is in the eye of the beholder, in my case that's the client.

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

So should client - programmer.  This is more typical and important when 
there is a single client and a single implementer.

-- 
Ian Collins

On Jul 19, 9:55 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >>>> James Kanze wrote:

> >     [...]
> > 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.

> The code either pass or fails the tests.

Since you'll be writing the tests, that won't help me much.  And
I want the code not only to work, but to be maintainable.

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

> > Testing can never prove correction; it can only prove that the
> > code is incorrect.

> Correctness is in the eye of the beholder, in my case that's
> the client.

Yes, and no professionally competent organization will accept
code just because it passes some arbitrary set of tests.  It has
to be maintainable.

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

> So should client - programmer.  This is more typical and
> important when there is a single client and a single
> implementer.

In such cases, one could argue that the development isn't just
the implementer; that the implementer is in fact part of my in
house team.  In such cases, impromtu communication is important;
that's why I always work on the customer site.  I tried once
working at a distance, but quickly found that I was "out of the
loop".

Also, I don't pretend to fournish finished software in such
cases.  I'm part of the customer's team (except for tax and
labor law purposes).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Stuart Golodetz wrote:
> James Kanze wrote:
> > Pascal J. Bourguignon wrote:
> > > James Kanze wrote:
> > > > a single individual is incapable of writing a correct program,
> > > > regardless of how skilled he is.
>
> > > This is obviously wrong, there are several example.
>
> > Such as?
>
> Here's an example: suppose my spec says "write a program which is valid
> C++ but does absolutely nothing". My implementation looks like:
>
> int main()
> {
>         return 0;
>
> }
>
> That's a correct program (although I look forward to somebody
> challenging that assertion :-)) which meets its specification. I'm a
> single individual, and I wrote it. Surely that makes the statement above
> false? We can change the terms of debate to "correct *non-trivial*
> program" if you like

I think those are already the terms of an adult debate. In other
words this isn't 1st grade playground my dad can kick your dad's
ass a million gazillion times banter. So you might have known or
at least assumed upfront that James didn't mean nonsense trivial
"look what I can do" programs.

So, it would be nice to explore real world examples. Knuth's TeX
was brought up as a counter example.  However, people other than
Knuth found and reported (to Knuth) bugs in TeX. So I don't know
if TeX falls under James' definition of "correct" or not, and if
that 3rd party testing breaks "single individual" or not.

KHD

James Kanze wrote:
> On Jul 19, 9:55 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> James Kanze wrote:
>>>>> On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>>>>>> James Kanze wrote:
> 
>>>     [...]
>>> 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.
> 
>> The code either pass or fails the tests.
> 
> Since you'll be writing the tests, that won't help me much.  And
> I want the code not only to work, but to be maintainable.

The code either pass or fails the customer's tests.

>>> Testing can never prove correction; it can only prove that the
>>> code is incorrect.
> 
>> Correctness is in the eye of the beholder, in my case that's
>> the client.
> 
> Yes, and no professionally competent organization will accept
> code just because it passes some arbitrary set of tests.  It has
> to be maintainable.

Then there's a lot of professionally competent organisations out there!

In my case, I'm the one paid to maintain the code.  They pay for 
additions, I pay for bug fixing.  Which gives me the incentive to 
deliver what they want and make sure they test it.

-- 
Ian Collins

On Jul 19, 5:21=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
>
> > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> =A0 =A0 [...]
>
> > > > a single individual is incapable of writing a correct
> > > > program, regardless of how skilled he is.
> > It may help to recall how Noah and his three sons built the
> > ark. =A0In that case a single family worked out their salvation
> > while others were lost to the flood. =A0That 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.
>
> That family wasn't a single individual. =A0And in the version I
> heard, they had some significant outside help, especially with
> regards to design and management.
>

There were four men and they each had a wife.  They had as you
say a lot of "outside help".  Anyway, I bring it up as an
example of a large, successful project that involved a small
number of people.  I am not arguing against what you wrote,
but saying there's no reason to be afraid of joining a small
team that has a big project in front of them.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Jul 20, 9:16 am, Brian Wood <c...@mailvault.com> wrote:
> On Jul 19, 5:21 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:

> > > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > wrote:

> >     [...]

> > > > > a single individual is incapable of writing a correct
> > > > > program, regardless of how skilled he is.
> > > 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.

> > That family wasn't a single individual.  And in the version
> > I heard, they had some significant outside help, especially
> > with regards to design and management.

> There were four men and they each had a wife.  They had as you
> say a lot of "outside help".

Of a sort most software projects can't hope for.  (Most software
projects can't even hope for someone as skilled as Knuth, much
less an omniscient, infallible design specialist.)

> Anyway, I bring it up as an example of a large, successful
> project that involved a small number of people.  I am not
> arguing against what you wrote, but saying there's no reason
> to be afraid of joining a small team that has a big project in
> front of them.

I've never said anything against small teams.  In fact, it's
generally easier to establish the necessary communication in a
small team.  The ideal size of the team will vary, depending on
the size and complexity of the project, and the desired delay.
Optimizing for cost will *NOT* generally result in the shortest
delay, but you will run up against a limit fairly soon when
trying to shorten the delay which results in lowest cost.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 20, 7:00 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> Stuart Golodetz wrote:
> > James Kanze wrote:

> So, it would be nice to explore real world examples. Knuth's
> TeX was brought up as a counter example.  However, people
> other than Knuth found and reported (to Knuth) bugs in TeX. So
> I don't know if TeX falls under James' definition of "correct"
> or not, and if that 3rd party testing breaks "single
> individual" or not.

The real question is: what do we mean by "correct"?  There's a
very real sense that my statement is trivially correct: no
non-trivial program can be guaranteed 100% correct (without any
bugs), so obviously, no non-trivial program written by a single
person can be 100% correct.  That's just game playing, like
Stuarts example of a program which does nothing, but the
question remains: how many bugs to we accept?  And do we take
into consideration maintainability issues: how difficult is it
to correct the bugs once they are found?  (With regards to TeX,
at least seven bugs have been found and fixed since version 3.0
was released.  The source is around 40KLOC, so that's not a
particularly low bug rate.)

What I'd really be interesting in seeing is a real life example
of a real program written by a single person which is considered
correct, with a statement as to what is considered correct or
how it is known to be correct.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:

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

There's always an option, and everything is a trade-off... :)

Not everybody is in a metropolis, or in a densely populated, highly
developed area. It seems to be obvious that for any given specific skill
there are many places where it can't be found locally; not sure why
anybody would want to debate this. The cost of convincing someone with
the skill to move to where the skill is needed may be prohibitive.

This regularly puts people in the situation of having to decide between
a local, lesser qualified (for a particular job or situation) person and
a remote but better qualified person, and of having to calculate the
trade-off between the advantages of the immediate communication physical
presence brings and the advantages proper qualification (for this
particular job or situation) brings. This trade-off doesn't always swing
towards the immediate communication.

Gerhard

On Jul 20, 3:03=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 20, 9:16 am, Brian Wood <c...@mailvault.com> wrote:
>
>
>
>
>
> > On Jul 19, 5:21 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 17, 9:27 pm, Brian Wood <c...@mailvault.com> wrote:
> > > > On Jul 17, 4:35 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > =A0 =A0 [...]
> > > > > > a single individual is incapable of writing a correct
> > > > > > program, regardless of how skilled he is.
> > > > It may help to recall how Noah and his three sons built
> > > > the ark. =A0In that case a single family worked out their
> > > > salvation while others were lost to the flood. =A0That
> > > > 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.
> > > That family wasn't a single individual. =A0And in the version
> > > I heard, they had some significant outside help, especially
> > > with regards to design and management.
> > There were four men and they each had a wife. =A0They had as you
> > say a lot of "outside help".
>
> Of a sort most software projects can't hope for. =A0(Most software
> projects can't even hope for someone as skilled as Knuth, much
> less an omniscient, infallible design specialist.)

I disagree.  G-d wants to help people and still does so.
More recently, there's David and Goliath.  David killed
Goliath even though Goliath was more experienced and
was much bigger physically than David.
If you said, most software projects don't even hope for
someone as skilled as Knuth, much less ..., I'd be more
inclined to agree.  But there's something wrong with that.
How could a software project hope for anything?  I'll assume
you're not playing some sort of word game.


>
> I've never said anything against small teams. =A0In fact, it's
> generally easier to establish the necessary communication in a
> small team. =A0The ideal size of the team will vary, depending on
> the size and complexity of the project, and the desired delay.
> Optimizing for cost will *NOT* generally result in the shortest
> delay, but you will run up against a limit fairly soon when
> trying to shorten the delay which results in lowest cost.
>

Are you saying there's an organic aspect to projects that
should be considered?


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

Keith H Duggar wrote:

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

An important aspect of "clear" specs is that they must be clear to both
parties :) This basically means that the level of detail depends on the
person doing the job. For some, a high-level description is good enough,
because you can trust that they either know what to do, or know when
they don't know -- and go out themselves and efficiently get that
information, as well as you could do it. For others, you need to be more
specific. 

It's important to get a feel for this level. Too detailed, and people
feel micromanaged and may get demotivated. Too coarse, and people feel
(or are) lost -- and may get demotivated just the same :)

Ideally the level is so that the person is pround that she managed to
complete it, and what she did is so that you can say "great job!"

Gerhard

On Jul 15, 5:04 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Noah Roberts <roberts.n...@gmail.com> writes:
> > Here's another big issue.  We're not in an area that holds a lot of
> > programmers.
>
> Hey look, it's your lucky day!
>
> Computer geeks invented something to solve your problem, it's called
> "The Internet".
>
> With "The Internet", you can send specifications to highly qualified
> programmers located elsewhere, and get back good quality code along
> with an invoice.  You pay the invoice and you may send back
> specification patches, to get program patches.

Can you please recommend a few websites or other resources that you
find most helpful for finding and utilizing quality developers over
the Internet? Thanks!

KHD

Keith H Duggar wrote:
> On Jul 15, 5:04 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Noah Roberts <roberts.n...@gmail.com> writes:
>>> Here's another big issue.  We're not in an area that holds a lot of
>>> programmers.
>> Hey look, it's your lucky day!
>>
>> Computer geeks invented something to solve your problem, it's called
>> "The Internet".
>>
>> With "The Internet", you can send specifications to highly qualified
>> programmers located elsewhere, and get back good quality code along
>> with an invoice.  You pay the invoice and you may send back
>> specification patches, to get program patches.
> 
> Can you please recommend a few websites or other resources that you
> find most helpful for finding and utilizing quality developers over
> the Internet? Thanks!

rentacoder.com :P

Brian Wood wrote:

> There were four men and they each had a wife.  They had as you
> say a lot of "outside help".  Anyway, I bring it up as an
> example of a large, successful project that involved a small
> number of people.  I am not arguing against what you wrote,
> but saying there's no reason to be afraid of joining a small
> team that has a big project in front of them.

A large, impossible project.  I for one think fairy tale solutions to 
real world problems is PART of the problem in the software industry.

I gather you believe it, and you're free to do so, but for those of us 
who can't depend on miracles and a god's personal intervention (come on, 
even you must admit that the lumber alone would have taken 4 people a 
decade to produce) need to concentrate on methods that don't involve 
divine boogiemen.

Brian Wood wrote:

> I disagree.  G-d wants to help people and still does so.

Is there any conversation in which people won't attempt to prostheletize?

On Jul 21, 1:00=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Brian Wood wrote:
> > I disagree. =A0G-d wants to help people and still does so.
>
> Is there any conversation in which people won't attempt to prostheletize?


In the United States the national motto is: In G-d we trust.
I believe G-d has been and is leading me with Ebenezer
Enterprises.  With many companies failing, I suggest to them
the same help I've got.  He doesn't charge anything for his
help.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net


"Unless the L-RD builds the house, they labor in vain
that build it; unless the L-RD keeps the city, the
watchman waketh but in vain."   Psalm 127:1

Brian Wood wrote:
> On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> Brian Wood wrote:
>>> I disagree.  G-d wants to help people and still does so.
>> Is there any conversation in which people won't attempt to prostheletize?
> 
> 
> In the United States the national motto is: In G-d we trust.

Rewriting/forgetting US history is not a valid excuse for rudely 
intruding in a reasonable conversation about important issues with your 
religiously led need to convert everyone to your way of thinking.  You 
can be happy with what one group of lawmakers decided--nearly 200 years 
after the formation of the country--to be our national motto (replacing 
the original) but it's completely beside the point in professional 
conversations (unless of course your profession is religion).

Many of us recognize the fact that cultures go through phases and in the 
1950's this country was under the influence of a religious fervor and 
fear of "The Communists".  A lot of mistakes were made and a lot of 
"god" injected where he didn't belong.

> I believe G-d has been and is leading me with Ebenezer
> Enterprises.

You're free to think whatever you want.  I'll definitely add you to the 
list of companies to run away from should I find our paths crossing. 
You may as well be sacrificing chickens at your management meetings or 
following the newspaper horrorscope.  I'll stick to professionals, thanks.

E pluribus unum

On Jul 21, 4:08=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Brian Wood wrote:
> > On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> >> Brian Wood wrote:
> >>> I disagree. =A0G-d wants to help people and still does so.
> >> Is there any conversation in which people won't attempt to prostheleti=
ze?
>
> > In the United States the national motto is: In G-d we trust.
>
> Rewriting/forgetting US history is not a valid excuse for rudely

I'm not rewriting history.  I didn't say that we never had another
national motto.  If I recall correctly at one time the national
motto was:  Mind your own business.


> Many of us recognize the fact that cultures go through phases and in the
> 1950's this country was under the influence of a religious fervor and
> fear of "The Communists". =A0A lot of mistakes were made and a lot of
> "god" injected where he didn't belong.
>

Some mistakes were made, but making "in G-d we trust" our motto wasn't
a mistake.  "Mind your own business" was a fine motto also.


> > I believe G-d has been and is leading me with Ebenezer
> > Enterprises.
>
> You're free to think whatever you want. =A0I'll definitely add you to the
> list of companies to run away from should I find our paths crossing.
> You may as well be sacrificing chickens at your management meetings or
> following the newspaper horrorscope. =A0I'll stick to professionals, than=
ks.
>
> E pluribus unum

There's nothing wrong with that saying.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

Brian Wood wrote:
> On Jul 21, 4:08 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> Brian Wood wrote:
>>> On Jul 21, 1:00 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>>>> Brian Wood wrote:
>>>>> I disagree.  G-d wants to help people and still does so.
>>>> Is there any conversation in which people won't attempt to prostheletize?
>>> In the United States the national motto is: In G-d we trust.
>> Rewriting/forgetting US history is not a valid excuse for rudely
> 
> Mind your own business.

Next time you feel the need to prostheletize in a professional 
conversation you might take this bit of advice.  I'll leave you to your 
business, but when you shove it in my face (quite rudely I might add) I 
will respond.

Noah Roberts wrote:
> The problem is that I'm having an incredibly hard time communicating 
> what I need to communicate to the developers on my team.

Doesn't ALL of this really resolve to understanding the "Control Loop" 
described in management texts. Did you cover this in college? Have they 
stopped teaching this in college?

An old college book I have:
"Management" by James A.F. Stoner - Prentice-Hall, ISBN: 0-13-549303-X 
(Gotta' appreciate the guys name.) :-) *Chapter 21, The Control 
Process.* More chapters follow about "control."

Everyone generally freaks out when they see management and control in 
the same sentence, but as usual, this tool can be used for Good or Evil.

If done correctly I would really call this a "human feedback loop." To 
borrow from Control Theory, instead of HIL (hardware in the loop) or SIL 
(software in the loop), think of it as "Human in the Loop" and act 
accordingly.

A human "control loop" is kinda' like a programmatic control loop. 
Except we have weird (hey, they're programmers right), complicated, 
irrational "hu-mans" running around instead of - in comparison - nice 
orderly electrons.

Just a thought.

The philosophy exam was a piece of cake which was a
bit of a surprise, actually, because I was expecting
some questions on a sheet of paper.

Andrew Tomazos wrote:
> On Jul 15, 11:04 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> With "The Internet", you can send specifications to highly qualified
>> programmers located elsewhere, and get back good quality code along
>> with an invoice.
> 
> 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.  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.
>   -Andrew.

So I guess Rent-A-Coder (search web for info) doesn't exist then? And 
managing teams of programmers in India is right-out then!

Yeah now I get it, the year I spent �talking to some guys in India� was 
a year spend in a dream world. Thanks, I always wondered about that.

"A wise man adapts himself to circumstances as water shapes itself to 
the vessel that contains it." - Chinese Proverb

James Kanze wrote:
> What I'd really be interesting in seeing is a real life example
> of a real program written by a single person which is considered
> correct, with a statement as to what is considered correct or
> how it is known to be correct.

Bjarne Stroustrup developing a "program" (note the quotes) called C++?

Linus Torvalds creating the Linux kernel?

And just for fun: Paul Allen creating GW-Basic. Bwha! (See if you can 
find Waldo in that one.) :-)

Enjoy.

JustBoo wrote:
> So I guess Rent-A-Coder (search web for info) doesn't exist then?

LOL!  I said rentacoder.com as a joke!  Have you actually been there?

Probably 90%, or more even, of the projects are, "I need my homework 
project written."

Highest bid I see in there currently is 1500, but having spent time 
trying to find worthy projects I can say that's very rare.  Most are max 
bid < 100.

SoftwareXChange was a better attempt.  There were actually some real 
professionals and some real projects being bid upon.  That site fell 
through though and doesn't exist anymore.

Noah Roberts wrote:
> JustBoo wrote:
>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
> 
> LOL!  I said rentacoder.com as a joke!  Have you actually been there?
> 
> Probably 90%, or more even, of the projects are, "I need my homework 
> project written."
> 
> Highest bid I see in there currently is 1500, but having spent time 
> trying to find worthy projects I can say that's very rare.  Most are max 
> bid < 100.
> 
> SoftwareXChange was a better attempt.  There were actually some real 
> professionals and some real projects being bid upon.  That site fell 
> through though and doesn't exist anymore.

LOL. And your point is?

My point is that a system exists and has for years, whereby remote work 
is performed and completed via the internet. If it didn't work, then it 
would go the way of the flopped site you mention.

JustBoo wrote:
> Noah Roberts wrote:
>> JustBoo wrote:
>>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
>>
>> LOL!  I said rentacoder.com as a joke!  Have you actually been there?
>>
>> Probably 90%, or more even, of the projects are, "I need my homework 
>> project written."
>>
>> Highest bid I see in there currently is 1500, but having spent time 
>> trying to find worthy projects I can say that's very rare.  Most are 
>> max bid < 100.
>>
>> SoftwareXChange was a better attempt.  There were actually some real 
>> professionals and some real projects being bid upon.  That site fell 
>> through though and doesn't exist anymore.
> 
> LOL. And your point is?
> 
> My point is that a system exists and has for years, whereby remote work 
> is performed and completed via the internet. If it didn't work, then it 
> would go the way of the flopped site you mention.

I think maybe you're missing the point.

The rentacoder model is not an example of managing teams of remote 
developers.  The rentacoder model is an example of independent 
consultants implementing projects for customers.

Customer X needs his homework done.  Consultant Y places a bid.  When 
the bid is won they gather requirements and does Customer X's homework.

It's not about hiring a developer to work on a project and managing that 
project.  It's about hiring a development "firm" to implement and manage 
the project for you.

Furthermore, the projects at rentacoder for the most part are not worthy 
to compare with a real world project.  Doing someone's homework for them 
is not the same thing as writing a large scale commercial product and 
the kind of expertise you need for the two are vastly different.

Noah Roberts wrote:
> JustBoo wrote:
>> Noah Roberts wrote:
>>> JustBoo wrote:
>>>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
>>>
>>> LOL!  I said rentacoder.com as a joke!  Have you actually been there?

snippy all around.

>> LOL. And your point is?
> 
> I think maybe you're missing the point.
> 
> The rentacoder model is not an example of managing teams of remote 

Oh, I remember you now. Never actually reads what people post and hopes 
a response with a flurry of words will throw everyone off, and make 
yourself feel like you've "won." Remembering that... your topic and its 
subject matter makes perfect sense.

Good Luck to you sir, you'll need it.

On 07/23/2009 12:50 AM, Noah Roberts wrote:
> JustBoo wrote:
>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
> 
> LOL!  I said rentacoder.com as a joke!  Have you actually been there?
> 
> Probably 90%, or more even, of the projects are, "I need my homework
> project written."
> 
> Highest bid I see in there currently is 1500, but having spent time
> trying to find worthy projects I can say that's very rare.  Most are max
> bid < 100.
> 
> SoftwareXChange was a better attempt.  There were actually some real
> professionals and some real projects being bid upon.  That site fell
> through though and doesn't exist anymore.

How about SourceForge.net? I think, one can find and, or invite Hundreds
of thousands of C/C++ and, or other programmers there. Moreover, one can
easily review contributions, patches and, or other project work (mostly
available online) of these volunteer programmers

-- 
Balwinder S "bdheeman" Dheeman        Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/      Visit: http://counter.li.org/

JustBoo wrote:
> Noah Roberts wrote:
>> JustBoo wrote:
>>> Noah Roberts wrote:
>>>> JustBoo wrote:
>>>>> So I guess Rent-A-Coder (search web for info) doesn't exist then?
>>>>
>>>> LOL!  I said rentacoder.com as a joke!  Have you actually been there?
> 
> snippy all around.
> 
>>> LOL. And your point is?
>>
>> I think maybe you're missing the point.
>>
>> The rentacoder model is not an example of managing teams of remote 
> 
> Oh, I remember you now. Never actually reads what people post and hopes 
> a response with a flurry of words will throw everyone off, and make 
> yourself feel like you've "won." Remembering that... your topic and its 
> subject matter makes perfect sense.
> 
> Good Luck to you sir, you'll need it.

lol, ok.

On Jul 9, 11:38=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
> ...

Good programmers are 100x more productive than average ones,
especially on hard problems, as I'm sure you know.

If you've been working only with good ones so far, welcome to reality!
Also, bad hiring practices can lead to teams that are 100% idiots. No
amount of "process" will fix that.

Btw, if you want some leadership ideas, watch "Generation Kill".

On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
> On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:

> > ...

> Good programmers are 100x more productive than average ones,
> especially on hard problems, as I'm sure you know.

"Average" programmers (whatever that means) are good
programmers.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 23, 2:24=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > ...
> > Good programmers are 100x more productive than average ones,
> > especially on hard problems, as I'm sure you know.
>
> "Average" programmers (whatever that means) are good
> programmers.
>

I should have said "median". Because of the long tail in the
productivity distribution, "average" are indeed "good", or at least
"half as good". The point is the productivity difference between a
regular programmer and someone in the top 10% or so can be 2 orders of
magnitude.

On Jul 23, 4:24=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > ...
> > Good programmers are 100x more productive than average ones,
> > especially on hard problems, as I'm sure you know.
>
> "Average" programmers (whatever that means) are good
> programmers.
>

This reminds me of something from Prarie Home Companion.
They say that all the children in Lake Wobegone are above
average.  I wonder if Garrison has ever thought of asking
Stroustrup to be on the program.  He could quiz Stroustrup
about programming and take some pot shots at other languages.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Jul 23, 7:05 pm, fft1976 <fft1...@gmail.com> wrote:
> On Jul 23, 2:24 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:

> > > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > > ...
> > > Good programmers are 100x more productive than average
> > > ones, especially on hard problems, as I'm sure you know.

> > "Average" programmers (whatever that means) are good
> > programmers.

> I should have said "median". Because of the long tail in the
> productivity distribution, "average" are indeed "good", or at
> least "half as good". The point is the productivity difference
> between a regular programmer and someone in the top 10% or so
> can be 2 orders of magnitude.

Not really.  Not in terms of code, anyway, and not in a well
managed environment.  If the environment is correctly managed,
in fact, the one or two programmers you have in the top 10% may
actually produce less code, because most of their time will be
used improving the productivity of the other programmers.  (And
what makes a programmer "exceptional", or in the top 10%, is the
fact that his presence improves the productivity of everyone
else on the team.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

In article <GRI9m.54005$9P.45791@newsfe08.iad>,
JustBoo  <Boo@boowho.com> wrote:
>James Kanze wrote:
>> What I'd really be interesting in seeing is a real life example
>> of a real program written by a single person which is considered
>> correct, with a statement as to what is considered correct or
>> how it is known to be correct.
>
>Bjarne Stroustrup developing a "program" (note the quotes) called C++?

I don't think he was alone at it although he was the main author for
the original version.  Then a lot of peoples tried it and suggested
improvements to it... and now we are at C++0x...

>Linus Torvalds creating the Linux kernel?

Torvalds took inspiration from UNIX.  He initially wrote what we
should call an alpha version of a kernel and it certainly was not
correct as in totally bug-free.  The several additional contributors
help improve Torvalds early work.  

>And just for fun: Paul Allen creating GW-Basic. Bwha! (See if you can 
>find Waldo in that one.) :-)
>
>Enjoy.

Yannick Tremblay wrote:
> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
> JustBoo  <Boo@boowho.com> wrote:
>> James Kanze wrote:
>>> What I'd really be interesting in seeing is a real life example
>>> of a real program written by a single person which is considered
>>> correct, with a statement as to what is considered correct or
>>> how it is known to be correct.
>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
> 
> I don't think he was alone at it although he was the main author for
> the original version.  Then a lot of peoples tried it and suggested
> improvements to it... and now we are at C++0x...

 From what I've read, in the beginning and well into the development, he 
was alone. Remember all this was new. What's that old saying (probably 
paraphrasing here): "Failure is an orphan, where success has many 
fathers." It has many fathers *now*. Back then C++ was not a certain 
success.

But I�m not �picking this hill to die on.�  Take care.

On Jul 24, 12:54=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 23, 7:05 pm, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 23, 2:24 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
> > > > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > > > ...
> > > > Good programmers are 100x more productive than average
> > > > ones, especially on hard problems, as I'm sure you know.
> > > "Average" programmers (whatever that means) are good
> > > programmers.
> > I should have said "median". Because of the long tail in the
> > productivity distribution, "average" are indeed "good", or at
> > least "half as good". The point is the productivity difference
> > between a regular programmer and someone in the top 10% or so
> > can be 2 orders of magnitude.
>
> Not really. =A0Not in terms of code, anyway, and not in a well
> managed environment. =A0If the environment is correctly managed,
> in fact, the one or two programmers you have in the top 10% may
> actually produce less code, because most of their time will be
> used improving the productivity of the other programmers. =A0(And
> what makes a programmer "exceptional", or in the top 10%, is the
> fact that his presence improves the productivity of everyone
> else on the team.)
>

Maybe you've never worked with anyone good or on problems where being
good mattered?

Yannick Tremblay wrote:
> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
> JustBoo  <Boo@boowho.com> wrote:
>> James Kanze wrote:
>>> What I'd really be interesting in seeing is a real life example
>>> of a real program written by a single person which is considered
>>> correct, with a statement as to what is considered correct or
>>> how it is known to be correct.
>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
> 
> I don't think he was alone at it although he was the main author for
> the original version.  Then a lot of peoples tried it and suggested
> improvements to it... and now we are at C++0x...

C++1x you mean :P

Noah Roberts wrote:
> Yannick Tremblay wrote:
>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>> JustBoo  <Boo@boowho.com> wrote:
>>> James Kanze wrote:
>>>> What I'd really be interesting in seeing is a real life example
>>>> of a real program written by a single person which is considered
>>>> correct, with a statement as to what is considered correct or
>>>> how it is known to be correct.
>>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>>
>> I don't think he was alone at it although he was the main author for
>> the original version.  Then a lot of peoples tried it and suggested
>> improvements to it... and now we are at C++0x...
> 
> C++1x you mean :P

No, C++0x. C++1x is at least five years out.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

Pete Becker wrote:
> Noah Roberts wrote:
>> Yannick Tremblay wrote:
>>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>>> JustBoo  <Boo@boowho.com> wrote:
>>>> James Kanze wrote:
>>>>> What I'd really be interesting in seeing is a real life example
>>>>> of a real program written by a single person which is considered
>>>>> correct, with a statement as to what is considered correct or
>>>>> how it is known to be correct.
>>>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>>>
>>> I don't think he was alone at it although he was the main author for
>>> the original version.  Then a lot of peoples tried it and suggested
>>> improvements to it... and now we are at C++0x...
>>
>> C++1x you mean :P
> 
> No, C++0x. C++1x is at least five years out.

Do you expect C++0x to be ratified this year?

-- 
Ian Collins

Ian Collins wrote:
> Pete Becker wrote:
>> Noah Roberts wrote:
>>> Yannick Tremblay wrote:
>>>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>>>> JustBoo  <Boo@boowho.com> wrote:
>>>>> James Kanze wrote:
>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>> of a real program written by a single person which is considered
>>>>>> correct, with a statement as to what is considered correct or
>>>>>> how it is known to be correct.
>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called C++?
>>>>
>>>> I don't think he was alone at it although he was the main author for
>>>> the original version.  Then a lot of peoples tried it and suggested
>>>> improvements to it... and now we are at C++0x...
>>>
>>> C++1x you mean :P
>>
>> No, C++0x. C++1x is at least five years out.
> 
> Do you expect C++0x to be ratified this year?
> 

Next year.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

Pete Becker wrote:
> Ian Collins wrote:
>> Pete Becker wrote:
>>> Noah Roberts wrote:
>>>> Yannick Tremblay wrote:
>>>>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>>>>> JustBoo  <Boo@boowho.com> wrote:
>>>>>> James Kanze wrote:
>>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>>> of a real program written by a single person which is considered
>>>>>>> correct, with a statement as to what is considered correct or
>>>>>>> how it is known to be correct.
>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called 
>>>>>> C++?
>>>>>
>>>>> I don't think he was alone at it although he was the main author for
>>>>> the original version.  Then a lot of peoples tried it and suggested
>>>>> improvements to it... and now we are at C++0x...
>>>>
>>>> C++1x you mean :P
>>>
>>> No, C++0x. C++1x is at least five years out.
>>
>> Do you expect C++0x to be ratified this year?
>>
> 
> Next year.
> 
Ah, so x = 10!

-- 
Ian Collins

On Jul 24, 8:23 pm, fft1976 <fft1...@gmail.com> wrote:
> On Jul 24, 12:54 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jul 23, 7:05 pm, fft1976 <fft1...@gmail.com> wrote:

> > > On Jul 23, 2:24 am, James Kanze <james.ka...@gmail.com> wrote:
> > > > On Jul 23, 9:01 am, fft1976 <fft1...@gmail.com> wrote:
> > > > > On Jul 9, 11:38 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > > > > ...
> > > > > Good programmers are 100x more productive than average
> > > > > ones, especially on hard problems, as I'm sure you know.
> > > > "Average" programmers (whatever that means) are good
> > > > programmers.
> > > I should have said "median". Because of the long tail in
> > > the productivity distribution, "average" are indeed
> > > "good", or at least "half as good". The point is the
> > > productivity difference between a regular programmer and
> > > someone in the top 10% or so can be 2 orders of magnitude.

> > Not really.  Not in terms of code, anyway, and not in a well
> > managed environment.  If the environment is correctly
> > managed, in fact, the one or two programmers you have in the
> > top 10% may actually produce less code, because most of
> > their time will be used improving the productivity of the
> > other programmers.  (And what makes a programmer
> > "exceptional", or in the top 10%, is the fact that his
> > presence improves the productivity of everyone else on the
> > team.)

> Maybe you've never worked with anyone good or on problems
> where being good mattered?

I've worked on critical systems, where everything had to work.
I've worked with a lot of good people, and some exceptional
ones.

More likely you've never worked in an environment designed to
produce good software.  More likely you don't know how to judge
good.  Although I've seen a few exceptions, most professional
programmers are competent, and the cases I've seen where they're
not productive, it's been because management has prevented them
from being productive.  Sometimes, simply by letting a few
snotty brats who think that they're the only ones who know
anything run things.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

> 
> More likely you've never worked in an environment designed to
> produce good software.  More likely you don't know how to judge
> good.  Although I've seen a few exceptions, most professional
> programmers are competent, and the cases I've seen where they're
> not productive, it's been because management has prevented them
> from being productive.  Sometimes, simply by letting a few
> snotty brats who think that they're the only ones who know
> anything run things.

Or marketing types who think they know how to develop software!

I think more professional programmers succeed despite rather than 
because of their management.

-- 
Ian Collins

Ian Collins wrote:
> Pete Becker wrote:
>> Ian Collins wrote:
>>> Pete Becker wrote:
>>>> Noah Roberts wrote:
>>>>> Yannick Tremblay wrote:
>>>>>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>>>>>> JustBoo  <Boo@boowho.com> wrote:
>>>>>>> James Kanze wrote:
>>>>>>>> What I'd really be interesting in seeing is a real life
>>>>>>>> example of a real program written by a single person which
>>>>>>>> is considered correct, with a statement as to what is
>>>>>>>> considered correct or how it is known to be correct.
>>>>>>> Bjarne Stroustrup developing a "program" (note the quotes)
>>>>>>> called C++?
>>>>>>
>>>>>> I don't think he was alone at it although he was the main
>>>>>> author for the original version.  Then a lot of peoples tried
>>>>>> it and suggested improvements to it... and now we are at
>>>>>> C++0x...
>>>>>
>>>>> C++1x you mean :P
>>>>
>>>> No, C++0x. C++1x is at least five years out.
>>>
>>> Do you expect C++0x to be ratified this year?
>>>
>>
>> Next year.
>>
> Ah, so x = 10!

See, you solved the equation.  :-)

Seriously, there are already some work in progress for the real 
C++1x - originally aiming at C++15. We will have to see if we get 0xA 
or 0xB, before we know if C++15 is possible. I believe ISO wants a 
minimum of 5 years between revisions (not a problem so far :-).


Bo Persson

Ian Collins wrote:
> Pete Becker wrote:
>> Ian Collins wrote:
>>> Pete Becker wrote:
>>>> Noah Roberts wrote:
>>>>> Yannick Tremblay wrote:
>>>>>> In article <GRI9m.54005$9P.45791@newsfe08.iad>,
>>>>>> JustBoo  <Boo@boowho.com> wrote:
>>>>>>> James Kanze wrote:
>>>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>>>> of a real program written by a single person which is considered
>>>>>>>> correct, with a statement as to what is considered correct or
>>>>>>>> how it is known to be correct.
>>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called 
>>>>>>> C++?
>>>>>>
>>>>>> I don't think he was alone at it although he was the main author for
>>>>>> the original version.  Then a lot of peoples tried it and suggested
>>>>>> improvements to it... and now we are at C++0x...
>>>>>
>>>>> C++1x you mean :P
>>>>
>>>> No, C++0x. C++1x is at least five years out.
>>>
>>> Do you expect C++0x to be ratified this year?
>>>
>>
>> Next year.
>>
> Ah, so x = 10!
> 

Yup. It's still the project that started in 2003. The name hasn't been 
changed.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

On Jul 25, 3:34=A0am, Ian Collins <ian-n...@hotmail.com> wrote:
> > More likely you've never worked in an environment designed to
> > produce good software. =A0More likely you don't know how to judge
> > good. =A0Although I've seen a few exceptions, most professional
> > programmers are competent, and the cases I've seen where they're
> > not productive, it's been because management has prevented them
> > from being productive. =A0Sometimes, simply by letting a few
> > snotty brats who think that they're the only ones who know
> > anything run things.
>
> Or marketing types who think they know how to develop software!
>
> I think more professional programmers succeed despite rather than
> because of their management.
>

One reason I started a company was to get away from the
groupthink/immaturity that is pervasive in companies today.
I read the hand writing on the wall in the 1990s and didn't
feel I had a choice.  The company was born out of necessity
more than than it being a goal of some sort.  Now I view it
as a move parallel to the pilgrims who left Europe on the
Mayflower and some other ships.  They didn't have it easy,
but they were successful in producing humbler management
for themselves in America.  That worked for awhile, but
lately we've not been getting much out of our "leaders."


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Jul 25, 3:05=A0pm, Brian Wood <c...@mailvault.com> wrote:
>
> One reason I started a company was to get away from the
> groupthink/immaturity that is pervasive in companies today.
> I read the hand writing on the wall in the 1990s and didn't
> feel I had a choice. =A0The company was born out of necessity
> more than than it being a goal of some sort. =A0Now I view it
> as a move parallel to the pilgrims who left Europe on the
> Mayflower and some other ships. =A0They didn't have it easy,
> but they were successful in producing humbler management
> for themselves in America. =A0That worked for awhile, but
> lately we've not been getting much out of our "leaders."
>


Here's a few headlines from July 25, 2009
http://wnd.com

Analyst says Obama will change healthcare plan
'The president hates one thing more than anything else =96 losing'

GOP not allowed to say 'government-run health care'
Communications with constituents that use phrase lose franking
privilege


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> > More likely you've never worked in an environment designed
> > to produce good software.  More likely you don't know how to
> > judge good.  Although I've seen a few exceptions, most
> > professional programmers are competent, and the cases I've
> > seen where they're not productive, it's been because
> > management has prevented them from being productive.
> > Sometimes, simply by letting a few snotty brats who think
> > that they're the only ones who know anything run things.

> Or marketing types who think they know how to develop software!

> I think more professional programmers succeed despite rather
> than because of their management.

I don't think a professional programmer can succeed without good
management, regardless of how good he is.  Programming is a team
effort---one person, working alone, cannot produce good code.
And it takes management to organize the team.  (Note that in
some cases, particularly in smaller projects or organizations,
the "manager" may also be part of the team.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> More likely you've never worked in an environment designed
>>> to produce good software.  More likely you don't know how to
>>> judge good.  Although I've seen a few exceptions, most
>>> professional programmers are competent, and the cases I've
>>> seen where they're not productive, it's been because
>>> management has prevented them from being productive.
>>> Sometimes, simply by letting a few snotty brats who think
>>> that they're the only ones who know anything run things.
> 
>> Or marketing types who think they know how to develop software!
> 
>> I think more professional programmers succeed despite rather
>> than because of their management.
> 
> I don't think a professional programmer can succeed without good
> management, regardless of how good he is.  Programming is a team
> effort---one person, working alone, cannot produce good code.

I still find that statement rather offensive.  I done a lot of solo 
projects for several clients in various corners of the globe over the 
past decade and I've produced plenty of what I still consider to be very 
good code.

> And it takes management to organize the team.  (Note that in
> some cases, particularly in smaller projects or organizations,
> the "manager" may also be part of the team.)

Team management is often excellent, it's those who climb higher up the 
greasy pole who loose the plot.

-- 
Ian Collins

On Jul 9, 2:38 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> 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.

If you are new to managing, right now you are being tested by your
subordinates. If someone is not doing what you say ask why they
didn't. But their are many ways to ask this question. The attitude you
broadcast will be returned three times fold.
How are your communication skills? Do you listen to what your are
saying to others? Communication is key. If you walk in others shoes
you will climb mountains.
Obviously you have been managed before,
Who were your best managers and who were your worst?
Which managers made you feel appreciated?
What qualities did they possess to accomplish this feeling of
appreciation?
Do you still talk to these managers?
How is your attitude?
Are you humble and appreciative or demanding and condescending?

Is their a common activity that you can do as a group. Make a game
night or something to that effect.

In message 
<827d8b9d-ef49-4490-831d-01116a0a9bff@g6g2000vbr.googlegroups.com>, 
Brian Wood <coal@mailvault.com> writes
>On Jul 25, 3:05 pm, Brian Wood <c...@mailvault.com> wrote:
>>
>> One reason I started a company was to get away from the
>> groupthink/immaturity that is pervasive in companies today.
>> I read the hand writing on the wall in the 1990s and didn't
>> feel I had a choice.  The company was born out of necessity
>> more than than it being a goal of some sort.  Now I view it
>> as a move parallel to the pilgrims who left Europe on the
>> Mayflower and some other ships.  They didn't have it easy,
>> but they were successful in producing humbler management
>> for themselves in America.  That worked for awhile, but
>> lately we've not been getting much out of our "leaders."
>>
>
>
>Here's a few headlines from July 25, 2009
>http://wnd.com
>
>Analyst says Obama will change healthcare plan
>'The president hates one thing more than anything else – losing'
>
>GOP not allowed to say 'government-run health care'
>Communications with constituents that use phrase lose franking
>privilege
>

Did you have a question about C++?

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

-- 
Richard Herring

On Jul 26, 9:44=A0am, James Kanze <james.ka...@gmail.com> wrote:
> I don't think a professional programmer can succeed without good
> management, regardless of how good he is. =A0Programming is a team
> effort---one person, working alone, cannot produce good code.

That is completely incorrect.  I have personally seen a 400k line
codebase that was written largely by one person that was (and maybe
its latest versions still is) used by nearly a million people with
minimal marketing.  The programmer had never heard of version control
and thumbed his nose at object-oriented programming.  There are
countless examples of great pieces of software written by one person.
Programming does not have to be a team effort, anymore than writing a
book needs to be a team effort.
  -Andrew.

On Jul 26, 9:58 am, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >>> More likely you've never worked in an environment designed
> >>> to produce good software.  More likely you don't know how
> >>> to judge good.  Although I've seen a few exceptions, most
> >>> professional programmers are competent, and the cases I've
> >>> seen where they're not productive, it's been because
> >>> management has prevented them from being productive.
> >>> Sometimes, simply by letting a few snotty brats who think
> >>> that they're the only ones who know anything run things.

> >> Or marketing types who think they know how to develop software!

> >> I think more professional programmers succeed despite rather
> >> than because of their management.

> > I don't think a professional programmer can succeed without
> > good management, regardless of how good he is.  Programming
> > is a team effort---one person, working alone, cannot produce
> > good code.

> I still find that statement rather offensive.  I done a lot of
> solo projects for several clients in various corners of the
> globe over the past decade and I've produced plenty of what I
> still consider to be very good code.

It's not offensive, it's a fact of life.  I've done a lot of
solo work in the past, as well.  Before the importance of
teamwork was fully recognized everywhere.  At the time, I
considered the code "very good".  And it was, compared to, say,
what other people working alone were producing.  But in the last
large project I did that way, the integration and test team
still found four errors.  For about 40 KLOC---that's one error
per 10 thousand lines of code.  Where as I've seen programmers
who I'd consider considerably less skilled than I produce code
with only one error per 100 KLOC, thanks to things like code
review and such.  Today, I simply cannot meet the standards I
set for myself (and others) without help from others.

> > And it takes management to organize the team.  (Note that in
> > some cases, particularly in smaller projects or organizations,
> > the "manager" may also be part of the team.)

> Team management is often excellent, it's those who climb
> higher up the greasy pole who loose the plot.

I've seen that, too.  One of the reasons smaller organizations
are often more successful than larger ones is that "management"
always wears several hats, including some which involve
programming as well, and so don't loose touch with reality.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 27, 2:23 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 26, 9:44 am, James Kanze <james.ka...@gmail.com> wrote:

> > I don't think a professional programmer can succeed without
> > good management, regardless of how good he is.  Programming
> > is a team effort---one person, working alone, cannot produce
> > good code.

> That is completely incorrect.

I'm sorry, but it's a proven fact.

> I have personally seen a 400k line codebase that was written
> largely by one person that was (and maybe its latest versions
> still is) used by nearly a million people with minimal
> marketing.

And?  A lot of people are using a lot of junk.  Note that
working in a team is a necessary condition, but not necessarily
a sufficient one.  A lot of junk has been produced by large
teams as well.  And the fact that a large number of people use
something is no proof of quality---consider Windows for example
(or Linux---but there are a lot less people using it).

> The programmer had never heard of version control and thumbed
> his nose at object-oriented programming.  There are countless
> examples of great pieces of software written by one person.

For example?

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 27, 4:03=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> > I have personally seen a 400k line codebase that was written
> > largely by one person that was (and maybe its latest versions
> > still is) used by nearly a million people with minimal
> > marketing.
>
> And? =A0A lot of people are using a lot of junk.

The software in question won numerous high profile awards in the face
of competition, and people described themselves as "huge fans" of it.
It was noted not only for its nice user interface, but for its amazing
robustness.  It was most certainly good software.  Its existence
disproves your statement.

Try and figure out why you are wrong, and how it is possible for one
programmer with an informal process to write good software.  I know
it's a spanner in the works for all those precious Software
Engineering Process textbooks that are prescribed at universities -
but I'm afraid it is real.  Deal with it.

It has been known for some time that good programmers can be 100x
effective than average ones.  This is based on empirical evidence, as
demonstrated by the existence of programs like the one descirbed
above.  There have been various theories put forth for why this is the
case, but the truth is noone has really figured out why.

Why do some novelists write bestsellers, while the majority write
flops?  Why do some mathematicians and physicians think up
groundbreaking theories, while the majority just regurgitate and
rearrange existing knowledge?  Who knows.
  -Andrew.

James Kanze <james.kanze@gmail.com> writes:

> On Jul 26, 9:58 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>> > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> I still find that statement rather offensive.  I done a lot of
>> solo projects for several clients in various corners of the
>> globe over the past decade and I've produced plenty of what I
>> still consider to be very good code.
>
> It's not offensive, it's a fact of life.  I've done a lot of
> solo work in the past, as well.  Before the importance of
> teamwork was fully recognized everywhere.  At the time, I
> considered the code "very good".  And it was, compared to, say,
> what other people working alone were producing.  But in the last
> large project I did that way, the integration and test team
> still found four errors.  For about 40 KLOC---that's one error
> per 10 thousand lines of code.  Where as I've seen programmers
> who I'd consider considerably less skilled than I produce code
> with only one error per 100 KLOC, thanks to things like code
> review and such.  Today, I simply cannot meet the standards I
> set for myself (and others) without help from others.

Interesting.  While the bug count indeed must be reduced, I wouldn't
say that's the most important factor of code quality.  I would put
code maintainability first.

But anyways, your example doesn't involves more than one programmer.
It's good to have testers.  And perhaps other kinds of people in a team
around a programmer.  

That's basically what is advocated in The Mythical Man Month actually.


-- 
__Pascal Bourguignon__

Noah Roberts <roberts.noah@gmail.com> writes:
>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?  How do you mentor a
>whole team of people and still get something written?

  You might try to ask the programmers what they /have/ done in
  the past and what they /can/ do well and then assign them to
  tasks based on this.

  The number of years on the job might have little meaning in
  this regard. For example, an excellent programmer of software
  for engine control or database reports might never have heard
  of �MVC�.

  Maybe they are not �lower level programmers� at all, but 
  �subordinate programmers�?

  See also:

http://codeofdoom.com/wordpress/2009/03/16/dont-let-junior-programmers-cowboy-code/

On Jul 27, 8:59=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 26, 9:58 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> > >>> More likely you've never worked in an environment designed
> > >>> to produce good software. =A0More likely you don't know how
> > >>> to judge good. =A0Although I've seen a few exceptions, most
> > >>> professional programmers are competent, and the cases I've
> > >>> seen where they're not productive, it's been because
> > >>> management has prevented them from being productive.
> > >>> Sometimes, simply by letting a few snotty brats who think
> > >>> that they're the only ones who know anything run things.
> > >> Or marketing types who think they know how to develop software!
> > >> I think more professional programmers succeed despite rather
> > >> than because of their management.
> > > I don't think a professional programmer can succeed without
> > > good management, regardless of how good he is. =A0Programming
> > > is a team effort---one person, working alone, cannot produce
> > > good code.
> > I still find that statement rather offensive. =A0I done a lot of
> > solo projects for several clients in various corners of the
> > globe over the past decade and I've produced plenty of what I
> > still consider to be very good code.
>
> It's not offensive, it's a fact of life. =A0I've done a lot of
> solo work in the past, as well. =A0Before the importance of
> teamwork was fully recognized everywhere. =A0At the time, I
> considered the code "very good". =A0And it was, compared to, say,
> what other people working alone were producing. =A0But in the last
> large project I did that way, the integration and test team
> still found four errors. =A0For about 40 KLOC---that's one error
> per 10 thousand lines of code. =A0Where as I've seen programmers
> who I'd consider considerably less skilled than I produce code
> with only one error per 100 KLOC, thanks to things like code
> review and such. =A0Today, I simply cannot meet the standards I
> set for myself (and others) without help from others.
>
> > > And it takes management to organize the team. =A0(Note that in
> > > some cases, particularly in smaller projects or organizations,
> > > the "manager" may also be part of the team.)
> > Team management is often excellent, it's those who climb
> > higher up the greasy pole who loose the plot.
>
> I've seen that, too. =A0One of the reasons smaller organizations
> are often more successful than larger ones is that "management"
> always wears several hats, including some which involve
> programming as well, and so don't loose touch with reality.
>

Losing touch with reality is a common problem and in my opinion
one solution is starting a company.  "If you can't join em,
beat em."  That's what the pilgrims did.  They created a better
country than the countries they left --
http://webEbenezer.net/comparison.html


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Jul 27, 11:34 am, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > > I have personally seen a 400k line codebase that was written
> > > largely by one person that was (and maybe its latest versions
> > > still is) used by nearly a million people with minimal
> > > marketing.
>
> > And?  A lot of people are using a lot of junk.
>
> The software in question won numerous high profile awards in the face
> of competition, and people described themselves as "huge fans" of it.
> It was noted not only for its nice user interface, but for its amazing
> robustness.  It was most certainly good software.  Its existence
> disproves your statement.

Why aren't you naming this "software in question"? Are you
hiding something?

KHD

On Jul 25, 9:13=A0am, Pete Becker <p...@versatilecoding.com> wrote:
> Ian Collins wrote:
> > Pete Becker wrote:
> >> Ian Collins wrote:
> >>> Pete Becker wrote:
> >>>> Noah Roberts wrote:
> >>>>> Yannick Tremblay wrote:
> >>>>>> In article <GRI9m.54005$9P.45...@newsfe08.iad>,
> >>>>>> JustBoo =A0<B...@boowho.com> wrote:
> >>>>>>> James Kanze wrote:
> >>>>>>>> What I'd really be interesting in seeing is a real life example
> >>>>>>>> of a real program written by a single person which is considered
> >>>>>>>> correct, with a statement as to what is considered correct or
> >>>>>>>> how it is known to be correct.
> >>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called
> >>>>>>> C++?
>
> >>>>>> I don't think he was alone at it although he was the main author f=
or
> >>>>>> the original version. =A0Then a lot of peoples tried it and sugges=
ted
> >>>>>> improvements to it... and now we are atC++0x...
>
> >>>>>C++1xyou mean :P
>
> >>>> No,C++0x.C++1xis at least five years out.
>
> >>> Do you expectC++0x to be ratified this year?
>
> >> Next year.
>
> > Ah, so x =3D 10!
>
> Yup. It's still the project that started in 2003. The name hasn't been
> changed.

It seems Stroustrup diasgrees with you. Below is a quote from

http://www.ddj.com/cpp/218600111

"Even after cutting "concepts," the next C++ standard may be delayed.
Sadly, there will be no C++0x (unless you count the minor corrections
in C++03). We must wait for C++1x, and hope that 'x' will be a low
digit. There is hope because C++1x is now feature complete (excepting
the possibility of some national standards bodies effectively
insisting on some feature present in the formal proposal for the
standard). "All" that is left is the massive work of resolving
outstanding technical issues and comments." - Bjarne Stroustrup

So if I read that right, he refers to standards by the
year of ratification (or expected ratification) not by
the year work starts. That also explains why everyone
was referring to it as C++0x and not C++03 (which would
be consistent with your explanation).

KHD

Keith H Duggar wrote:
> On Jul 25, 9:13 am, Pete Becker <p...@versatilecoding.com> wrote:
>> Ian Collins wrote:
>>> Pete Becker wrote:
>>>> Ian Collins wrote:
>>>>> Pete Becker wrote:
>>>>>> Noah Roberts wrote:
>>>>>>> Yannick Tremblay wrote:
>>>>>>>> In article <GRI9m.54005$9P.45...@newsfe08.iad>,
>>>>>>>> JustBoo  <B...@boowho.com> wrote:
>>>>>>>>> James Kanze wrote:
>>>>>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>>>>>> of a real program written by a single person which is considered
>>>>>>>>>> correct, with a statement as to what is considered correct or
>>>>>>>>>> how it is known to be correct.
>>>>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called
>>>>>>>>> C++?
>>>>>>>> I don't think he was alone at it although he was the main author for
>>>>>>>> the original version.  Then a lot of peoples tried it and suggested
>>>>>>>> improvements to it... and now we are atC++0x...
>>>>>>> C++1xyou mean :P
>>>>>> No,C++0x.C++1xis at least five years out.
>>>>> Do you expectC++0x to be ratified this year?
>>>> Next year.
>>> Ah, so x = 10!
>> Yup. It's still the project that started in 2003. The name hasn't been
>> changed.
> 
> It seems Stroustrup diasgrees with you. Below is a quote from
> 
> http://www.ddj.com/cpp/218600111
> 
> "Even after cutting "concepts," the next C++ standard may be delayed.
> Sadly, there will be no C++0x (unless you count the minor corrections
> in C++03). We must wait for C++1x, and hope that 'x' will be a low
> digit. There is hope because C++1x is now feature complete (excepting
> the possibility of some national standards bodies effectively
> insisting on some feature present in the formal proposal for the
> standard). "All" that is left is the massive work of resolving
> outstanding technical issues and comments." - Bjarne Stroustrup
> 
> So if I read that right, he refers to standards by the
> year of ratification (or expected ratification) not by
> the year work starts. That also explains why everyone
> was referring to it as C++0x and not C++03 (which would
> be consistent with your explanation).
> 

The project is C++0x, and will continue to be.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

On Jul 27, 8:40 pm, Pete Becker <p...@versatilecoding.com> wrote:
> Keith H Duggar wrote:
> > On Jul 25, 9:13 am, Pete Becker <p...@versatilecoding.com> wrote:
> >> Ian Collins wrote:
> >>> Pete Becker wrote:
> >>>> Ian Collins wrote:
> >>>>> Pete Becker wrote:
> >>>>>> Noah Roberts wrote:
> >>>>>>> Yannick Tremblay wrote:
> >>>>>>>> In article <GRI9m.54005$9P.45...@newsfe08.iad>,
> >>>>>>>> JustBoo  <B...@boowho.com> wrote:
> >>>>>>>>> James Kanze wrote:
> >>>>>>>>>> What I'd really be interesting in seeing is a real life example
> >>>>>>>>>> of a real program written by a single person which is considered
> >>>>>>>>>> correct, with a statement as to what is considered correct or
> >>>>>>>>>> how it is known to be correct.
> >>>>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called
> >>>>>>>>> C++?
> >>>>>>>> I don't think he was alone at it although he was the main author for
> >>>>>>>> the original version.  Then a lot of peoples tried it and suggested
> >>>>>>>> improvements to it... and now we are atC++0x...
> >>>>>>> C++1xyou mean :P
> >>>>>> No,C++0x.C++1xis at least five years out.
> >>>>> Do you expectC++0x to be ratified this year?
> >>>> Next year.
> >>> Ah, so x = 10!
> >> Yup. It's still the project that started in 2003. The name hasn't been
> >> changed.
>
> > It seems Stroustrup diasgrees with you. Below is a quote from
>
> >http://www.ddj.com/cpp/218600111
>
> > "Even after cutting "concepts," the next C++ standard may be delayed.
> > Sadly, there will be no C++0x (unless you count the minor corrections
> > in C++03). We must wait for C++1x, and hope that 'x' will be a low
> > digit. There is hope because C++1x is now feature complete (excepting
> > the possibility of some national standards bodies effectively
> > insisting on some feature present in the formal proposal for the
> > standard). "All" that is left is the massive work of resolving
> > outstanding technical issues and comments." - Bjarne Stroustrup
>
> > So if I read that right, he refers to standards by the
> > year of ratification (or expected ratification) not by
> > the year work starts. That also explains why everyone
> > was referring to it as C++0x and not C++03 (which would
> > be consistent with your explanation).
>
> The project is C++0x, and will continue to be.

That's very informative, thank you. I was under the impression
it was just an unofficial name. Tell me, where on what page does
"C++0x" appear in the latest working draft?

KHD

On Jul 28, 1:37=A0am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> On Jul 27, 11:34 am, Andrew Tomazos <and...@tomazos.com> wrote:
>
> > On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > > > I have personally seen a 400k line codebase that was written
> > > > largely by one person that was (and maybe its latest versions
> > > > still is) used by nearly a million people with minimal
> > > > marketing.
>
> > > And? =A0A lot of people are using a lot of junk.
>
> > The software in question won numerous high profile awards in the face
> > of competition, and people described themselves as "huge fans" of it.
> > It was noted not only for its nice user interface, but for its amazing
> > robustness. =A0It was most certainly good software. =A0Its existence
> > disproves your statement.
>
> Why aren't you naming this "software in question"? Are you
> hiding something?

Yes - but nothing that effects the validity of the point.
  -Andrew.

On Jul 28, 1:29 am, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 28, 1:37 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > On Jul 27, 11:34 am, Andrew Tomazos <and...@tomazos.com> wrote:
> > > On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > > > > I have personally seen a 400k line codebase that was written
> > > > > largely by one person that was (and maybe its latest versions
> > > > > still is) used by nearly a million people with minimal
> > > > > marketing.
>
> > > > And?  A lot of people are using a lot of junk.
>
> > > The software in question won numerous high profile awards in the face
> > > of competition, and people described themselves as "huge fans" of it.
> > > It was noted not only for its nice user interface, but for its amazing
> > > robustness.  It was most certainly good software.  Its existence
> > > disproves your statement.
>
> > Why aren't you naming this "software in question"? Are you
> > hiding something?
>
> Yes - but nothing that effects the validity of the point.

On the contrary, it affects our ability to independently evaluate
and verify your claims. Without that we can't decide the validity
of your point (since it was just a collection of anecdotal claims
as opposed to say a deduction from shared beliefs).

KHD

On Jul 28, 8:39=A0am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> > > > > > I have personally seen a 400k line codebase that was written
> > > > > > largely by one person that was (and maybe its latest versions
> > > > > > still is) used by nearly a million people with minimal
> > > > > > marketing.
>
> > > > > And? =A0A lot of people are using a lot of junk.
>
> > > > The software in question won numerous high profile awards in the fa=
ce
> > > > of competition, and people described themselves as "huge fans" of i=
t.
> > > > It was noted not only for its nice user interface, but for its amaz=
ing
> > > > robustness. =A0It was most certainly good software. =A0Its existenc=
e
> > > > disproves your statement.
>
> > > Why aren't you naming this "software in question"? Are you
> > > hiding something?
>
> > Yes - but nothing that effects the validity of the point.
>
> On the contrary, it affects our ability to independently evaluate
> and verify your claims. Without that we can't decide the validity
> of your point (since it was just a collection of anecdotal claims
> as opposed to say a deduction from shared beliefs).

You are correct.  It is indeed merely eye witness testimony.  It is up
to you how much you are swayed by it.  From my point of view, I know
it's valid.  From yours, I guess you can't be certain - although I
can't think what I would gain by making stuff like this up.
  -Andrew.

On Jul 27, 5:39 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > On Jul 26, 9:58 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >> > On Jul 25, 10:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> I still find that statement rather offensive.  I done a lot
> >> of solo projects for several clients in various corners of
> >> the globe over the past decade and I've produced plenty of
> >> what I still consider to be very good code.

> > It's not offensive, it's a fact of life.  I've done a lot of
> > solo work in the past, as well.  Before the importance of
> > teamwork was fully recognized everywhere.  At the time, I
> > considered the code "very good".  And it was, compared to,
> > say, what other people working alone were producing.  But in
> > the last large project I did that way, the integration and
> > test team still found four errors.  For about 40
> > KLOC---that's one error per 10 thousand lines of code.
> > Where as I've seen programmers who I'd consider considerably
> > less skilled than I produce code with only one error per 100
> > KLOC, thanks to things like code review and such.  Today, I
> > simply cannot meet the standards I set for myself (and
> > others) without help from others.

> Interesting.  While the bug count indeed must be reduced, I
> wouldn't say that's the most important factor of code quality.
> I would put code maintainability first.

Both are important.  It's just that the error count is easiest
to measure.

> But anyways, your example doesn't involves more than one
> programmer.  It's good to have testers.  And perhaps other
> kinds of people in a team around a programmer.

OK.  I should have used some other word than programmer,
perhaps, although in the places I've worked, the testers were
also programmers.  But I was talking about the total production
of the code, which does involve much more than just coding.

Of course, in order to ensure maintainability, you need code
review by people with the same profile as those who will be
called on to maintain the code, which means that they're
qualified as programmers, even if they aren't actually
"programming" when doing the review.

The important fact is that the final product is a team effort.

> That's basically what is advocated in The Mythical Man Month
> actually.

Amongst other things.  That you need a team, and that not
everyone in the team should have the same qualifications.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

>> > I don't think a professional programmer can succeed without
>> > good management, regardless of how good he is.  Programming
>> > is a team effort---one person, working alone, cannot produce
>> > good code.
> 
>> That is completely incorrect.
> 
> I'm sorry, but it's a proven fact.

Beware of people who claim something was a "proven fact". 

> Note that
> working in a team is a necessary condition, but not necessarily
> a sufficient one.

Well, if you are working in a team, then teamwork is necessary. There are 
types of Software that can usually not be developed alone, because of the 
complexity of the whole thing. There are very many Programmers that can not 
work alone, because they either are good at Software Design or at coding or 
at project management. 

Nevertheless there are people who are equally good at project management, 
software architecture and coding. It is not the usual case, but they can 
produce high quality software alone. Sometimes they don't do it alone, 
because the effort they are working on is better solved in a team.

Christof

On Jul 27, 5:34 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 27, 4:03 pm, James Kanze <james.ka...@gmail.com> wrote:

> > > I have personally seen a 400k line codebase that was
> > > written largely by one person that was (and maybe its
> > > latest versions still is) used by nearly a million people
> > > with minimal marketing.

> > And?  A lot of people are using a lot of junk.

> The software in question won numerous high profile awards in
> the face of competition, and people described themselves as
> "huge fans" of it.  It was noted not only for its nice user
> interface, but for its amazing robustness.  It was most
> certainly good software.  Its existence disproves your
> statement.

And of course, you won't tell us what it was, or give us any
other means of verifying your claims.  (Windows NT also won some
awards, and a number of people liked it, but it's hardly what I
would call good software.)

    [...]
> It has been known for some time that good programmers can be
> 100x effective than average ones.

It has been known for some time that the world is flat, too.
Actual measurements, of course, have proven the opposite, but
that doesn't bother some people.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 11:44 am, Christof Donat <c...@okunah.de> wrote:
> >> > I don't think a professional programmer can succeed
> >> > without good management, regardless of how good he is.
> >> > Programming is a team effort---one person, working alone,
> >> > cannot produce good code.

> >> That is completely incorrect.

> > I'm sorry, but it's a proven fact.

> Beware of people who claim something was a "proven fact".

Because they might be right?

> > Note that working in a team is a necessary condition, but
> > not necessarily a sufficient one.

> Well, if you are working in a team, then teamwork is
> necessary.  There are types of Software that can usually not be
> developed alone, because of the complexity of the whole thing.
> There are very many Programmers that can not work alone,
> because they either are good at Software Design or at coding
> or at project management.

There are, in fact, no human beings who are perfect, and don't
make mistakes.  An effectively managed team can reduces these
significantly, however, because the mistakes of one person will
be caught and corrected by another.

> Nevertheless there are people who are equally good at project
> management, software architecture and coding.

That's true, but only in a negative sense.  (There are people
who are totally incompetent at all three.)  No one can shine in
all possible areas, however.

But that's not the point.  No one is perfect in any area.  We
all make mistakes.  Having some one else review our work catches
most of those mistakes (supposing that person is competent as
well); the mistakes he makes (the points he misses in the
review) will not be the same ones we make.  (Statistically, at
least.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:

> But that's not the point.  No one is perfect in any area.  We
> all make mistakes.  Having some one else review our work catches
> most of those mistakes (supposing that person is competent as
> well); the mistakes he makes (the points he misses in the
> review) will not be the same ones we make.  (Statistically, at
> least.)

Which is a good argument for pair programming!

-- 
Ian Collins

Hi,

>> > I'm sorry, but it's a proven fact.
> 
>> Beware of people who claim something was a "proven fact".
> 
> Because they might be right?

Because they never are.

Nothing can be a proven fact because any proof can only base on prior 
knowledge and there is no real knowledge that can be counted as proven. So 
people who claim something was a proven fact must be wrong with that claim 
even if the fact is correct.

> There are, in fact, no human beings who are perfect, and don't
> make mistakes.

True, even if they claim it was a proven fact. Once it was a proven fact 
that the earth is flat.

> An effectively managed team can reduces these
> significantly, however, because the mistakes of one person will
> be caught and corrected by another.

That is true as well, but it does not prove your claim that single 
programmers could never produce good code. Their chances are lower than 
those of a well managed highly skilled team.

>> Nevertheless there are people who are equally good at project
>> management, software architecture and coding.
> 
> That's true, but only in a negative sense.  (There are people
> who are totally incompetent at all three.)  No one can shine in
> all possible areas, however.

These are only three areas and at least one of them only partly. In a team 
project management includes a lot of communication skills. For developers 
working alone that part is not necessary. That developer doesn't need to be 
equally good with rowing, writing poems, driving cars or whatever.

Even if you have not yet met any of that rare kind that are competent in all 
three areas, be sure they do exist.

> Having some one else review our work catches
> most of those mistakes

At least that raises the probability. Again that doesn't prove that there 
can not be anyone that is equally competent (in a positive sense) in project 
management, software architecture and coding.

Christof

Hi,

>> But that's not the point.  No one is perfect in any area.  We
>> all make mistakes.  Having some one else review our work catches
>> most of those mistakes (supposing that person is competent as
>> well); the mistakes he makes (the points he misses in the
>> review) will not be the same ones we make.  (Statistically, at
>> least.)
> 
> Which is a good argument for pair programming!

That is _the_ reason for pair programming. Pair programming is a very good 
idea, because it really lowers the probability for mistakes a lot.

Christof

Christof Donat wrote:

Please don't snip attributions!

> Ian Collins wrote:
>> James Kanze wrote:
 >>>
>>> But that's not the point.  No one is perfect in any area.  We
>>> all make mistakes.  Having some one else review our work catches
>>> most of those mistakes (supposing that person is competent as
>>> well); the mistakes he makes (the points he misses in the
>>> review) will not be the same ones we make.  (Statistically, at
>>> least.)
 >>
>> Which is a good argument for pair programming!
> 
> That is _the_ reason for pair programming.

Only one of many.

-- 
Ian Collins

On Jul 28, 11:46=A0am, James Kanze <james.ka...@gmail.com> wrote:
> And of course, you won't tell us what it was, or give us any
> other means of verifying your claims. =A0(Windows NT also won some
> awards, and a number of people liked it, but it's hardly what I
> would call good software.)

:)  I don't think you really believe I'm lieing about what I say.
You've just dug yourself a trench and now are stubbornly laying in it.

> > It has been known for some time that good programmers can be
> > 100x effective than average ones.
>
> It has been known for some time that the world is flat, too.
> Actual measurements, of course, have proven the opposite, but
> that doesn't bother some people.

It's based on empirical evidence.  I've seen the phenomenon firsthand,
numerous other people have given me firsthand accounts, I've read
about it in books.  The only reason I can guess that you have not seen
it too, is that maybe you've never worked closely with a really good
programmer.  Maybe you've been working in IT departments of nontech
sectors like banking etc.  Most good programmers are cherry picked
away by the pure tech companies.
  -Andrew.

Keith H Duggar wrote:
> On Jul 27, 8:40 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> Keith H Duggar wrote:
>>> On Jul 25, 9:13 am, Pete Becker <p...@versatilecoding.com> wrote:
>>>> Ian Collins wrote:
>>>>> Pete Becker wrote:
>>>>>> Ian Collins wrote:
>>>>>>> Pete Becker wrote:
>>>>>>>> Noah Roberts wrote:
>>>>>>>>> Yannick Tremblay wrote:
>>>>>>>>>> In article <GRI9m.54005$9P.45...@newsfe08.iad>,
>>>>>>>>>> JustBoo  <B...@boowho.com> wrote:
>>>>>>>>>>> James Kanze wrote:
>>>>>>>>>>>> What I'd really be interesting in seeing is a real life example
>>>>>>>>>>>> of a real program written by a single person which is considered
>>>>>>>>>>>> correct, with a statement as to what is considered correct or
>>>>>>>>>>>> how it is known to be correct.
>>>>>>>>>>> Bjarne Stroustrup developing a "program" (note the quotes) called
>>>>>>>>>>> C++?
>>>>>>>>>> I don't think he was alone at it although he was the main author for
>>>>>>>>>> the original version.  Then a lot of peoples tried it and suggested
>>>>>>>>>> improvements to it... and now we are atC++0x...
>>>>>>>>> C++1xyou mean :P
>>>>>>>> No,C++0x.C++1xis at least five years out.
>>>>>>> Do you expectC++0x to be ratified this year?
>>>>>> Next year.
>>>>> Ah, so x = 10!
>>>> Yup. It's still the project that started in 2003. The name hasn't been
>>>> changed.
>>> It seems Stroustrup diasgrees with you. Below is a quote from
>>> http://www.ddj.com/cpp/218600111
>>> "Even after cutting "concepts," the next C++ standard may be delayed.
>>> Sadly, there will be no C++0x (unless you count the minor corrections
>>> in C++03). We must wait for C++1x, and hope that 'x' will be a low
>>> digit. There is hope because C++1x is now feature complete (excepting
>>> the possibility of some national standards bodies effectively
>>> insisting on some feature present in the formal proposal for the
>>> standard). "All" that is left is the massive work of resolving
>>> outstanding technical issues and comments." - Bjarne Stroustrup
>>> So if I read that right, he refers to standards by the
>>> year of ratification (or expected ratification) not by
>>> the year work starts. That also explains why everyone
>>> was referring to it as C++0x and not C++03 (which would
>>> be consistent with your explanation).
>> The project is C++0x, and will continue to be.
> 
> That's very informative, thank you. I was under the impression
> it was just an unofficial name. Tell me, where on what page does
> "C++0x" appear in the latest working draft?
> 

It doesn't.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

On Jul 28, 2:03 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 28, 11:46 am, James Kanze <james.ka...@gmail.com> wrote:

> > And of course, you won't tell us what it was, or give us any
> > other means of verifying your claims.  (Windows NT also won
> > some awards, and a number of people liked it, but it's
> > hardly what I would call good software.)

> :)  I don't think you really believe I'm lieing about what I
> say.  You've just dug yourself a trench and now are stubbornly
> laying in it.

> > > It has been known for some time that good programmers can
> > > be 100x effective than average ones.

> > It has been known for some time that the world is flat, too.
> > Actual measurements, of course, have proven the opposite,
> > but that doesn't bother some people.

> It's based on empirical evidence.

The empirical evidence goes the other way.  There are no good
programs developed by just a single person.  You've said there's
one, but since you've refused to actually exhibit it, we have to
conclude that it's probably not as good as you think.

> I've seen the phenomenon firsthand, numerous other people have
> given me firsthand accounts, I've read about it in books.  The
> only reason I can guess that you have not seen it too, is that
> maybe you've never worked closely with a really good
> programmer.

I've worked with some of the best, at times.  The only reason I
can guess that you think you've seen it is that you don't know
what a good program is, so you accept some just as acceptable.

> Maybe you've been working in IT departments of nontech sectors
> like banking etc.  Most good programmers are cherry picked
> away by the pure tech companies.

A lot you know---the banks are generally the ones who do the
cherry picking.  But I've worked a lot on critical systems,
where quality was essential.  I've also worked with the C++
standards committee, where I've had the privilege of
collaborating with some real experts.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 12:11 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > But that's not the point.  No one is perfect in any area.
> > We all make mistakes.  Having some one else review our work
> > catches most of those mistakes (supposing that person is
> > competent as well); the mistakes he makes (the points he
> > misses in the review) will not be the same ones we make.
> > (Statistically, at least.)

> Which is a good argument for pair programming!

Well, pair programming is certainly better than working in
isolation.  But other organizations work too, and are usually
more cost effective.  (IMHO, pair programming doesn't remove the
necessity of doing good code review, because both of the
programmers are involved with the actual writing.  To get the
most advantage, you really need an outside view---someone who
has no idea about the code before hand.  And once you do that,
pair programming adds very little, while requiring twice the
number of people.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 12:19 pm, Christof Donat <c...@okunah.de> wrote:

    [...]
> > There are, in fact, no human beings who are perfect, and
> > don't make mistakes.

> True, even if they claim it was a proven fact. Once it was a
> proven fact that the earth is flat.

When?  The basic principles of scientific proof are a product of
the renaissance, where as it's been well known in scientific
circles that the world is round since at least Ptolomic times.

> > An effectively managed team can reduces these significantly,
> > however, because the mistakes of one person will be caught
> > and corrected by another.

> That is true as well, but it does not prove your claim that
> single programmers could never produce good code.  Their
> chances are lower than those of a well managed highly skilled
> team.

Well, I suppose that a million monkeys typing away at a keyboard
could also produce a "good" program, just by chance.  The
probability of it, however, is low enough that it can be
considered zero.

> >> Nevertheless there are people who are equally good at
> >> project management, software architecture and coding.

> > That's true, but only in a negative sense.  (There are
> > people who are totally incompetent at all three.)  No one
> > can shine in all possible areas, however.

> These are only three areas and at least one of them only
> partly. In a team project management includes a lot of
> communication skills. For developers working alone that part
> is not necessary. That developer doesn't need to be equally
> good with rowing, writing poems, driving cars or whatever.

> Even if you have not yet met any of that rare kind that are
> competent in all three areas, be sure they do exist.

More or less competent, perhaps, but they'll still be better in
one than the others.  Software development requires both right
brain people and left brain people, and one person can't be
both.

But as I said, that's not the point.  The point is that
regardless of competence, the person is a fallible human being.
Having someone else verify there work is an absolute necessity.

(FWIW: take a look at any quality technical book.  The author
will not fail to cite a number of reviewers, and others who've
help in the writing.)

> > Having some one else review our work catches most of those
> > mistakes

> At least that raises the probability.

From basically zero.

> Again that doesn't prove
> that there can not be anyone that is equally competent (in a
> positive sense) in project management, software architecture
> and coding.

But that's irrelevant to the argument.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 2:17=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> A lot you know---the banks are generally the ones who do the
> cherry picking.

Hilarious.  Most good programmers get the gag reflex at the thought of
working for a bank.  So I was right.  You haven't worked with any good
programmers.  Just the tie-wearing IT pro crowd.
  -Andrew.

James Kanze <james.kanze@gmail.com> writes:
>There are no good programs developed by just a single person.

  Do you deem �TeX� to be developed by just a single person?
  Do you deem �TeX� to be �good�?

  Recently, Viktor Mayer-Sch�nberger went public claiming that
  too much �groupthink� might hinder creativity and that 
  programmers sometimes might need some solitude.

http://www.livescience.com/technology/etc/090724-internet-groupthink-throttles-creativity.html
http://inventorspot.com/articles/does_social_media_produce_groupthink_30660

  Groups might encourage incremental improvements of classic
  ideas, but might discourage individuals with radical new ideas.

  Viktor Mayer-Sch�nberger in German:

http://www.heise.de/bin/tp/issue/r4/dl-artikel2.cgi?artikelnr=30791&mode=print

Stefan Ram wrote:
> James Kanze <james.kanze@gmail.com> writes:
>> There are no good programs developed by just a single person.
> 
>   Do you deem �TeX� to be developed by just a single person?

Yes.

>   Do you deem �TeX� to be �good�?
> 

No. It's a horrible programming language. Which is why it's usually 
papered over with LaTeX, which masks many of its quirks, but adds quirks 
of its own.

-- 
   Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

Hi,

>> > There are, in fact, no human beings who are perfect, and
>> > don't make mistakes.
> 
>> True, even if they claim it was a proven fact. Once it was a
>> proven fact that the earth is flat.
> 
> When?  The basic principles of scientific proof are a product of
> the renaissance,

No. People like Roger Bacon an William of Ockham were before. Aristoteles 
was earlier as well. The foundations are really old.

What I actually wanted to say is that you should be careful with claiming 
"proven facts".

>> > An effectively managed team can reduces these significantly,
>> > however, because the mistakes of one person will be caught
>> > and corrected by another.
> 
>> That is true as well, but it does not prove your claim that
>> single programmers could never produce good code.  Their
>> chances are lower than those of a well managed highly skilled
>> team.
> 
> Well, I suppose that a million monkeys typing away at a keyboard
> could also produce a "good" program, just by chance.  The
> probability of it, however, is low enough that it can be
> considered zero.

I see, you don't want to accept the fact, that there are a few people that 
really are able to create high quality software alone.

>> Even if you have not yet met any of that rare kind that are
>> competent in all three areas, be sure they do exist.
> 
> More or less competent, perhaps, but they'll still be better in
> one than the others.  Software development requires both right
> brain people and left brain people, and one person can't be
> both.

It cant be because it shall not be. Reality has some surprises for all who 
think they can put it into simple boxes. "Right Brain" and "Left Brain" 
people are very simple boxes. Most people might fit into somehow, but there 
still are some that don't fit in any of your boxes.

>> > Having some one else review our work catches most of those
>> > mistakes
> 
>> At least that raises the probability.
> 
> From basically zero.

No. 

Actually I have written up to medium sized programs alone which I still 
think are well designed and coded and I finished them in time, so the project 
management wasn't so bad as well. I have worked as a coder, a software 
architect and as a project manager and succeeded in all three areas. I have 
also had various mixed roles and managed to do those jobs good as well.

I can tell you from my experience, that
1. people exist that are able to do all those three jobs well,
2. well managed a good team has a higher probability to prevent errors and 
get things done and
3. single people can produce well designed good written code in a reasonable 
project schedule as well. It's harder, but far from impossible.

Christof

James Kanze wrote:
> On Jul 28, 12:11 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> But that's not the point.  No one is perfect in any area.
>>> We all make mistakes.  Having some one else review our work
>>> catches most of those mistakes (supposing that person is
>>> competent as well); the mistakes he makes (the points he
>>> misses in the review) will not be the same ones we make.
>>> (Statistically, at least.)
> 
>> Which is a good argument for pair programming!
> 
> Well, pair programming is certainly better than working in
> isolation.  But other organizations work too, and are usually
> more cost effective.  (IMHO, pair programming doesn't remove the
> necessity of doing good code review, because both of the
> programmers are involved with the actual writing.  To get the
> most advantage, you really need an outside view---someone who
> has no idea about the code before hand.  And once you do that,
> pair programming adds very little, while requiring twice the
> number of people.)

You keep claiming that never having tried it.

-- 
Ian Collins

On Jul 26, 12:44=A0am, James Kanze <james.ka...@gmail.com> wrote:

> I don't think a professional programmer can succeed without good
> management, regardless of how good he is.

This confirms my suspicion that you've never worked with anyone good.
(Being good is somewhat different than being a language lawyer, by the
way)

On Jul 28, 2:32 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Jul 28, 2:17 pm, James Kanze <james.ka...@gmail.com> wrote:

> > A lot you know---the banks are generally the ones who do the
> > cherry picking.

> Hilarious.  Most good programmers get the gag reflex at the
> thought of working for a bank.  So I was right.  You haven't
> worked with any good programmers.  Just the tie-wearing IT pro
> crowd.

I think you've proved my point.  You obviously don't know beans
about good programs, or good programmers (or banks, for that
matter).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 3:40 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> James Kanze <james.ka...@gmail.com> writes:
> >There are no good programs developed by just a single person.

>   Do you deem =BBTeX=AB to be developed by just a single person?
>   Do you deem =BBTeX=AB to be =BBgood=AB?

No, and fundamentally, no.

It's certainly not the work of a single programmer, working in
isolation---Knuth is known for his communcations skills, and was
a thesis advisor for a number of people when TeX was being
written.  (I read somewhere that a large percentage of TeX was
actually coded by one of the people who had him as a thesis
advisor.  Having actually read several chapters of the source
code, however, I have my doubts---the style is definitely
Knuth's.  On the other hand, Addison-Wesley published it as a
book, and technical books published by Addison-Wesley are NOT
produced in isolation---they're reviewed.  And such reviews do
result in significant changes, and a lot of errors being
caught.)

As for the quality, it is significantly better than a lot of
commercial programs around.  But it still contained more errors
than would have been acceptable in most places where I've
worked.

>   Recently, Viktor Mayer-Sch=F6nberger went public claiming that
>   too much =BBgroupthink=AB might hinder creativity and that
>   programmers sometimes might need some solitude.

Even without reading the article...  Any creative thinker
certainly needs moments of solitude---a lot of my best ideas
come either in the shower, or when I'm driving, with no one else
in the car.  But such creative ideas, and their implementation,
do need to be reviewed.

I think it also depends on the person.  I'm most creative in an
isolated context, but I've worked with people who couldn't
create unless they were doing so out loud, to a listening
audience.  So that after a fairly short brainstorming session,
I'd want to break it off, so that I could think creatively about
the points raised, but my collegue wanted it to continue, for
the same reason.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 4:50 pm, Pete Becker <p...@versatilecoding.com> wrote:
> Stefan Ram wrote:
> > James Kanze <james.ka...@gmail.com> writes:
> >> There are no good programs developed by just a single person.

> >   Do you deem =BBTeX=AB to be developed by just a single person?

> Yes.

I'm pretty sure that's not the case, at least not in the sense I
mean.  (I can't imagine that Knuth published the code without
having someone review it first.  Review before publishing is a
basic principle in scholastic circles.)

> >   Do you deem =BBTeX=AB to be =BBgood=AB?

> No. It's a horrible programming language. Which is why it's
> usually papered over with LaTeX, which masks many of its
> quirks, but adds quirks of its own.

Good point.  To answer the question, you have to precise what is
meant by "good".  With regards to the number of errors, it's
better than a lot of commercial software, but still not what
would be considered "acceptable" in many places I've worked.
With regards to the quality of the output, I don't know of
anything better; I'm a bit of a perfectionists, and I use LaTeX
because the output is so beautiful (compared to, say, Word).
With regards to the "language", on the other hand... it is just
attrocious; it makes Fortran IV look elegant.  (I suppose one
could argue that as TeX itself was really meant to be used as a
sort of "assembler" in which to write higher level languages,
it's acceptable.  Except that plain TeX was supposed to be one
of those higher level languages, and neither it nor LaTeX---the
most widely used of the higher level languages---are really much
better.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 9:14 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jul 28, 12:11 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >> James Kanze wrote:
> >>> But that's not the point.  No one is perfect in any area.
> >>> We all make mistakes.  Having some one else review our work
> >>> catches most of those mistakes (supposing that person is
> >>> competent as well); the mistakes he makes (the points he
> >>> misses in the review) will not be the same ones we make.
> >>> (Statistically, at least.)

> >> Which is a good argument for pair programming!

> > Well, pair programming is certainly better than working in
> > isolation.  But other organizations work too, and are
> > usually more cost effective.  (IMHO, pair programming
> > doesn't remove the necessity of doing good code review,
> > because both of the programmers are involved with the actual
> > writing.  To get the most advantage, you really need an
> > outside view---someone who has no idea about the code before
> > hand.  And once you do that, pair programming adds very
> > little, while requiring twice the number of people.)

> You keep claiming that never having tried it.

There are lot's of things I've never tried.  That doesn't mean I
can't analyse, and make some prognostics.  The people who
propose it never point to any studies where it was compared with
more established techniques, like code review, which have been
proven effective in many environments.  As I said, it is
certainly a significant improvement over programming in total
isolation.  But better (more cost effective) techniques are
known.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 5:34 pm, Christof Donat <c...@okunah.de> wrote:
> >> > There are, in fact, no human beings who are perfect, and
> >> > don't make mistakes.

> >> True, even if they claim it was a proven fact. Once it was
> >> a proven fact that the earth is flat.

> > When?  The basic principles of scientific proof are a
> > product of the renaissance,

> No. People like Roger Bacon and William of Ockham were before.

I'd consider them precursers of the renaissance.  And I'm not
sure they really covered everything we understand in "scientific
proof" today.

> Aristoteles was earlier as well. The foundations are really
> old.

Some of the foundations, yes.  But not really what we'd insist
on for scientific proof today.  (Predictividy, reproduceability,
etc.)

> What I actually wanted to say is that you should be careful
> with claiming "proven facts".

Certainly.

> >> > An effectively managed team can reduces these
> >> > significantly, however, because the mistakes of one
> >> > person will be caught and corrected by another.

> >> That is true as well, but it does not prove your claim that
> >> single programmers could never produce good code.  Their
> >> chances are lower than those of a well managed highly
> >> skilled team.

> > Well, I suppose that a million monkeys typing away at a
> > keyboard could also produce a "good" program, just by
> > chance.  The probability of it, however, is low enough that
> > it can be considered zero.

> I see, you don't want to accept the fact, that there are a few
> people that really are able to create high quality software
> alone.

Because I don't accept that any human being can be perfect, and
that he can produce a significant work without errors.
Empirical evidence supports me in this: to date, no human being
has ever produces a perfect work, in any field.  And they've
been trying for a long time.

> >> Even if you have not yet met any of that rare kind that are
> >> competent in all three areas, be sure they do exist.

> > More or less competent, perhaps, but they'll still be better
> > in one than the others.  Software development requires both
> > right brain people and left brain people, and one person
> > can't be both.

> It cant be because it shall not be.

Can't be because despite all of the efforts to find an
exception, none has been found.  It's an empirical proof, but
given the size of the observed data, it's rather hard to deny
it.

> Reality has some surprises for all who think they can put it
> into simple boxes. "Right Brain" and "Left Brain" people are
> very simple boxes. Most people might fit into somehow, but
> there still are some that don't fit in any of your boxes.

Right brain and left brain are simple boxes, and people do lie
along a continuum.  But they do represent distinct skills, and
people near the middle aren't particularly gifted for one or the
other (i.e. they aren't at one of the extremes).

> >> > Having some one else review our work catches most of
> >> > those mistakes

> >> At least that raises the probability.

> > From basically zero.

> No.

So you're arguing that some human beings are infallible.

> Actually I have written up to medium sized programs alone
> which I still think are well designed and coded and I finished
> them in time, so the project management wasn't so bad as well.
> I have worked as a coder, a software architect and as a
> project manager and succeeded in all three areas. I have also
> had various mixed roles and managed to do those jobs good as
> well.

But you're missing the main point.  They're still fallible, and
need someone else to review their work.

> I can tell you from my experience, that
> 1. people exist that are able to do all those three jobs well,

For a low enough level of well, I suppose.

> 2. well managed a good team has a higher probability to
> prevent errors and get things done and
> 3. single people can produce well designed good written code
> in a reasonable project schedule as well. It's harder, but far
> from impossible.

A person, working alone, will still make significant errors
which would be caught by a review by a third party.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 28, 10:08 pm, fft1976 <fft1...@gmail.com> wrote:
> On Jul 26, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:

> > I don't think a professional programmer can succeed without
> > good management, regardless of how good he is.

> This confirms my suspicion that you've never worked with
> anyone good.  (Being good is somewhat different than being a
> language lawyer, by the way)

So show an exception.  Empirical evidence supports my
statement---where management is bad, projects fail, regardless
of how good the programmers on them are.  To date, no one has
been able to present an exception, and an awfully large data set
has been examined.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Hi,

>> No. People like Roger Bacon and William of Ockham were before.
> 
> I'd consider them precursers of the renaissance.  And I'm not
> sure they really covered everything we understand in "scientific
> proof" today.

As a modern mathematically educated man I can not accept as a proof what you 
tell us.

You claim, that A can never happen and try to proof that with saying: "I 
have never seen A happen." People come up who claim that they have seen A 
happen. They must be wrong and people who claim they have even made A happen 
must be liars. The simple fact is, that your proof is invalid as a proof.

>> I see, you don't want to accept the fact, that there are a few
>> people that really are able to create high quality software
>> alone.
> 
> Because I don't accept that any human being can be perfect,

That automatically leads to the conclusion that any group of human beings 
can never be perfect. Just maybe closer to perfect than a single human that 
is part of the group. There is nothing more in what I said. You will never 
get perfect software which is notably more complex than "hello world". No 
matter how many people you have in your team.

> and that he can produce a significant work without errors.

Oh yes, he can. Maybe you can't. Maybe you never met anyone who can. But 
these guys are out there. Don't ask them to do their laundry or cook a meal 
- they won't be able to accomplish tasks like that, but there are people 
that can produce significant pieces of software alone.

> Empirical evidence supports me in this: to date, no human being
> has ever produces a perfect work, in any field.  And they've
> been trying for a long time.

Some have come quite close.

Has any group of people ever produced a perfect work? If so show me.

> Can't be because despite all of the efforts to find an
> exception, none has been found.

You haven't found => none has been found.

> given the size of the observed data, 

Tell us what data you have observed. Obviously there are people around here 
that have observed other data.

>> Reality has some surprises for all who think they can put it
>> into simple boxes. "Right Brain" and "Left Brain" people are
>> very simple boxes. Most people might fit into somehow, but
>> there still are some that don't fit in any of your boxes.
> 
> Right brain and left brain are simple boxes, and people do lie
> along a continuum. 

No, reality is not linear. Here we see another too simple box to fit reality 
into it.

>> No.
> 
> So you're arguing that some human beings are infallible.

No, but you argue, that there is a group of people that is infallible.

> But you're missing the main point.  They're still fallible, and
> need someone else to review their work.

Show me the perfect software that has been produced by a group of people. If 
there is none, show me the perfect piece of work that has been done by a 
group of people.

You will never get perfection.

Christof

James Kanze wrote:
> On Jul 28, 2:03 pm, Andrew Tomazos <and...@tomazos.com> wrote:

>> I've seen the phenomenon firsthand, numerous other people have
>> given me firsthand accounts, I've read about it in books.  The
>> only reason I can guess that you have not seen it too, is that
>> maybe you've never worked closely with a really good
>> programmer.
> 
> I've worked with some of the best, at times.  The only reason I
> can guess that you think you've seen it is that you don't know
> what a good program is, so you accept some just as acceptable.

LOL!!!

"I'm right and you can't see that because you suck!"

"No.  I'm right and you can't see that because you suck!"

"Actually, the only reason you think that is that you suck!"

"Well, if you didn't suck you'd know that you're clearly mistaken!"

How long you guys intend to keep THAT up?  You, Mr. Kanze, seem prone to 
this kind of argument.  If you can't convince them with absolutisms and 
other nonsense, tell them they suck.

NEITHER of you are arguing from an empirical point.  There is no such 
thing as objectively decidable "good software".  To be empirical there 
must be a measurable gradient by which to judge.  Neither of you has 
provided one.  After reading the back and forth it seems clear to me 
that the definition Mr. Kanze is working with is, "anything not created 
by a solo developer," because no amount of examples of people who've 
considered solo development projects "good" seems to knock him from his 
high horse or pull that gigantic brush from his hand.

People can disagree with you.  It's not the end of the world.  There's 
absolutely no way that, "...it's a proven fact," that solo developers 
can't create something good because nobody agrees what constitutes 
"good" in the software industry.  Ask one industry expert and you'll get 
an entirely different answer from the next one.  Neither is wrong.

Anyway, I'll leave you to this undecidable argument.  If you keep 
insisting how much better you are than each other one of you might cave, 
but I seriously doubt it.  Argument from authority is even less 
convincing when you declare yourself the authority.

On Jul 30, 12:15 am, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:
> > On Jul 28, 2:03 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> >> I've seen the phenomenon firsthand, numerous other people
> >> have given me firsthand accounts, I've read about it in
> >> books.  The only reason I can guess that you have not seen
> >> it too, is that maybe you've never worked closely with a
> >> really good programmer.

> > I've worked with some of the best, at times.  The only
> > reason I can guess that you think you've seen it is that you
> > don't know what a good program is, so you accept some just
> > as acceptable.

> LOL!!!

> "I'm right and you can't see that because you suck!"

> "No.  I'm right and you can't see that because you suck!"

> "Actually, the only reason you think that is that you suck!"

> "Well, if you didn't suck you'd know that you're clearly mistaken!"

> How long you guys intend to keep THAT up?  You, Mr. Kanze,
> seem prone to this kind of argument.  If you can't convince
> them with absolutisms and other nonsense, tell them they suck.

> NEITHER of you are arguing from an empirical point.

There's a large body of empirical evidence which proves that
human beings are fallible.  And that there is no 100x factor
between the best and the worst.  There's also a lot of programs
out there that one can look at, and discuss.

> There is no such thing as objectively decidable "good
> software".

There are established measures for some aspects, like the
absense of errors.  For others, no.

> To be empirical there must be a measurable gradient by which
> to judge.  Neither of you has provided one.  After reading the
> back and forth it seems clear to me that the definition Mr.
> Kanze is working with is, "anything not created by a solo
> developer," because no amount of examples of people who've
> considered solo development projects "good" seems to knock him
> from his high horse or pull that gigantic brush from his hand.

If you choose to ignore the data, there's not much I can say.
(Andrew has no exposed his data---he just says it exists, but we
can't see it.)

> People can disagree with you.  It's not the end of the world.
> There's absolutely no way that, "...it's a proven fact," that
> solo developers can't create something good because nobody
> agrees what constitutes "good" in the software industry.

Again, that's only true for some aspects of "good".  Anything
with more than about 1 error per 100 KLoc of code is certainly
not good.  (That doesn't mean that it's not usable.)  So I
submit the challenge: show me a program which was written by a
single person, without any help (no reviews, etc.), which has
only 1 error per 100 KLoc of code or less.  That's what it would
take to convince me.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 30, 10:57=A0am, James Kanze <james.ka...@gmail.com> wrote:
> And that there is no 100x factor between the best and the worst.

Actually the 100x figure is between the best and the average.  The
worst programmers actually do damage to a project, so their
productivity is negative.
  -Andrew.

On Jul 30, 12:15=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
> NEITHER of you are arguing from an empirical point. =A0There is no such
> thing as objectively decidable "good software".

My definition of good software, is software that has an intuitive
interface and the implementation does what you expect it to.  Human
expectations and intuitions vary, so when we speak about these
qualities in general, we are talking about "most users".  So let me
propose a question:

"If every user that this software is designed for, were to use it in
every possible situation that they would do - would the overwhelming
majority of them (a) consider it easy-to-use; and (b) find that it
operated as they expect?"

If the answer is yes, than it is good software.

In order to test empirically, one could take a random sample of
intended users, get them to thoroughly use the software, and then ask
them whether they found it intuitive and if it worked as expected.

So there you go, "good software" measured empirically.

Furthermore, the idea of counting errors per line of code is
preposterous.  Some issues are clearly bugs (the program freezes) or
feature requests (the icon should be blue) - but most issues fall
somewhere on a continuous scale in between.  To compound the problem
many issues can be thought of as one singular issue, or alternatively
as a set of multiple issues.  Further, depending on your perspective
you can be looking at issue causes or issue symptoms which form a
graph in which there is interrelation and not necessarily one-to-one
correspondences.

You usually get into this idea of counting errors, when you have an
unmotivated permanent development team, and are trying to compensate
for that with formal process.  It never works, and just wastes time.
  -Andrew.

Andrew Tomazos <andrew@tomazos.com> writes:

> On Jul 30, 12:15�am, Noah Roberts <roberts.n...@gmail.com> wrote:
>> NEITHER of you are arguing from an empirical point. �There is no such
>> thing as objectively decidable "good software".
>
> My definition of good software, is software that has an intuitive
> interface and the implementation does what you expect it to.  Human
> expectations and intuitions vary, so when we speak about these
> qualities in general, we are talking about "most users".  So let me
> propose a question:
>
> "If every user that this software is designed for, were to use it in
> every possible situation that they would do - would the overwhelming
> majority of them (a) consider it easy-to-use; and (b) find that it
> operated as they expect?"
>
> If the answer is yes, than it is good software.
>
> In order to test empirically, one could take a random sample of
> intended users, get them to thoroughly use the software, and then ask
> them whether they found it intuitive and if it worked as expected.
>
> So there you go, "good software" measured empirically.
>
> Furthermore, the idea of counting errors per line of code is
> preposterous.  Some issues are clearly bugs (the program freezes) or
> feature requests (the icon should be blue) - but most issues fall
> somewhere on a continuous scale in between.  To compound the problem
> many issues can be thought of as one singular issue, or alternatively
> as a set of multiple issues.  Further, depending on your perspective
> you can be looking at issue causes or issue symptoms which form a
> graph in which there is interrelation and not necessarily one-to-one
> correspondences.
>
> You usually get into this idea of counting errors, when you have an
> unmotivated permanent development team, and are trying to compensate
> for that with formal process.  It never works, and just wastes time.

Not to mention that half of the bugs I see actually are not errors in
the program, but things that were not specified formally and which
once implemented suscite a different "specification".  The other half
being mostly problems with using underspecified / documented libraries.

Programmer errors are actually rather rare because either the program
won't compile, or won't run, or won't pass the minimal unit tests.
That is, they're as much "bugs" as the typos you can make while
editing the program.  If you increment your bug corrected counter
every time you press the DEL key, then ok, solo programmers produce a
lot of bugs.


-- 
__Pascal Bourguignon__

On Jul 30, 2:45 pm, Andrew Tomazos <and...@tomazos.com> wrote:
    [...]
> Furthermore, the idea of counting errors per line of code is
> preposterous.

That's why it's one of the principal measures used in places
where critical software is written.  When the software has to
work, then you take the necessary steps.

    [...]
> You usually get into this idea of counting errors, when you
> have an unmotivated permanent development team, and are trying
> to compensate for that with formal process.  It never works,
> and just wastes time.

Without some sort of process, you don't know whether your
software is doing what it is supposed to do, or how good you
really are.  Noah was very right about one thing: you have to
measure.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Andrew Tomazos wrote:
> On Jul 30, 12:15 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>> NEITHER of you are arguing from an empirical point.  There is no such
>> thing as objectively decidable "good software".
> 
> My definition of good software, is software that has an intuitive
> interface and the implementation does what you expect it to.  Human
> expectations and intuitions vary, so when we speak about these
> qualities in general, we are talking about "most users".  So let me
> propose a question:
> 
> "If every user that this software is designed for, were to use it in
> every possible situation that they would do - would the overwhelming
> majority of them (a) consider it easy-to-use; and (b) find that it
> operated as they expect?"
> 
> If the answer is yes, than it is good software.
> 
> In order to test empirically, one could take a random sample of
> intended users, get them to thoroughly use the software, and then ask
> them whether they found it intuitive and if it worked as expected.
> 
> So there you go, "good software" measured empirically.

Problem is that I don't agree with your definition.  Although we can 
certainly say that the program doing what is intended and being easy to 
use is a necessary component of "good software", I would consider that 
more an aspect of interface design and that's only one side of the coin. 
  The other side of the coin, when the user likes it so much that they 
start suggesting changes...can they be made easily?  THAT I think is if 
not the most important aspect of "good software" then it's the second 
most important aspect.

> 
> Furthermore, the idea of counting errors per line of code is
> preposterous.

I agree.  Any metric that depends on LOC count is a questionable metric 
at best.  I also don't think this would be a good measure of "good 
software".  You can write completely shitty code but it will be bug free 
and follow specification...you'll just end up completely rewriting it 
for every simple change and/or spend 10x+ as long as you would have with 
"good software".

We should also consider the fact that whatever "good software" is there 
must be a continuous scale, not a discrete one.  We can't draw a line 
somewhere and say good is on one side and bad on the other.  There are 
degrees of crappiness when it comes to software.  A solo developer can 
write software that will fall on that scale on one side or the other of 
a line we cannot draw...for some people and not for others.  A solo 
developer can write software that is much "gooder" than software made by 
some teams.

James Kanze wrote:
> On Jul 30, 12:15 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 28, 2:03 pm, Andrew Tomazos <and...@tomazos.com> wrote:
>>>> I've seen the phenomenon firsthand, numerous other people
>>>> have given me firsthand accounts, I've read about it in
>>>> books.  The only reason I can guess that you have not seen
>>>> it too, is that maybe you've never worked closely with a
>>>> really good programmer.
> 
>>> I've worked with some of the best, at times.  The only
>>> reason I can guess that you think you've seen it is that you
>>> don't know what a good program is, so you accept some just
>>> as acceptable.
> 
>> LOL!!!
> 
>> "I'm right and you can't see that because you suck!"
> 
>> "No.  I'm right and you can't see that because you suck!"
> 
>> "Actually, the only reason you think that is that you suck!"
> 
>> "Well, if you didn't suck you'd know that you're clearly mistaken!"
> 
>> How long you guys intend to keep THAT up?  You, Mr. Kanze,
>> seem prone to this kind of argument.  If you can't convince
>> them with absolutisms and other nonsense, tell them they suck.
> 
>> NEITHER of you are arguing from an empirical point.
> 
> There's a large body of empirical evidence which proves that
> human beings are fallible.

So are teams of humans.  In fact, there's a large body of empirical 
evidence that shows groups of humans act even stupider than solo human 
in many cases and fall prey to a whole set of new problems; group think 
is but one example.

   And that there is no 100x factor
> between the best and the worst.  There's also a lot of programs
> out there that one can look at, and discuss.
> 
>> There is no such thing as objectively decidable "good
>> software".
> 
> There are established measures for some aspects, like the
> absense of errors.  For others, no.

And that's a completely arbitrary definition that leaves out many areas 
for crapiness.
> 
>> To be empirical there must be a measurable gradient by which
>> to judge.  Neither of you has provided one.  After reading the
>> back and forth it seems clear to me that the definition Mr.
>> Kanze is working with is, "anything not created by a solo
>> developer," because no amount of examples of people who've
>> considered solo development projects "good" seems to knock him
>> from his high horse or pull that gigantic brush from his hand.
> 
> If you choose to ignore the data, there's not much I can say.
> (Andrew has no exposed his data---he just says it exists, but we
> can't see it.)

Same goes for you.  Show me evidence that the majority of software teams 
can produce code that has <1 error per 100 kloc and that no solo human 
being is capable of the same.  Show me evidence that these teams are 
still efficient at producing products and innovate with new ideas and 
directions (problem being that too much concern over error tends to 
stamp down risk taking).  How long does it take said team to produce 100 
kloc?  What constitutes an error?  Spelling mistakes in the interface? 
How many people are on these teams?

If the average person can develop 50 error free loc in a day then it 
would take 5.5 man years (including weekends/holidays) to develop those 
100kloc of error free code you're looking at.  100kloc is a small 
program.  It seems to me that you're again being completely arbitrary 
and setting up the conversation to run in your favor without providing 
any evidence that we should accept your definition.

James Kanze wrote:

> Because I don't accept that any human being can be perfect, and
> that he can produce a significant work without errors.
> Empirical evidence supports me in this: to date, no human being
> has ever produces a perfect work, in any field.  And they've
> been trying for a long time.

But you haven't told us why "good software" must be "perfect software". 
  From my perspective it doesn't require a perfect human to develop 
_good_ software..convenient thing too because otherwise there'd be no 
such thing as good software, written by teams or otherwise.

Christof Donat wrote:
>> Because I don't accept that any human being can be perfect,
> 
> That automatically leads to the conclusion that any group of human beings 
> can never be perfect. Just maybe closer to perfect than a single human that 
> is part of the group.

Or visa-versa.  A human alone has X number of flaws.  A group of humans 
has XN number of flaws and often times the X's complement each other to 
create new flaws so you have XN + Z number of flaws such that for any n 
in the group the non-flaws about that person cannot possibly counter the 
flaws in the entire group.

James Kanze wrote:
> 
> Without some sort of process, you don't know whether your
> software is doing what it is supposed to do, or how good you
> really are.  Noah was very right about one thing: you have to
> measure.

Ah, but measure what?

I've always judged my my code by either customer satisfaction and (lack 
of!) support revenue with a single customer or field defects for 
applications with many, unknown, customers.

-- 
Ian Collins

On Jul 29, 2:10=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 28, 10:08 pm, fft1976 <fft1...@gmail.com> wrote:
>
> > On Jul 26, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:
> > > I don't think a professional programmer can succeed without
> > > good management, regardless of how good he is.
> > This confirms my suspicion that you've never worked with
> > anyone good. =A0(Being good is somewhat different than being a
> > language lawyer, by the way)
>
> So show an exception. =A0Empirical evidence supports my
> statement---where management is bad, projects fail, regardless
> of how good the programmers on them are. =A0To date, no one has
> been able to present an exception, and an awfully large data set
> has been examined.

That's not what you said, actually. "Without management" and "with bad
management" are different things.

In article <7c4osuqp7f.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>Andrew Tomazos <andrew@tomazos.com> writes:
>
>> On Jul 30, 12:15�am, Noah Roberts <roberts.n...@gmail.com> wrote:
>>> NEITHER of you are arguing from an empirical point. �There is no such
>>> thing as objectively decidable "good software".
>>
>> My definition of good software, is software that has an intuitive
>> interface and the implementation does what you expect it to.  Human
>> expectations and intuitions vary, so when we speak about these
>> qualities in general, we are talking about "most users".  So let me
>> propose a question:
>>
>> "If every user that this software is designed for, were to use it in
>> every possible situation that they would do - would the overwhelming
>> majority of them (a) consider it easy-to-use; and (b) find that it
>> operated as they expect?"
>>
>> If the answer is yes, than it is good software.
>>
>> In order to test empirically, one could take a random sample of
>> intended users, get them to thoroughly use the software, and then ask
>> them whether they found it intuitive and if it worked as expected.
>
[... snip snip...]
>
>Not to mention that half of the bugs I see actually are not errors in
>the program, but things that were not specified formally and which
>once implemented suscite a different "specification".  The other half
>being mostly problems with using underspecified / documented libraries.

This is absolutely true.  However, this even more highlight that a
single human being, isolated, is less likely to produce a great
software than a team.  Because the single human being will tend to
think one way and not easily be able to see a problem from several
angles.  So the specification, usability or other similar things are
less likely to fully consider all the multiple aspects aspect of the
problem.  

so regardless of quality of the code line by line, the quality of the
complete solution might not fullfil the needs of the users as well.

>Programmer errors are actually rather rare because either the program
>won't compile, or won't run, or won't pass the minimal unit tests.
>That is, they're as much "bugs" as the typos you can make while
>editing the program.  If you increment your bug corrected counter
>every time you press the DEL key, then ok, solo programmers produce a
>lot of bugs.

Yannick

In article <4a71cc44$0$7462$cc2e38e6@news.uslec.net>,
Noah Roberts  <roberts.noah@gmail.com> wrote:
>Christof Donat wrote:
>>> Because I don't accept that any human being can be perfect,
>> 
>> That automatically leads to the conclusion that any group of human beings 
>> can never be perfect. Just maybe closer to perfect than a single human that 
>> is part of the group.
>
>Or visa-versa.  A human alone has X number of flaws.  A group of humans 
>has XN number of flaws and often times the X's complement each other to 
>create new flaws so you have XN + Z number of flaws such that for any n 
>in the group the non-flaws about that person cannot possibly counter the 
>flaws in the entire group.

Well, if you are going to include a Z flaw that are purely a product
of combination of flaws in various peoples, you shiould also be fair
and add a Y that is the number of flaws that are negated due to one
person having a quality that negate the presence of the flaw in
someone else.  You may also need to consider is duplicated flaws have
the same cost as unique flaws... 

So total number of flaws:

XN + Z

Total number of non-negated flaws would be:

XN + Z - Y

And total number of non-negated unique flaws become probabilistic and
a mathematical expression for them is non-trivial...

James Kanze wrote:
> Noah was very right about one thing: you have to
> measure.

Actually, what I said was that in order for something to be empirically 
based there must have been a measurement done.

I don't agree with you that software "goodness" is something that can be 
measured.  In fact, I can't think of any "goodness" that is possible to 
measure.  Various things that various people think are "good", sure, but 
"goodness" is a subjective term that can't be empirically measured or 
applied.

For example, you are using "goodness" to mean, "lack of errors."  We can 
measure errors, somewhat, but since not everyone agrees with your use of 
the term "good" we haven't objectively measured "goodness".  This is why 
when speaking empirically it is best to use objective terms like "lack 
of error" instead of "goodness".  Then people know WTF you're talking about.

Noah Roberts wrote:
> James Kanze wrote:
>> Noah was very right about one thing: you have to
>> measure.
> 
> Actually, what I said was that in order for something to be empirically 
> based there must have been a measurement done.
> 
> I don't agree with you that software "goodness" is something that can be 
> measured.  In fact, I can't think of any "goodness" that is possible to 
> measure.  Various things that various people think are "good", sure, but 
> "goodness" is a subjective term that can't be empirically measured or 
> applied.
> 
> For example, you are using "goodness" to mean, "lack of errors."  We can 
> measure errors, somewhat, but since not everyone agrees with your use of 
> the term "good" we haven't objectively measured "goodness".  This is why 
> when speaking empirically it is best to use objective terms like "lack 
> of error" instead of "goodness".  Then people know WTF you're talking 
> about.

Could it be that we are looking at quality or "goodness" from different 
perspectives?

My perspective is that of a business supplying a product (which happens 
to be code) to a customer.  From that perspective I don't really care 
how many lines of code there are.  I care about customer satisfaction 
and my bottom line.  Sure I strive for perfection, but that has to be 
balanced with cost and delivery dates.  "Good" code is code makes my 
customers happy, generates follow up work and doesn't cost me time in 
bug fixes (I don't charge for those).

My customers are happy and I haven't gone bust, so therefore I must be 
producing good code!

-- 
Ian Collins

Ian Collins wrote:

> My customers are happy and I haven't gone bust, so therefore I must be 
> producing good code!

So you agree that Microsoft must be producing good code? Just
checking... :)

Gerhard

On Jul 17, 12:36=A0pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
> On Jul 9, 2:38 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > Another example: I tell this one guy who's been a developer for like 20
> > years or something to work on settingupa property editor. =A0I 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. =A0He goes off "researching" some boost::fusion based cra=
p
> > for two weeks and when I go to check on how he's progressed on somethin=
g
> > that would take me an hour...he's nowhere. =A0Now, 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.

Similar to daily plans are the stand-up meetings. Here are some
details on it - http://www.martinfowler.com/articles/itsNotJustStandingUp.h=
tml

It won't make much sense if you have a team of 2 including yourself
but you always have the options to tailor it to your needs. But such
catch-ups surely help provided you have the right implementation such
that it doesn't go much off-track and it isn't taking too much time.
Some of the pitfalls are available on the link above like: story-
telling.

WBS (http://en.wikipedia.org/wiki/Work_breakdown_structure) might
provide you some control too. It will probably ensure that the team
knows what a particular delivery unit is and would help measure the
progress better with clarity both for you and your team.

I must say that I have not been in a management/lead role myself but I
have been a relatively new practitioner of the above 2 and they have
somewhat helped in terms of greater clarity for the team, measuring
progress, sharing knowledge among the team. Important is that the team
including the lead/manager has the belief/buy-in, where mostly the
challenge lies.

Here=B4s my take on it:

In school you learn that things have to be almost perfect
to get a good grade, even if takes two months to do it.

Then you move to the busyness world where things have to be
ready for yesterday, and as long as they work, it doesn=B4t mater
if they are inefficient, patchy, bloated and ugly. Bosses(clients,
internal or external)
prefer a bad working code today, than a perfect one in two months.

This often takes time to be accepted by some(it surely took for me,
and I don=B4t
fully yet accept that yet, but it=B4s slowly sinking in).

Another problem maybe in the communication:

I think the best way is to communicate in terms of problem/time/
suggestions/restrictions. 'I have
this problem that I need solved for a week. My suggestion is that you
use this, this
and this but if you can think up something, better go ahead. Oh there
=B4s also this
and this restriction"

But by all, means don=B4t behave like "I need a facade pattern"(who
knows he may think of something better!why would that ever be a
restriction ?) using this this this and this. And variables and
commentaries should be in this style."
(Go ahead pawn!)

Developers like to use their brains, and not just be the hands and
legs of someone
else=B4s brains.

Someone sayed: "Trying to manage programmers is like trying to herd
cats"

Have you ever tried to use Scrumm ? I think it=B4s a quality methodology
that suits your problem very well.

Good luck.

Rafael

Ian Collins <ian-news@hotmail.com> writes:

> Noah Roberts wrote:
>> James Kanze wrote:
>>> Noah was very right about one thing: you have to
>>> measure.
>>
>> Actually, what I said was that in order for something to be
>> empirically based there must have been a measurement done.
>>
>> I don't agree with you that software "goodness" is something that
>> can be measured.  In fact, I can't think of any "goodness" that is
>> possible to measure.  Various things that various people think are
>> "good", sure, but "goodness" is a subjective term that can't be
>> empirically measured or applied.
>>
>> For example, you are using "goodness" to mean, "lack of errors."  We
>> can measure errors, somewhat, but since not everyone agrees with
>> your use of the term "good" we haven't objectively measured
>> "goodness".  This is why when speaking empirically it is best to use
>> objective terms like "lack of error" instead of "goodness".  Then
>> people know WTF you're talking about.
>
> Could it be that we are looking at quality or "goodness" from
> different perspectives?
>
> My perspective is that of a business supplying a product (which
> happens to be code) to a customer.  From that perspective I don't
> really care how many lines of code there are.  I care about customer
> satisfaction and my bottom line.  

Indeed, when customer satisfaction and bottom line is the target, bug
counts are irrelevant.  Or any _other_ aspect of goodness. 


> Sure I strive for perfection, 

That's why you're not as rich as Bill Gates.


> but that has to be balanced with cost and delivery dates.  "Good" code is
> code makes my customers happy, generates follow up work and doesn't
> cost me time in bug fixes (I don't charge for those).

There's no bug that can overcome a good marketting campain (which can
minimally be just a nice splash screen) to make users happy.


> My customers are happy and I haven't gone bust, so therefore I must be
> producing good code!

Asking the credit card number of your customers first thing on the hot
line is also a good way to avoid dealing with bugs.

-- 
__Pascal Bourguignon__

Abhishek Padmanabh wrote:
> On Jul 17, 12:36 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
>> On Jul 9, 2:38 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>>> Another example: I tell this one guy who's been a developer for like 20
>>> years or something to work on settingupa 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.
> 
> Similar to daily plans are the stand-up meetings. Here are some
> details on it - http://www.martinfowler.com/articles/itsNotJustStandingUp.html
> 

We did stand ups here and they were a total waste of time for us.  We 
got the same stuff I got when just asking, "How are things going?" 
People respond with, "fine," and in stand-ups that would be, "I'm doing 
backlog item XXX and everything's going great."  Everyone knows you're 
doing backlog item XXX and the later is not informative.

Ian Collins wrote:
> Noah Roberts wrote:
>> James Kanze wrote:
>>> Noah was very right about one thing: you have to
>>> measure.
>>
>> Actually, what I said was that in order for something to be 
>> empirically based there must have been a measurement done.
>>
>> I don't agree with you that software "goodness" is something that can 
>> be measured.  In fact, I can't think of any "goodness" that is 
>> possible to measure.  Various things that various people think are 
>> "good", sure, but "goodness" is a subjective term that can't be 
>> empirically measured or applied.
>>
>> For example, you are using "goodness" to mean, "lack of errors."  We 
>> can measure errors, somewhat, but since not everyone agrees with your 
>> use of the term "good" we haven't objectively measured "goodness".  
>> This is why when speaking empirically it is best to use objective 
>> terms like "lack of error" instead of "goodness".  Then people know 
>> WTF you're talking about.
> 
> Could it be that we are looking at quality or "goodness" from different 
> perspectives?
> 
> My perspective is that of a business supplying a product (which happens 
> to be code) to a customer.  From that perspective I don't really care 
> how many lines of code there are.  I care about customer satisfaction 
> and my bottom line.  Sure I strive for perfection, but that has to be 
> balanced with cost and delivery dates.  "Good" code is code makes my 
> customers happy, generates follow up work and doesn't cost me time in 
> bug fixes (I don't charge for those).

Well, it sounds to me like you have "good" design in there (measured by 
the ease with which you fix bugs or perform follow up work) so I'd be 
happy with that definition.  I think LOC is a really silly metric.  I do 
loosely have a max LOC per function requirement but it's very loose.
> 
> My customers are happy and I haven't gone bust, so therefore I must be 
> producing good code!
> 

Surely.  I still think it's more communicative to use the direct terms 
though.  "I write software that my customers are happy with," is more 
informative and correct--and hard to argue with--than, "I write good 
software."

On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:

I wasn't going to respond any further here, since the argument
is really "Everyone I've ever worked with is incompetent" (from
Andrew) and "I'm just being argumentive if I dispute this" (from
Noah).  As it happens, most of the people I've worked with, with
very, very few exceptions, are good programmers, the insults
thrown out gratuously by Andrew not withstanding.  (And until
Noah understands this basic principle, he's not going to be able
to effectively lead a team.  Leadership starts with respect for
your subordonnates.)

As for the idea that no good programmer would work at a bank:
http://bartelby.net/17/1/31.html.  In fact, I've over thirty
five years of professional experience, in many different
domains: OS, compilers, embedded systems, telecoms and banks,
and there's no significant difference in the level competence
depending on the domain.  (There is a difference in the fields
of competence---you'll find a lot more experts in numeric
programming working in investment banks than on embedded
systems.)

As for the +100 factor: superman only exists in comic books;
human beings just don't vary that much in their capacities.

As for the statement "one person, working alone, cannot write a
good program", it's obviously a simplification, and a bit of
hyperbole, since it doesn't mean much without a definition of
good, when applied to a program, and "working alone", for that
matter---witness the discussion about TeX.  (I wouldn't consider
anyone writing reviewed works in a University context "working
alone".  But the collaboration is obviously of a different
nature than that usual in enterprise, and I can understand a
difference of opinion concerning that definition.)

    [...]
> > There are established measures for some aspects, like the
> > absense of errors.  For others, no.

> And that's a completely arbitrary definition that leaves out
> many areas for crapiness.

Certainly.  It's a necessary condition.  It's not a sufficient
one.  (Good software doesn't crash.  Regardless of how good it
is in other aspects.)

It just happens to be the easiest one to measure.  And one that
can't be achieved by a person working in isolation, at least as
far as I can tell.  (For non-trivial software, of course.)

    [...]
> > If you choose to ignore the data, there's not much I can
> > say.  (Andrew has no exposed his data---he just says it
> > exists, but we can't see it.)

> Same goes for you.

I supposed that my data was well known to most practionners,
since it has been widely published.  If not,
http://www.sei.cmu.edu/ is a good place to start.

> Show me evidence that the majority of software teams can
> produce code that has <1 error per 100 kloc and that no solo
> human being is capable of the same.

The majority of software teams probably can't.  It takes at
least an SEI level 3, and I think (without looking it up, so
don't bet on it) that that's less than 10% of the organization
the SEI has measured.  It takes a pretty good process to get to
that level; only one of the places I've worked has achieved it.
But it's certainly a possibility, and at least one place has
documented significantly better.  My experience (and this is
very subjective) is that anything you do bringing you closer to
the 1 error per KLOC tends to reduce costs in the long run
("quality is free"); I can't really say for sure, but
intuitively, I suspect that going beyond that will quickly
become very expensive.  (The organisms which do significantly
better generally have to, regardless of price.)

As for why a single person can't do this well... Well, I've
known a lot of really good programmers---some of the best, in
fact, and none come anywhere close.  And given that some of
these are at the upper limits of competence, and given the
limits in variance in human performance, it seems like a very
reasonable assumption.  Do you know, or have you even heard of,
anyone who even claims anything close to this.  (I know my upper
limit is about 1 line per 10 KLOC, and I don't always perform at
that level.)

> Show me evidence that these teams are still efficient at
> producing products and innovate with new ideas and directions
> (problem being that too much concern over error tends to stamp
> down risk taking).

Concern for errors does mean that you have to evaluate risks.
So does most other things.  Radical experimentation belongs in
the University, not in industry.  And I've never heard of a
client who pays just for something to be "new"---they want
working solutions to real problems.  (And from experience---the
first program to exploit a new idea is never "good".  There's a
reason it's called the "bleeding edge".)

> How long does it take said team to produce 100 kloc?

It depends on how many people are in the team, and how complex
the problem domain is.

> What constitutes an error?

Anything that has to be fixed.

> Spelling mistakes in the interface?

Or even in the log file output, or the documentation.  Anything
that causes you to have to change something in the deliverables
after delivery.  (From the programmers point of view, delivery
is delivery to the integration team, at least on large
projects.)

> How many people are on these teams?

It varies, but in the places I've worked, four to six people in
each group seems to be about optimal.  The larger the project,
the more groups you need.  Or maybe I should say, can use;
there's an upper limit to the number of groups that can be used
effectively, which varies according to the size and complexity
of the project.

> If the average person can develop 50 error free loc in a day
> then it would take 5.5 man years (including weekends/holidays)
> to develop those 100kloc of error free code you're looking at.
> 100kloc is a small program.

One person doesn't develop "error free LOC".  And it's very
difficult to discuss time in the abstract, because it varies so
much.  In cases where I have a rigid, fixed specification of
exactly what the program is to do, and it involves a field in
which I have expertise, I'm capable of producing about 40 KLOC
in a man year, with about 1 error per 10 KLOC.  But those
conditions are very exceptional, almost never met.  And that's
working alone---the results are, I think, better than most could
do, but they're still not what I would consider "good".  For
that, I need help---code reviews, etc.  (At the other extreme,
if the customer has no real idea what he wants, or you're
working on something so radically new that you need to develope
completely new algorithms, then you can easily spend a man-year
producing no lines of code.)

The important thing, of course, is to be able to measure what
you're doing, so that you can determine whether any change you
make is an improvement or not.

> It seems to me that you're again being completely arbitrary
> and setting up the conversation to run in your favor without
> providing any evidence that we should accept your definition.

As I said, you might start with the documentation at the SEI
site quoted above.  Particularly
http://www.sei.cmu.edu/publications/key-publications.html and
the link to process improvement.  Most of what they suggest has
been around for awhile, and has proven its value.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> 
> As I said, you might start with the documentation at the SEI
> site quoted above.  Particularly
> http://www.sei.cmu.edu/publications/key-publications.html and
> the link to process improvement.  Most of what they suggest has
> been around for awhile, and has proven its value.

James, have you read

"CMMI or Agile: Why Not Embrace Both!"?

http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf

-- 
Ian Collins

On Aug 4, 11:14=A0am, James Kanze <james.ka...@gmail.com> wrote:
> I wasn't going to respond any further here, since the argument
> is really "Everyone I've ever worked with is incompetent" (from
> Andrew)

That is a childish misrepresentation of what I said.  If you don't
understand where the statement "a good programmer can be 100x
productive as an average one" comes from than my guess is you haven't
worked with any *really* good programmers.

Surely you don't claim to have worked with every programmer on Earth?
Given that you have not, why isn't it possible that some of the
programmers you have not worked with are significantly better than the
best programmer you have worked with?  You must concede it as, at a
minimum, logically possible.

Given that it is possible, why do you so fervently deny it?  I would
quite happily accept you saying that you have not seen the phenomenon
- but you are claiming that it doesn't exist because you haven't seen
it.  When someone digs a trench like this they usually have a vested
interest in their position being true:

The fact is a lot of engineering process designers and project
managers would love it if programmers were homogeneous interchangeable
parts.  It would make a managers job so much easier that some even try
to bury their head in the sand and pretend that this is the case.  X
programmers produce Y lines of code with Z errors. :)  Unfortunately
it just doesn't gel with reality.

Programmers vary greatly in their level of productivity (yes as much
as 100x).  I repeat: I have seen this firsthand, I have heard
firsthand account, it has been written about in books.
  -Andrew.

James Kanze wrote:
> [...]
>>>> It has been known for some time that good programmers can
>>>> be 100x effective than average ones.
> 
> [...]
> 
>> I've seen the phenomenon firsthand, numerous other people have
>> given me firsthand accounts, I've read about it in books.  The
>> only reason I can guess that you have not seen it too, is that
>> maybe you've never worked closely with a really good
>> programmer.
> 
> [...]
> 
>> Maybe you've been working in IT departments of nontech sectors
>> like banking etc.  Most good programmers are cherry picked
>> away by the pure tech companies.
> 
> A lot you know---the banks are generally the ones who do the
> cherry picking.  But I've worked a lot on critical systems,
> where quality was essential.  I've also worked with the C++
> standards committee, where I've had the privilege of
> collaborating with some real experts.

I guess with you it's just the opposite, James: You haven't
worked with bad programmers in a long time. :) (Or you just
don't see how much worse some of those around you are. But
you surely would have found out in code reviews, so that's
rather unlikely.)
Just to look at some of the questions that are asked here
daily which show fundamental misunderstandings or surprising
lack of even the most basic knowledge -- and those are asked
by the ones who find Usenet. And not all of those asking such
questions are newbies just trying to learn the language.

Schobi

"Andrew Tomazos" <andrew@tomazos.com>
On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>> I wasn't going to respond any further here, since the argument
>> is really "Everyone I've ever worked with is incompetent" (from
>> Andrew)

>That is a childish misrepresentation of what I said.  If you don't
>understand where the statement "a good programmer can be 100x
>productive as an average one" comes from than my guess is you haven't
>worked with any *really* good programmers.

I'm quite sure James worked with some of those.

What I seriously doubt from reading many his posts, that he worked with bad 
ones. And mor importantly with many average ones.    And if you cut the 
first 80% of measuring data, certainly different figures will emerge.

Being able to find the good places to work, and restrict to only those is a 
good thing -- but not too widespread. 

Andrew Tomazos wrote:
> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>> I wasn't going to respond any further here, since the argument
>> is really "Everyone I've ever worked with is incompetent" (from
>> Andrew)
> 
> That is a childish misrepresentation of what I said.  If you don't
> understand where the statement "a good programmer can be 100x
> productive as an average one" comes from than my guess is you haven't
> worked with any *really* good programmers.

That's really just silly.
> 
> Surely you don't claim to have worked with every programmer on Earth?
> Given that you have not, why isn't it possible that some of the
> programmers you have not worked with are significantly better than the
> best programmer you have worked with?  You must concede it as, at a
> minimum, logically possible.
> 
> Given that it is possible, why do you so fervently deny it?

I see arguments just like this quite often when people try to get me to 
believe in supernatural boogymen or start praying to rocks.  I'm not 
going to speak for Kanze of course but I see a very clear difference 
between "logically possible" and "realistic".  Logic isn't actually that 
great for telling us about the real world.

You can logically prove all kinds of ridiculous ideas with false or 
questionable premises; mix a contradiction in and anything is provable. 
  You can also invent all kinds of insane ideas that are completely 
impossible to logically disprove.  People who base everything on logic 
are not going to get anywhere if they don't check their logic with 
reality once in a while.

So, for example, if someone were to come to me and say they have a rock 
that can think I'd utterly dismiss the idea entirely.  I wouldn't even 
entertain it as possible.  Can I logically prove that some given rock is 
not sentient?  No, never.  Do I need to before I laugh at the person or 
kindly let them know they might need mental help?  No.


   I would
> quite happily accept you saying that you have not seen the phenomenon
> - but you are claiming that it doesn't exist because you haven't seen
> it.

Actually, Kanze has put a lot more out there than just that he's never 
seen one.  You should go back and read what he's said if that's all you 
think he's basing his opinion on.  I'm not saying he's right or that I 
agree with him but this really is an unfair statement about his position.


> The fact is a lot of engineering process designers and project
> managers would love it if programmers were homogeneous interchangeable
> parts.  It would make a managers job so much easier that some even try
> to bury their head in the sand and pretend that this is the case.  X
> programmers produce Y lines of code with Z errors. :)  Unfortunately
> it just doesn't gel with reality.

And as far as I can tell Kanze hasn't said otherwise here either.  There 
are definitely really good developers and "free electrons" as Rands puts 
it in his book, but there's no such thing as a super-programmer.
> 
> Programmers vary greatly in their level of productivity (yes as much
> as 100x).  I repeat: I have seen this firsthand, I have heard
> firsthand account, it has been written about in books.
>   -Andrew.

James Kanze wrote:
> On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> James Kanze wrote:
> 
> I wasn't going to respond any further here, since the argument
> is really "Everyone I've ever worked with is incompetent" (from
> Andrew) and "I'm just being argumentive if I dispute this" (from
> Noah).  As it happens, most of the people I've worked with, with
> very, very few exceptions, are good programmers, the insults
> thrown out gratuously by Andrew not withstanding.  (And until
> Noah understands this basic principle, he's not going to be able
> to effectively lead a team.  Leadership starts with respect for
> your subordonnates.)

I really don't know where you get off on these accusations but I guess I 
can't expect any better from you.  It seems clear to me that you're 
perfectly happy playing the insult game until you run into someone 
that's just as happy to play and maybe a bit better at it.  I would 
kindly ask that you actually quote me insulting people or showing 
disrespect to "subordonnates" but actually backing up your accusations 
has not been your strong suit.  This is like the times you insisted I 
write crap code when you'd never even seen one line...more shit for the 
pile, Kanze.

Keep it.  In the words of Overkill:

YOU! Got a lot to learn.
Your head's up your ass!
YOU! Got a lot to learn.
You got no class.

No class.

On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:
> > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> >> James Kanze wrote:
>
> > I wasn't going to respond any further here, since the argument
> > is really "Everyone I've ever worked with is incompetent" (from
> > Andrew) and "I'm just being argumentive if I dispute this" (from
> > Noah). =A0As it happens, most of the people I've worked with, with
> > very, very few exceptions, are good programmers, the insults
> > thrown out gratuously by Andrew not withstanding. =A0(And until
> > Noah understands this basic principle, he's not going to be able
> > to effectively lead a team. =A0Leadership starts with respect for
> > your subordonnates.)
>
> I really don't know where you get off on these accusations but I guess I
> can't expect any better from you. =A0It seems clear to me that you're
> perfectly happy playing the insult game until you run into someone
> that's just as happy to play and maybe a bit better at it. =A0I would
> kindly ask that you actually quote me insulting people or showing
> disrespect to "subordonnates" but actually backing up your accusations
> has not been your strong suit. =A0This is like the times you insisted I
> write crap code when you'd never even seen one line...more shit for the
> pile, Kanze.
>
> Keep it. =A0In the words of Overkill:
>
> YOU! Got a lot to learn.
> Your head's up your ass!
> YOU! Got a lot to learn.
> You got no class.
>
> No class.

What is with this newsgroup?  People seem to be waiting for an
opportunity to go at each other's throat.  First there was Mr. Duggar
who thinks the best way to get someone to admit their mistake
(legitimate or not) is to humiliate them.  The next is Mr. Roberts
who, in all this time of lurking in this newsgroup, I have never seen
agreeing with Mr. Kanze on anything (not that its a bad thing -- I
just wonder why this kind of language needs to be resorted to).

The thing that gets me is I have been following this newsgroup for
several years.  I have learnt an enormous amount of C++ by simply
reading posts from James Kanze, Jerry Coffin, Hyman Rosen and others.
Doesn't that count for a little bit of respect or at least the fact
they, you know, might actually know what they are talking about?  Like
everyone of us they are going to be wrong from time to time and I have
personally read quite a few posts where they have freely admitted it.
But even there they have been more right than wrong.  Why can't we all
get along?  Is it too much to maintain some civility considering, um,
we are adults?

Dilip wrote:
> On Aug 5, 11:08 am, Noah Roberts <roberts.n...@gmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>>>> James Kanze wrote:
>>> I wasn't going to respond any further here, since the argument
>>> is really "Everyone I've ever worked with is incompetent" (from
>>> Andrew) and "I'm just being argumentive if I dispute this" (from
>>> Noah).  As it happens, most of the people I've worked with, with
>>> very, very few exceptions, are good programmers, the insults
>>> thrown out gratuously by Andrew not withstanding.  (And until
>>> Noah understands this basic principle, he's not going to be able
>>> to effectively lead a team.  Leadership starts with respect for
>>> your subordonnates.)
>> I really don't know where you get off on these accusations but I guess I
>> can't expect any better from you.  It seems clear to me that you're
>> perfectly happy playing the insult game until you run into someone
>> that's just as happy to play and maybe a bit better at it.  I would
>> kindly ask that you actually quote me insulting people or showing
>> disrespect to "subordonnates" but actually backing up your accusations
>> has not been your strong suit.  This is like the times you insisted I
>> write crap code when you'd never even seen one line...more shit for the
>> pile, Kanze.
>>
>> Keep it.  In the words of Overkill:
>>
>> YOU! Got a lot to learn.
>> Your head's up your ass!
>> YOU! Got a lot to learn.
>> You got no class.
>>
>> No class.
> 
> What is with this newsgroup?  People seem to be waiting for an
> opportunity to go at each other's throat.  First there was Mr. Duggar
> who thinks the best way to get someone to admit their mistake
> (legitimate or not) is to humiliate them.  The next is Mr. Roberts
> who, in all this time of lurking in this newsgroup, I have never seen
> agreeing with Mr. Kanze on anything (not that its a bad thing -- I
> just wonder why this kind of language needs to be resorted to).

Well, there's no reason to reply to someone's post to say, "I agree."  I 
have never said Kanze is wrong 100% of the time but there have certainly 
been differences.
> 
> The thing that gets me is I have been following this newsgroup for
> several years.  I have learnt an enormous amount of C++ by simply
> reading posts from James Kanze, Jerry Coffin, Hyman Rosen and others.
> Doesn't that count for a little bit of respect or at least the fact
> they, you know, might actually know what they are talking about?

Sometimes, sometimes not.  Nobody knows everything and nobody has the 
right to act like they do.  Kanze tends to respond to technical 
differences with non-technical arguments.  When someone regularly gets 
into arguments about who's worked with "good programmers" with many 
different opponents there's probably something to look at in the one 
consistent feature of those arguments.  As Despair Inc. says, "The only 
consistent thing in all your broken relationships is you."

   Like
> everyone of us they are going to be wrong from time to time and I have
> personally read quite a few posts where they have freely admitted it.
> But even there they have been more right than wrong.  Why can't we all
> get along?  Is it too much to maintain some civility considering, um,
> we are adults?

I think I have a right to respond to baseless accusations.  Having been 
on the receiving end of such from Kanze many, many times I also tend to 
have a very different view that you do.  Try disagreeing with him 
sometime and then lecture me.  Thanks anyway for the feedback but I 
don't agree with your assessment.

Book suggestion: 201 principles in Software development. The chapter
on management may suit you well.

Rafael

Andrew Tomazos wrote:
> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>> I wasn't going to respond any further here, since the argument
>> is really "Everyone I've ever worked with is incompetent" (from
>> Andrew)
> 
> That is a childish misrepresentation of what I said.  If you don't
> understand where the statement "a good programmer can be 100x
> productive as an average one" comes from than my guess is you haven't
> worked with any *really* good programmers.

Like James, I don't believe one human can be two orders of magnitude 
better at a chosen occupation than another.  The other simply wouldn't 
graduate.  If he or she did and managed to con their way into a job, 
they wouldn't stay employed for long

<snip>

> Programmers vary greatly in their level of productivity (yes as much
> as 100x).  I repeat: I have seen this firsthand, I have heard
> firsthand account, it has been written about in books.

Care to cite the references?

-- 
Ian Collins

"Ian Collins" <ian-news@hotmail.com>

> Like James, I don't believe one human can be two orders of magnitude 
> better at a chosen occupation than another.  The other simply wouldn't 
> graduate.  If he or she did and managed to con their way into a job, they 
> wouldn't stay employed for long

I can't really get this part on magnitudes.

I have seen several (rather say many) programmers, and even more managers, 
whose contribution to the project's progress and success is negative.

Whoever think my experience is unique, please go to thedailywtf.com, to find 
a zillion of reports.

If you just take a plain vanilla honest programmer, who just does the job 
say processing a backlog item every 2 weeks for good -- how his performance 
measures up against that of the draggers-down? 

Balog Pal wrote:
> "Ian Collins" <ian-news@hotmail.com>
> 
>> Like James, I don't believe one human can be two orders of magnitude 
>> better at a chosen occupation than another.  The other simply wouldn't 
>> graduate.  If he or she did and managed to con their way into a job, they 
>> wouldn't stay employed for long
> 
> I can't really get this part on magnitudes.
> 
> I have seen several (rather say many) programmers, and even more managers, 
> whose contribution to the project's progress and success is negative.

That's a fair point but I was using the "typical" programmer as a 
baseline, which was fair considering the original statement was "a good 
programmer can be 100x productive as an average one"

I have seen my fair share of crap programmers, I even made a good living 
cleaning up after one!  I've also learned how to spot them and I'm 
pretty good at weeding them out in interviews.

> If you just take a plain vanilla honest programmer, who just does the job 
> say processing a backlog item every 2 weeks for good -- how his performance 
> measures up against that of the draggers-down? 

It's way better.  But that wasn't the centre of the argument, which used 
  average programmers as the baseline.

-- 
Ian Collins

* Ian Collins:
> Andrew Tomazos wrote:
>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>>> I wasn't going to respond any further here, since the argument
>>> is really "Everyone I've ever worked with is incompetent" (from
>>> Andrew)
>>
>> That is a childish misrepresentation of what I said.  If you don't
>> understand where the statement "a good programmer can be 100x
>> productive as an average one" comes from than my guess is you haven't
>> worked with any *really* good programmers.
> 
> Like James, I don't believe one human can be two orders of magnitude 
> better at a chosen occupation than another.  The other simply wouldn't 
> graduate.  If he or she did and managed to con their way into a job, 
> they wouldn't stay employed for long

Your argument wouldn't be much different with one order of magnitude, and that's 
commonly observed. So where does the argument go wrong? It's simply that the 
argument assumes that the requirements for graduating and holding a job, in a 
technical profession, have to do with productivity and/or quality, a sort of 
monotonically increasing function, whereas in reality there can be little direct 
connection between technical ability and success, and whereas success can have 
more to do with conformance and social issues. In fact, a recent career guide in 
Norwegian "Dagens N�ringsliv", a leading economics newspaper in Norway, 
cautioned strongly against doing too well while at the lower rungs of the ladder 
because one is then viewed as a threat both by co-workers and by one's boss, and 
reader comments were uniformly positive that at last some reality was discussed.


>> Programmers vary greatly in their level of productivity (yes as much
>> as 100x).  I repeat: I have seen this firsthand, I have heard
>> firsthand account, it has been written about in books.
> 
> Care to cite the references?

Third google hit on "programmer productivity", citing e.g. Steve McConnell, 
Randall E. Stross and [clc++m] mod (now inactive) Robert C. Martin: <url: 
http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.

It's so common and well-known that it has its own name.

Note that this fact, the observed reality, doesn't square with your reasoning 
above, and one resolution of that is as I noted above (I'm not saying that 
that's the only explanation, but I think it's the main one).


Cheers & hth.,

- Alf

Ian Collins wrote:
> Andrew Tomazos wrote:
>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>>> I wasn't going to respond any further here, since the argument
>>> is really "Everyone I've ever worked with is incompetent" (from
>>> Andrew)
>>
>> That is a childish misrepresentation of what I said.  If you don't
>> understand where the statement "a good programmer can be 100x
>> productive as an average one" comes from than my guess is you haven't
>> worked with any *really* good programmers.
> 
> Like James, I don't believe one human can be two orders of magnitude 
> better at a chosen occupation than another.

Again it depends on what "better" means.  How are we going to measure 
it?  Are we going to compare someone who's been in the field for 
decades, and constantly making sure their knowledge is current, to 
someone straight out of college?  You would probably get close to 100x 
difference in any method you chose to measure their code quality and 
production.

On the other hand we might not.  The best new meat knows his code.

If we compare two equally experienced developers then there's going to 
be less difference, maybe.  We might be comparing a senior developer 
that works at Intel or some other large, well funded, and sought after 
employer (someone that regularly has to compete and keep learning) to 
someone that's been sitting in a corner at the state for 20 years doing 
just what he needs to get by (not saying everyone at the state is a 
dipshit, but there's certainly more ways for them to hide their 
dipshittedness there).

I'm of the opinion that good developers do something extra on the side 
to keep themselves updated.  They read books, experiment with stuff they 
can't experiment with at work, and they continue to bring in new, fresh 
ideas.  A lot of people are simply not motivated to do this but think 
going to work and getting the job done is enough.  I frankly don't know 
what it's like in the larger companies but I see this quite a lot. 
Nothing wrong with it if that's what you're about but someone who goes 
the extra mile is going to be better (no matter how much of a star you 
were in school) and in many cases that difference will be significant.

   The other simply wouldn't
> graduate.

I don't think we can assume that anymore.  There's many colleges out 
there, and not even getting into diploma mills, that for whatever reason 
seem to graduate people that still can't do the job.

   If he or she did and managed to con their way into a job,
> they wouldn't stay employed for long

Again, it depends.  If you're talking about a big company that has lots 
of money and can hire the best then I'm sure you're right.  In other 
cases employers may tend to make do with who they can get.  You run into 
all sorts of varying degrees of ability in these cases.  The mentoring 
in can be sub-par also because people who've been there for a long time 
may not have had the opportunity to be mentored either.  Not that 
they're bad developers or anything but if you've not had the opportunity 
to learn under someone great you may never reach your potential.

So I think that though the 100x figure is a bit extreme I do believe 
there can be significant differences between developers, especially when 
you don't assume we're talking about some super-shop that only hires the 
best and can afford to do so...and take the time to interview and 
replace people when they don't pan out as expected.  I think many of the 
posters here may forget what the real world looks like because they work 
in a more optimal environment.  The real world is full of people who 
somehow manage to get into positions they can't actually fulfill and 
others who are just plain lazy asses.

Alf P. Steinbach wrote:
> * Ian Collins:
>> Andrew Tomazos wrote:
>>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>>>> I wasn't going to respond any further here, since the argument
>>>> is really "Everyone I've ever worked with is incompetent" (from
>>>> Andrew)
>>>
>>> That is a childish misrepresentation of what I said.  If you don't
>>> understand where the statement "a good programmer can be 100x
>>> productive as an average one" comes from than my guess is you haven't
>>> worked with any *really* good programmers.
>>
>> Like James, I don't believe one human can be two orders of magnitude 
>> better at a chosen occupation than another.  The other simply wouldn't 
>> graduate.  If he or she did and managed to con their way into a job, 
>> they wouldn't stay employed for long
> 
> Your argument wouldn't be much different with one order of magnitude, 
> and that's commonly observed. So where does the argument go wrong? It's 
> simply that the argument assumes that the requirements for graduating 
> and holding a job, in a technical profession, have to do with 
> productivity and/or quality, a sort of monotonically increasing 
> function, whereas in reality there can be little direct connection 
> between technical ability and success, and whereas success can have more 
> to do with conformance and social issues. In fact, a recent career guide 
> in Norwegian "Dagens N�ringsliv", a leading economics newspaper in 
> Norway, cautioned strongly against doing too well while at the lower 
> rungs of the ladder because one is then viewed as a threat both by 
> co-workers and by one's boss, and reader comments were uniformly 
> positive that at last some reality was discussed.

That observation is as old as humanity!  Luckily we don't execute 
threats to the leadership any more.

>>> Programmers vary greatly in their level of productivity (yes as much
>>> as 100x).  I repeat: I have seen this firsthand, I have heard
>>> firsthand account, it has been written about in books.
>>
>> Care to cite the references?
> 
> Third google hit on "programmer productivity", citing e.g. Steve 
> McConnell, Randall E. Stross and [clc++m] mod (now inactive) Robert C. 
> Martin: <url: 
> http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.
> 
> It's so common and well-known that it has its own name.

They don't claim 100:1.

> Note that this fact, the observed reality, doesn't square with your 
> reasoning above, and one resolution of that is as I noted above (I'm not 
> saying that that's the only explanation, but I think it's the main one).

Maybe I should have cited James' favourite caveat - "In well run shops"..


-- 
Ian Collins

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
> On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
> > James Kanze wrote:
> > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > >> James Kanze wrote:
>
> > > I wasn't going to respond any further here, since the argument
> > > is really "Everyone I've ever worked with is incompetent" (from
> > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > Noah). =A0As it happens, most of the people I've worked with, with
> > > very, very few exceptions, are good programmers, the insults
> > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > Noah understands this basic principle, he's not going to be able
> > > to effectively lead a team. =A0Leadership starts with respect for
> > > your subordonnates.)
>
> > I really don't know where you get off on these accusations but I guess =
I
> > can't expect any better from you. =A0It seems clear to me that you're
> > perfectly happy playing the insult game until you run into someone
> > that's just as happy to play and maybe a bit better at it. =A0I would
> > kindly ask that you actually quote me insulting people or showing
> > disrespect to "subordonnates" but actually backing up your accusations
> > has not been your strong suit. =A0This is like the times you insisted I
> > write crap code when you'd never even seen one line...more shit for the
> > pile, Kanze.
>
> > Keep it. =A0In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup? =A0People seem to be waiting for an
> opportunity to go at each other's throat.

There is a fair amount of incivility out there these days.
Close to a year ago I posted a link to a news story
about conflict between older and younger pilots.  The
younger were attempting to bully the older into early
retirement.   Most companies/politicians pay lip
service to ethics and integrity, but few back it up.
In "The Abolition of Man" by C.S. Lewis he observed
in the 1940s that technological integration was
leading to societal disintegration.


"Most men will proclaim every one his own goodness:
but a faithful man who can find?"  Proverbs 20:6

On Aug 5, 5:29=A0pm, Brian Wood <c...@mailvault.com> wrote:
> On Aug 5, 11:58=A0am, Dilip <rdil...@lycos.com> wrote:
>
>
>
>
>
> > On Aug 5, 11:08=A0am, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > > James Kanze wrote:
> > > > On Jul 30, 5:04 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> > > >> James Kanze wrote:
>
> > > > I wasn't going to respond any further here, since the argument
> > > > is really "Everyone I've ever worked with is incompetent" (from
> > > > Andrew) and "I'm just being argumentive if I dispute this" (from
> > > > Noah). =A0As it happens, most of the people I've worked with, with
> > > > very, very few exceptions, are good programmers, the insults
> > > > thrown out gratuously by Andrew not withstanding. =A0(And until
> > > > Noah understands this basic principle, he's not going to be able
> > > > to effectively lead a team. =A0Leadership starts with respect for
> > > > your subordonnates.)
>
> > > I really don't know where you get off on these accusations but I gues=
s I
> > > can't expect any better from you. =A0It seems clear to me that you're
> > > perfectly happy playing the insult game until you run into someone
> > > that's just as happy to play and maybe a bit better at it. =A0I would
> > > kindly ask that you actually quote me insulting people or showing
> > > disrespect to "subordonnates" but actually backing up your accusation=
s
> > > has not been your strong suit. =A0This is like the times you insisted=
 I
> > > write crap code when you'd never even seen one line...more shit for t=
he
> > > pile, Kanze.
>
> > > Keep it. =A0In the words of Overkill:
>
> > > YOU! Got a lot to learn.
> > > Your head's up your ass!
> > > YOU! Got a lot to learn.
> > > You got no class.
>
> > > No class.
>
> > What is with this newsgroup? =A0People seem to be waiting for an
> > opportunity to go at each other's throat.
>
> There is a fair amount of incivility out there these days.
> Close to a year ago I posted a link to a news story
> about conflict between older and younger pilots. =A0The
> younger were attempting to bully the older into early
> retirement. =A0 Most companies/politicians pay lip
> service to ethics and integrity, but few back it up.
> In "The Abolition of Man" by C.S. Lewis he observed
> in the 1940s that technological integration was
> leading to societal disintegration.
>
> "Most men will proclaim every one his own goodness:
> but a faithful man who can find?" =A0Proverbs 20:6- Hide quoted text -
>
> - Show quoted text -

I meant to include my signature.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

In article <4a79eb17$0$7448$cc2e38e6@news.uslec.net>, 
roberts.noah@gmail.com says...

[ ... ]

> So I think that though the 100x figure is a bit extreme I do believe 
> there can be significant differences between developers, especially when 
> you don't assume we're talking about some super-shop that only hires the 
> best and can afford to do so...and take the time to interview and 
> replace people when they don't pan out as expected. 

In _The Mythical Man-Month_, Brooks quotes a study by Sackman, 
Erikson, and Grant, giving a factor of approximately 10x in terms of 
productivity, and 5x in terms of program speed and space.

That study, however, was conducted in 1968, and (a point that's often 
ignored) was originally written as a comparison of online to offline 
programming. That points (at least to some degree) to the difficulty 
of extrapolating from that study to much that's meaningful about 
current practice. For the sake of argument, however, let's assume 
that it gives a rough idea of the expected range of "native ability" 
of programmer.

I do think a couple of factors are worth considering, however. First 
of all, in 1968 there were relatively few programmers, and I'd guess 
that most had formal background in engineering, mathematic, or both. 
In 1968, there was virtually no such thing as a college with a major 
in computer science, but today there are quite a few. Unfortunately, 
for every good one today, there's at least one more that'll give a 
diploma to anybody with money.

That's likely to lead to a larger range of variation in both 
directions: there are almost certainly more people who picked 
programming as a job simply because it pays well and such (even 
though they may well lack any aptitude for the job at all). On the 
other side, there's a whole lot that can be accomplished by applying 
known, proven principles today that hadn't been invented at all in 
1968. The average has probably stated about the same, but the best 
certainly have a great deal more education now, while the worst 
probably have less.

Second, there are a lot more specialized tools reasonably easily 
available today than in 1968. Some maintain a high level of awareness 
of those tools, and are likely to apply them (to at least some 
degree) when they're at least reasonably appropriate. Others barely 
know a single language, and have no idea when another tool would be 
more appropriate.

Either of these could probably lead to a 2x factor by itself, so 
multiplying the three together, we've accounted for a 40x factor -- 
but this would still be between the best and the worst, NOT between 
the best and the average.

Assuming relatively minimal skew and such, that gives a difference 
between the top and the average of ~6.3x (no, not 20x -- the factors 
multiply, so it's sqrt(40), not 40/2).

While there are certainly other factors I haven't tried to take into 
account, I think those are probably the biggest ones. A 10x 
difference between the top and the average might be believable, but 
100x strikes me as more than just a bit extreme -- it sounds 
downright unbelievable.

I'd also note that there's at least one factor working in the 
opposite direction: we routinely expect systems today to be both 
larger and more reliable than any but a tiny percentage were in the 
1960's. In a large, high-reliability system, it's MUCH more difficult 
for even the best coder to be drastically better than an average one. 
In a large system, processes and procedures take up a larger 
percentage of overall time -- and in the process the time taken for 
the coding itself takes up a smaller percentage.

Assume programmer A could find and fix a particular bug in 6 minutes, 
but programmer B would take a full hour to do the same thing. So far 
A is 10x more productive. Now we have a code review where we have 
(say) 10 people look over the code. First we have 10 minutes where 
people discuss the weather, wait for the people who are inevitably a 
few minutes late, etc. Then the programmer spends 20 minutes 
outlining the bug and the change -- and since the meeting involves 
about the same level of people (overall) either way, A can't explain 
it a whole lot faster than B could.

Then the code is reviewed -- again, since about the same people are 
involved either way, the review takes about the same time either way. 
To give him the benefit of the doubt, let's assume A figured out a 
much simpler way of fixing the bug, so for A's fix, the meeting 
(overall) runs 45 minutes, but for B's fix, it runs an hour and a 
half.

In overall productivity, A's change took .1 + .75*10 = 7.6 man hours. 
B's change took 1 + 1.5*10 = 16 man hours. The 10x factor for the 
original change is now just over 2x -- and in all honesty, even 
that's probably being generous.

This also explains why you want formal reviews to involve fewer 
people if possible -- in the example above, if the review team was 5 
people instead of 10, the numbers would work out to 3.85 and 8.5 man-
hours respectively. The overall difference is still well under 3:1 
though...

P.S. If you really object to "man-hours" please feel free to read 
those as "person-hours". Personally, I find "person-hours" much 
clumsier to say -- and the percentage of programmers I've worked with 
who were female was tiny anyway.

-- 
    Later,
    Jerry.

Jerry Coffin wrote:

> In overall productivity, A's change took .1 + .75*10 = 7.6 man hours. 
> B's change took 1 + 1.5*10 = 16 man hours. The 10x factor for the 
> original change is now just over 2x -- and in all honesty, even 
> that's probably being generous.

OK, this is pretty good analysis but one thing it leaves out maybe is 
the time that a "bad" programmer can add to discussion time.  If you 
have to describe in excruciating detail everything for person B so they 
can competently understand what you've done whereas with person A you 
can discuss things in terms of patterns and other domain specific 
language...there's going to be time added there too.

In other words, a "bad" programmer may just plain not get it and may 
increase the time necessary for code reviews by 2+ times as well.

Still, as you say...100x is overboard.  Not sure it was meant as an 
accurate number, being seeming pulled from the sky (or some other 
place).  To be 100x it would have to take one person two weeks what it 
would another person an hour.

Actually...come to think of it...bah, but that was due to the developer 
running off and "researching" for two weeks and never accomplishing 
anything.  More a management issue I think.  I think you have to get an 
average programmer with poor attention and add a bad manager to get 100x.
> 
> P.S. If you really object to "man-hours" please feel free to read 
> those as "person-hours". Personally, I find "person-hours" much 
> clumsier to say -- and the percentage of programmers I've worked with 
> who were female was tiny anyway.
> 

We've interviewed 2 in the four years I've been here.  One was straight 
out of college and we got her as an intern.  The other one did not 
accept our offer.  She was impressive, it's really too bad.

In article <4a7a1b42$0$7464$cc2e38e6@news.uslec.net>, 
roberts.noah@gmail.com says...
> 
> Jerry Coffin wrote:
> 
> > In overall productivity, A's change took .1 + .75*10 = 7.6 man hours. 
> > B's change took 1 + 1.5*10 = 16 man hours. The 10x factor for the 
> > original change is now just over 2x -- and in all honesty, even 
> > that's probably being generous.
> 
> OK, this is pretty good analysis but one thing it leaves out maybe is 
> the time that a "bad" programmer can add to discussion time.  If you 
> have to describe in excruciating detail everything for person B so they 
> can competently understand what you've done whereas with person A you 
> can discuss things in terms of patterns and other domain specific 
> language...there's going to be time added there too.
> 
> In other words, a "bad" programmer may just plain not get it and may 
> increase the time necessary for code reviews by 2+ times as well.

True -- but it remains true for _all_ the code reviews, not just when 
he writes the code. IOW, this affects essentially _everybody's_ 
productivity, not just his own (at least everybody involved in code 
reviews along with him -- but probably almost anybody who has to 
interact with him at all). It's also (one of several reasons) why a 
poor programmer can be _so_ detrimental to a team.
 
> Still, as you say...100x is overboard.  Not sure it was meant as an 
> accurate number, being seeming pulled from the sky (or some other 
> place).  To be 100x it would have to take one person two weeks what it 
> would another person an hour.

Right -- while that's believable in special cases, it's much less so 
on a consistent, ongoing basis.

> Actually...come to think of it...bah, but that was due to the developer 
> running off and "researching" for two weeks and never accomplishing 
> anything.  More a management issue I think.  I think you have to get an 
> average programmer with poor attention and add a bad manager to get 100x.

As I said, it can happen once in a while, but maintaining it for long 
periods of time is a whole different story.

There are really two main points though: 1) as a project grows, the 
percentage of time actually spent writing code shrinks -- and the 
differences in productivity between programmers shrinks at about the 
same rate. 2) the square root involved when dealing with the factors 
makes the factor between the average and the top or bottom seem quite 
small compared to the factor between the top and the bottom.

-- 
    Later,
    Jerry.

Noah Roberts wrote:

> We did stand ups here and they were a total waste of time for us.  We
> got the same stuff I got when just asking, "How are things going?"
> People respond with, "fine," and in stand-ups that would be, "I'm
> doing backlog item XXX and everything's going great."  Everyone knows
> you're doing backlog item XXX and the later is not informative.

Exactly. Then ask for more details. If it's a bug "could you reproduce
it?" or "already have an idea what's the problem?", if it's a new
feature, "any ideas on how to do it?", "made any progress on the ideas
we talked about yesterday?" -- or whatever, but /specific/, until /you/
are satisfied with the specificness of the information (not necessarily
with the answers). 

You're the leader, so it's on you to lead the conversation... :) This
position is not only about being a higher skilled programmer (actually,
that's the architect's job, not the team leader's job, if you have the
luxury of having both), it's about being able to "lead" -- which means
being able to deal with, in one way or another, shortcomings (real or
perceived) of team members (and of higher-up management :).

Patience and absence of personal judgment are really important for this.

Gerhard

Alf P. Steinbach wrote:

>> Care to cite the references?
> 
> Third google hit on "programmer productivity", citing e.g. Steve McConnell, 
> Randall E. Stross and [clc++m] mod (now inactive) Robert C. Martin: <url: 
> http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.
> 
> It's so common and well-known that it has its own name.

They of course claim about 20:1 from best to worst, while Andrew claims
100:1 from best to average. 

Since you seem to defend this viewpoint... do you really think that
there is somebody who can in 1 day do what an /average/ (not "bad" or
"the worst") programmer can achieve in 4 months? (In terms of
programming, of course, not making money or impressing girls... :)

Gerhard

Dilip work:
> Noah Roberts work:
> > Keep it.  In the words of Overkill:
>
> > YOU! Got a lot to learn.
> > Your head's up your ass!
> > YOU! Got a lot to learn.
> > You got no class.
>
> > No class.
>
> What is with this newsgroup?  People seem to be waiting for an
> opportunity to go at each other's throat. First there was Mr. Duggar
> who thinks the best way to get someone to admit their mistake
> (legitimate or not) is to humiliate them. The next is Mr. Roberts
> who, in all this time of lurking in this newsgroup, I have never seen
> agreeing with Mr. Kanze on anything (not that its a bad thing -- I
> just wonder why this kind of language needs to be resorted to).
>
> The thing that gets me is I have been following this newsgroup for
> several years.  I have learnt an enormous amount of C++ by simply
> reading posts from James Kanze, Jerry Coffin, Hyman Rosen and others.

One of the most impressive things about James is that he rarely
(if ever) speculates beyond the bounds of his knowledge without
qualification. In other words, if he makes a factual claim, you
can bet that he *knows* it to be true first hand. I keep hoping
that he'll write a book someday covering his extensive practical
experience with C++.

In contrast to James, Jerry has lately been speculating beyond
the limits of his knowledge claiming falsehoods as facts. Such
misinformation is pedagogically dangerous when coming from one
who, as you rightly recognize, has otherwise (and often) shown
knowledge and expertise;  because,  you see, too many students
will naively believe his misinformation simply out of respect.
And, yes, when such a man is too proud to admit he is wrong, I
think extreme measures such as I took are warranted.

> Doesn't that count for a little bit of respect or at least the fact
> they, you know, might actually know what they are talking about? Like

Certainly. However, in the uncommon cases when they are wrong,
they must have the guts to admit it (publicly) or they expose
themselves to well deserved and justified attack.

> everyone of us they are going to be wrong from time to time and I have
> personally read quite a few posts where they have freely admitted it.

Please post some examples of Jerry Coffin freely admitting he
was wrong regarding a non-trivial matter which he debated.

> But even there they have been more right than wrong.

I don't know what that means. You mean they claimed N things
but were wrong about only m where m << N? Regardless how large
m is, anyone must have the guts to admit when they are wrong
and especially those who are "respected" or they damage the
students who believe them.

> Why can't we all get along? Is it too much to maintain some
> civility considering, um, we are adults?

There is far too much whining about incivility. Look, it's a
rough world. Instead of crying and moping, one should grow some
armor and balls. For example, Jerry called me a "pathetic worm",
a completely unoriginal and lame insult. Now, what am I going to
do about it, tell the school principal? Throw some equally lame
and unoriginal insult back at him? Instead, I continued to focus
on relentlessly dissecting and exposing his feeble attempts to
hide the demonstrable fact that he was wrong. C'est la vie.

http://www.youtube.com/watch?v=unkIVvjZc9Y

KHD

PS. Jerry's post here

http://groups.google.com/group/comp.lang.c++/msg/4762d9a5d9f98f44

was absolutely fantastic. So one can hope his other recent
misinformation was just a temporary glitch.

* Gerhard Fiedler:
> Alf P. Steinbach wrote:
> 
>>> Care to cite the references?
>> Third google hit on "programmer productivity", citing e.g. Steve McConnell, 
>> Randall E. Stross and [clc++m] mod (now inactive) Robert C. Martin: <url: 
>> http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.
>>
>> It's so common and well-known that it has its own name.
> 
> They of course claim about 20:1 from best to worst, while Andrew claims
> 100:1 from best to average. 
> 
> Since you seem to defend this viewpoint... do you really think that
> there is somebody who can in 1 day do what an /average/ (not "bad" or
> "the worst") programmer can achieve in 4 months?

No, not in general.

And by conventional metrics it can even go the other way, because conventional 
metrics do not account for future maintainability (even within the same cycle) 
nor, as I think it was James who remarked, do conventional metrics measure the 
effect on the team as a whole of having someone good present.

And in many cases, doing grudge work, by conventional metrics the good 
programmers can (apparently) do worse than the average ones. Because the 
conventional metrics mostly measure typing and editing speed. The good ones will 
be partially occupied helping the others do well and making sure that 
immediately upcoming requirements are supported, hence will have less time for 
typing and may have more to type. The super archeologist is not much better at 
digging with teaspon than the grad student. By conventional metrics the super 
archeologist may appear to do worse at this task.

And of course, if the super archeologist is set to digging with teaspon for an 
extended period of time, and only allowed to do that, under micro management, 
then some discontent will probably set in, and the super archeologist may be 
*less* effective than others, and may then have negative effect on the team.

But in rare cases a minute-to-week factor can happen for the things that an 
average programmer simply isn't able to do, or is blind to (in that case the 
factor can, of course, be arbitrarily large...). This I know because I've both 
observed it and done it. Relating one concrete case: some colleagues of mine 
were stuck with a strange error in a Windows-based client software, and I was 
called upon to help them out. On arriving at the site I just looked at the code 
on the screen and, since I knew these guys :-), I immediately spotted an 
uninitialized variable (they'd struggled with this for about a week). That was 
about 1 minute's work, and accounted for most of the problem. But there was 
still something not working, inexplicably since it had worked splendidly. I 
couldn't figure that out even after an hour. I took a stroll trough the locales 
just to clear my mind, and spotted my old mentor at the firm. Talking with him 
helped (good programmers know good programmers and can communicate effectively 
with them, also a factor!), and he mentioned a change in functionality in 
Windows 2000, which I didn't know about. And that was it, and now we're into, 
say, 1.5 hour from arrival, compared to a week already spent on the problem by a 
team of four.

But I've far more often been in the position of apparently being a drag, by 
conventional metrics. And in both cases the reason has been the same: that some 
things have simply not been understood by the average ones, and intentionally 
ignored by some of those with the necessary understanding. The problem of 
enlightening others, even about such simple things that using strong typing 
helps (like, enum instead of int, or T* instead of void*), is one I haven't yet 
cracked. There is a name for this effect too, the "tragedy of the commons", 
where most everyone exploit the immediate gains to be had in the environment, 
causing severe degradation of that environment to the detriment of all (the 
quick local gains are *relative* to the environment, while a more rational 
approach would improve the environment and yield much higher gains overall).


> (In terms of
> programming, of course, not making money or impressing girls... :)

There the factor is, I think, about six orders of magnitude. :-)


Cheers,

- Alf

Noah Roberts wrote:
> Ian Collins wrote:
>> Andrew Tomazos wrote:
>>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>>>> I wasn't going to respond any further here, since the argument
>>>> is really "Everyone I've ever worked with is incompetent" (from
>>>> Andrew)
>>>
>>> That is a childish misrepresentation of what I said.  If you don't
>>> understand where the statement "a good programmer can be 100x
>>> productive as an average one" comes from than my guess is you haven't
>>> worked with any *really* good programmers.
>>
>> Like James, I don't believe one human can be two orders of magnitude 
>> better at a chosen occupation than another.
> 
> Again it depends on what "better" means.  How are we going to measure 
> it?  Are we going to compare someone who's been in the field for 
> decades, and constantly making sure their knowledge is current, to 
> someone straight out of college?  You would probably get close to 100x 
> difference in any method you chose to measure their code quality and 
> production.

In answer to that, I'd point you to the original claim: "a good 
programmer can be 100x productive as an *average* one".

So an experiment might be to take a randomly selected group of 10 
programmers and compare their team output over ten day with the mythical 
super programmer who should produce the same output in one.  A larger 
sample size might give a better average..

-- 
Ian Collins

Ian Collins <ian-news@hotmail.com> writes:

> Balog Pal wrote:
>> "Ian Collins" <ian-news@hotmail.com>
>>
>>> Like James, I don't believe one human can be two orders of
>>> magnitude better at a chosen occupation than another.  The other
>>> simply wouldn't graduate.  If he or she did and managed to con
>>> their way into a job, they wouldn't stay employed for long
>>
>> I can't really get this part on magnitudes.
>>
>> I have seen several (rather say many) programmers, and even more
>> managers, whose contribution to the project's progress and success
>> is negative.
>
> That's a fair point but I was using the "typical" programmer as a
> baseline, which was fair considering the original statement was "a
> good programmer can be 100x productive as an average one"
>
> I have seen my fair share of crap programmers, I even made a good
> living cleaning up after one!  I've also learned how to spot them and
> I'm pretty good at weeding them out in interviews.
>
>> If you just take a plain vanilla honest programmer, who just does
>> the job say processing a backlog item every 2 weeks for good -- how
>> his performance measures up against that of the draggers-down? 
>
> It's way better.  But that wasn't the centre of the argument, which
> used average programmers as the baseline.

The 100-fold factor may integrate the fact that the good programmer
may also choose more productive tools.  So all other things equal, he
will be 10x more productive than your baseline programmer, but if in
"multiplication" he chooses to program in Lisp rather than C++, he
will easily be 100x more productive.

Have a look at the figure #3 on page 9 of this report:

    http://www.haskell.org/papers/NSWC/jfp.ps  

Notice that it has been written by a Haskell advocate.  Compare the
development time of Lisp vs other programming languages...


-- 
__Pascal Bourguignon__

Pascal J. Bourguignon wrote:
> 
> The 100-fold factor may integrate the fact that the good programmer
> may also choose more productive tools.  So all other things equal, he
> will be 10x more productive than your baseline programmer, but if in
> "multiplication" he chooses to program in Lisp rather than C++, he
> will easily be 100x more productive.
> 
> Have a look at the figure #3 on page 9 of this report:
> 
>     http://www.haskell.org/papers/NSWC/jfp.ps  
> 
> Notice that it has been written by a Haskell advocate.  Compare the
> development time of Lisp vs other programming languages...

On an embedded system?  He will probably be 100x slower!

-- 
Ian Collins

Ian Collins <ian-news@hotmail.com> writes:

> Pascal J. Bourguignon wrote:
>>
>> The 100-fold factor may integrate the fact that the good programmer
>> may also choose more productive tools.  So all other things equal, he
>> will be 10x more productive than your baseline programmer, but if in
>> "multiplication" he chooses to program in Lisp rather than C++, he
>> will easily be 100x more productive.
>>
>> Have a look at the figure #3 on page 9 of this report:
>>
>>     http://www.haskell.org/papers/NSWC/jfp.ps  
>>
>> Notice that it has been written by a Haskell advocate.  Compare the
>> development time of Lisp vs other programming languages...
>
> On an embedded system?   He will probably be 100x slower!

_development_ _time_!

We are not discussing speed of compiled programs (we could and I could
provide benchmarks showing Lisp programs faster than their counterpart
C programs, but that's not the subject).

-- 
__Pascal Bourguignon__

"Ian Collins" <ian-news@hotmail.com>
> Balog Pal wrote:
>> "Ian Collins" <ian-news@hotmail.com>
>>
>>> Like James, I don't believe one human can be two orders of magnitude 
>>> better at a chosen occupation than another.  The other simply wouldn't 
>>> graduate.  If he or she did and managed to con their way into a job, 
>>> they wouldn't stay employed for long
>>
>> I can't really get this part on magnitudes.
>>
>> I have seen several (rather say many) programmers, and even more 
>> managers, whose contribution to the project's progress and success is 
>> negative.
>
> That's a fair point but I was using the "typical" programmer as a 
> baseline, which was fair considering the original statement was "a good 
> programmer can be 100x productive as an average one"

Aha, I thought the comparision is about the edges. If the left point is 
'average', no wonder you are in the swamp with discussion.  As it is even 
more arbitrary to pick up a supposed middle.  As to that we need a good 
estimate on the ration of the 'crap programmers'.  What is IMO obvoiusly 
huge, if you look at the applications too.  Or if you calculate some weighed 
contribuition, and the overall failure rate of projects (that is over half 
in the last data I saw), it is easy to come up, the middle point still has 
negative contribution.  Or something close to zero.   That can explain huge 
figures in the diff.

IOW before bickering on figures, try to reach consensus what you call 
average. ;-)


 

"Alf P. Steinbach" <alfps@start.no>
> In fact, a recent career guide in Norwegian "Dagens N�ringsliv", a leading 
> economics newspaper in Norway, cautioned strongly against doing too well 
> while at the lower rungs of the ladder because one is then viewed as a 
> threat both by co-workers and by one's boss, and reader comments were 
> uniformly positive that at last some reality was discussed.

"Some" reality?  This is a fundamental thing, well described for long in 
Peter principle.

In a workplace that has a hierarchy, and where the boss is not the owner, it 
absolutely kicks.

An employee's first priority is his position in the majority of cases, not 
some abstract values like (even if painted on each wall) like integrity, 
quality, satisaction of the customer, etc.

"Noah Roberts" <roberts.noah@gmail.com>
> Jerry Coffin wrote:
>
>> In overall productivity, A's change took .1 + .75*10 = 7.6 man hours. B's 
>> change took 1 + 1.5*10 = 16 man hours. The 10x factor for the original 
>> change is now just over 2x -- and in all honesty, even that's probably 
>> being generous.
>
> OK, this is pretty good analysis but one thing it leaves out maybe is the 
> time that a "bad" programmer can add to discussion time.

I'd approach from the other direction.  The average programmer planted the 
otiginal bug in the code, being unaware of stuff like 'you initialize 
variables'  'you read the F*ing warnings', and so on.   The bug caused the 
10m or 60m or 10h or 20h or whatever much time that contributes nothing to 
value.

The good guy just followed the WAY and submitted the code without those 
bugs. (And very likely pushed some nearby fellows toward the WAY too.)

I observed organisations, especially bosses tend to not calculate with 
prevention at all.
Instead, measuring 'hard work' in the amount of visible sweat.   :(

Pascal J. Bourguignon wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> Pascal J. Bourguignon wrote:
>>> The 100-fold factor may integrate the fact that the good programmer
>>> may also choose more productive tools.  So all other things equal, he
>>> will be 10x more productive than your baseline programmer, but if in
>>> "multiplication" he chooses to program in Lisp rather than C++, he
>>> will easily be 100x more productive.
>>>
>>> Have a look at the figure #3 on page 9 of this report:
>>>
>>>     http://www.haskell.org/papers/NSWC/jfp.ps  
>>>
>>> Notice that it has been written by a Haskell advocate.  Compare the
>>> development time of Lisp vs other programming languages...
>> On an embedded system?   He will probably be 100x slower!
> 
> _development_ _time_!
> 
> We are not discussing speed of compiled programs (we could and I could
> provide benchmarks showing Lisp programs faster than their counterpart
> C programs, but that's not the subject).
> 
You said "the good programmer may also choose more productive tools". 
Do you know any good Lisp compilers and tool chains for embedded targets?

-- 
Ian Collins

On 6 ao=FBt, 12:50, Ian Collins <ian-n...@hotmail.com> wrote:
> Pascal J. Bourguignon wrote:
> > Ian Collins <ian-n...@hotmail.com> writes:
>
> >> Pascal J. Bourguignon wrote:
> >>> The 100-fold factor may integrate the fact that the good programmer
> >>> may also choose more productive tools. =A0So all other things equal, =
he
> >>> will be 10x more productive than your baseline programmer, but if in
> >>> "multiplication" he chooses to program in Lisp rather than C++, he
> >>> will easily be 100x more productive.
>
> >>> Have a look at the figure #3 on page 9 of this report:
>
> >>> =A0 =A0http://www.haskell.org/papers/NSWC/jfp.ps=A0
>
> >>> Notice that it has been written by a Haskell advocate. =A0Compare the
> >>> development time of Lisp vs other programming languages...
> >> On an embedded system? =A0 He will probably be 100x slower!
>
> > _development_ _time_!
>
> > We are not discussing speed of compiled programs (we could and I could
> > provide benchmarks showing Lisp programs faster than their counterpart
> > C programs, but that's not the subject).
>
> You said "the good programmer may also choose more productive tools".
> Do you know any good Lisp compilers and tool chains for embedded targets?

Don't ask for it, you may get it:

You can compile lisp to C and use any tool chain you like:
http://ecls.sourceforge.net/
http://www.dinukai.org/programming/scheme/hobbit/hobbit_f.html

There is also a version for micro controler:
http://w3.ift.ulaval.ca/~dadub100/files/HOSC.pdf

--
Michael

Ian Collins <ian-news@hotmail.com> writes:

> Pascal J. Bourguignon wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Pascal J. Bourguignon wrote:
>>>> The 100-fold factor may integrate the fact that the good programmer
>>>> may also choose more productive tools.  So all other things equal, he
>>>> will be 10x more productive than your baseline programmer, but if in
>>>> "multiplication" he chooses to program in Lisp rather than C++, he
>>>> will easily be 100x more productive.
>>>>
>>>> Have a look at the figure #3 on page 9 of this report:
>>>>
>>>>     http://www.haskell.org/papers/NSWC/jfp.ps  
>>>>
>>>> Notice that it has been written by a Haskell advocate.  Compare the
>>>> development time of Lisp vs other programming languages...
>>> On an embedded system?   He will probably be 100x slower!
>>
>> _development_ _time_!
>>
>> We are not discussing speed of compiled programs (we could and I could
>> provide benchmarks showing Lisp programs faster than their counterpart
>> C programs, but that's not the subject).
>>
> You said "the good programmer may also choose more productive
> tools". Do you know any good Lisp compilers and tool chains for
> embedded targets?

"Embedded targets" is too vague.  

For example, Common Lisp has been used in the Deep Space 1 sonde.
This is definitively "embedded" software for me.  AFAIK, it was a
standard commercial CL implementation that was used.

http://ti.arc.nasa.gov/m/tech/rse/publications/papers/IEEE1999/Autonomy.pdf
http://www-aig.jpl.nasa.gov/public/papers/rax-results-isairas99.ps 

For more restricted targets, Lisp can be used to actually generate the
code, without installing a whole implementation on the target.  An
example of this kind of deployment would be in the game market, where
NaughtyDog generated a PS2 game with lisp.

http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

You don't put a C compiler in a PIC, there's no reason why you'd put a
Lisp compiler there either.  But you might be able to produce the PIC
code more easily using tools written in Lisp than with a C compiler.


-- 
__Pascal Bourguignon__

On Aug 6, 7:57=A0am, Ian Collins <ian-n...@hotmail.com> wrote:
> Noah Roberts wrote:
> > Ian Collins wrote:
> >> Andrew Tomazos wrote:
> >>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
> >>>> I wasn't going to respond any further here, since the argument
> >>>> is really "Everyone I've ever worked with is incompetent" (from
> >>>> Andrew)
>
> >>> That is a childish misrepresentation of what I said. =A0If you don't
> >>> understand where the statement "a good programmer can be 100x
> >>> productive as an average one" comes from than my guess is you haven't
> >>> worked with any *really* good programmers.
>
> >> Like James, I don't believe one human can be two orders of magnitude
> >> better at a chosen occupation than another.
>
> > Again it depends on what "better" means. =A0How are we going to measure
> > it? =A0Are we going to compare someone who's been in the field for
> > decades, and constantly making sure their knowledge is current, to
> > someone straight out of college? =A0You would probably get close to 100=
x
> > difference in any method you chose to measure their code quality and
> > production.
>
> In answer to that, I'd point you to the original claim: "a good
> programmer can be 100x productive as an *average* one".
>
> So an experiment might be to take a randomly selected group of 10
> programmers and compare their team output over ten day with the mythical
> super programmer who should produce the same output in one. =A0A larger
> sample size might give a better average..

I haven't got a lot of time unfortunately, so I must be brief.

In trying to understand where the 100x factor comes from consider:

- How long does it take to locate an elusive intermittent bug in a
large codebase?  Are some people better/faster at this than others?
Why?

- When selecting an object model to implement a given interface/
contract, what impact on productivity will be seen by selecting a
really good one over just a mediocre one?

- How much more valuable is good software than average software?

- How much of an productivity impact does creating a tool to do a
repetitive task have over just doing the task manually?

- Do some people find reading other peoples code (reverse engineering)
easier than others?  Do well-chosen tools help?  How about a near
photographic memory?  How about a speed reader?

- If someone were to constantly type at 100 wpm for 10 hours straight,
how many lines of code could they write?  How many lines of code does
an average programmer write in 10 hours?  Why the huge difference?
What are they doing all this time they are not typing away?

The fact is that the bottleneck in writing software is to a large
extent "creative", in the same way that a mathematician thinks of
proofs by being "creative".  It is not well-understood why some people
are better at this than others, even two programmers with equal
experience and the same access to training/eduction/mentorship can
exhibit large differences in talent.  Some conjecture that it is the
result of early childhood or genetics or some combination thereof.

Have a look at the results of one of the completed marathon matches at
TopCoder.com.  You can see the problem statement, the finalists and
their code.  Notice how the winning entry varies both in performance
and how the code is written from say one of the average entries.
Clearly this is just a microcosm, but you can still tangibly see the
"100x phenomenon" at work.

Now consider:

1. Get the winner of the recent TopCoder marathon match "Fred".
2. Get the next problem statement.
3. Give Fred a day to do it.
4. Assemble a team of 10 average programmers - give them 10 days to do
it.
5. See who wins.

My money is on Fred.

Really have to go now!!

Enjoy,
Andrew.

In article <h5eao3$2ado$1@news.ett.com.ua>, pasa@lib.hu says...

[ ... ]

> I observed organisations, especially bosses tend to not calculate
> with prevention at all. Instead, measuring 'hard work' in the
> amount of visible sweat.   :(

You may have seen it before, but I'm reminded of the parable of the 
two programmers:

http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/Th
e%20Parable%20of%20the%20Two%20Programmers.html

Fun (and funny) but with quite a bit of truth as well...

-- 
    Later,
    Jerry.

In article <7cljlxicei.fsf@pbourguignon.anevia.com>,=20
pjb@informatimago.com says...

[ ... ]

> Have a look at the figure #3 on page 9 of this report:
>=20
>     http://www.haskell.org/papers/NSWC/jfp.ps =20
>=20
> Notice that it has been written by a Haskell advocate.  Compare the
> development time of Lisp vs other programming languages...

To get anything meaningful, you need to look at more than just that=20
one figure. First, you need to take into account that this was=20
development of a prototype, not real code. Second, you need to look=20
at the date on the paper -- 1994. Third, you also have to note that=20
none of the languages used was really Lisp as most people would=20
understand the term -- the only one that even resembled Lisp was=20
"relational lisp", which is: "[...] a language developed at ISI, is=20
essentially Lisp enhanced with notions of ?relational abstraction:? a=20
database-like facility having a logic-programming feel." Finally,=20
it's worth noting that they openly admit that the programs weren't=20
seriously tested, and "some of the prototypes did not actually=20
execute" (though they don't seem to identify which those were).

The date means what it calls C++ bore little resemblance to what we=20
use today -- in particular, its standard library was probably just a=20
C library plus iostreams. For a large project, that wouldn't=20
necessarily make a huge difference, but in such a small prototype as=20
this, the time and code to handle something as simple as a linked=20
list makes a _huge_ difference.

The prototype nature (and possible lack of execution) leaves us with=20
little assurance that the Lisp prototype actually worked. Given that=20
they clearly state that the author of the Lisp prototype attended a 4=20
hour kickoff meeting, but only reports 3 hours for development, means=20
that (at least as such things are normally measured) the three hours=20
is clearly incorrect -- four hours is the absolute minimum, and seven=20
is much more likely.

In contrast to any of the others, they note that the C++ version=20
included not only the program itself, but a ~600-line test harness.=20
That tends to suggest that 1) unlike at least some of the others, the=20
C++ version probably did execute, and 2) was probably much closer to=20
production code.

As far as the Lisp usage goes, we're left with insufficient=20
information to guess how much difference it's deviation from=20
"normal" Lisps made. First, we don't really have a good idea of what=20
"essentially Lisp" means, and second we don't know whether, and if so=20
how much, they used the relational capability of the language. If one=20
were to use CL (for example) the development time _might_ be almost=20
identical -- but it might just about easily be dramatically longer.

All in all, it's an interesting paper, and I'm glad you posted the=20
link -- but I don't think it provides much support for conclusions=20
about C++ or Lisp.

--=20
    Later,
    Jerry.

"Andrew Tomazos" <andrew@tomazos.com>

>>
Now consider:

1. Get the winner of the recent TopCoder marathon match "Fred".
2. Get the next problem statement.
3. Give Fred a day to do it.
4. Assemble a team of 10 average programmers - give them 10 days to do
it.
5. See who wins.
My money is on Fred.
<<

Better yet, define the accept requirements harshly. [Without telling, as it 
must be the notm, isn't it?]. I.e. that you will pass the 'product' all 
kinds of inputs, and a single crash or misbehavior is considered failure.

"Fred" will likely create something, in whatever time, and the team of 
monkeys will nus never come up with an acceptable thing. What is the ratio 
then?

IMO the camp talking about little differences just cheat in the result by 
assuming the low-end people still work wth knowledgeable colleagues, who do 
the code reviews and possibly wash up afterwards to.    It is easy to be 
'productive' doing a small portion of the job.

In article <MPG.24e4ab1f65924ad2989737@news.sunsite.dk>, 
jerryvcoffin@yahoo.com says...

[ ... ]

> The prototype nature (and possible lack of execution) leaves us with 
> little assurance that the Lisp prototype actually worked. Given that 
> they clearly state that the author of the Lisp prototype attended a 4 
> hour kickoff meeting, but only reports 3 hours for development, means 
> that (at least as such things are normally measured) the three hours 
> is clearly incorrect -- four hours is the absolute minimum, and seven 
> is much more likely.

After more reading, it looks like the Ada 9x prototype did not 
execute. They don't specify that the others all did, but lacking any 
evidence to the contrary, it's probably fair to say that all the 
others did actually execute.

-- 
    Later,
    Jerry.

"Jerry Coffin" <jerryvcoffin@yahoo.com>
> In article <h5eao3$2ado$1@news.ett.com.ua>, pasa@lib.hu says...
>> I observed organisations, especially bosses tend to not calculate
>> with prevention at all. Instead, measuring 'hard work' in the
>> amount of visible sweat.   :(
>
> You may have seen it before, but I'm reminded of the parable of the
> two programmers:
>
> http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/Th
> e%20Parable%20of%20the%20Two%20Programmers.html
>
> Fun (and funny) but with quite a bit of truth as well...

Oh yeah :(

Also there was a presentation 'rowers' circiling around at my last worklpace 
having a French team vs. a Japanese. Later I discovered versions of it on 
the net, having GM and Toyota and some others. Here's a neutral versiuon:

http://www.nteu9.org/membership/teamrace.pdf

Too bad that the more things change the more they stay the same.

Balog Pal wrote:
> 
> IMO the camp talking about little differences just cheat in the result by 
> assuming the low-end people still work wth knowledgeable colleagues, who do 
> the code reviews and possibly wash up afterwards to.    It is easy to be 
> 'productive' doing a small portion of the job.

"low-end people" are, by definition, below average.  For the nth time 
for those who aren't paying attention, I'll restate the original claim:

"a good programmer can be 100x productive as an *average* one".

-- 
Ian Collins

"Ian Collins" <ian-news@hotmail.com>
> Balog Pal wrote:
>>
>> IMO the camp talking about little differences just cheat in the result by 
>> assuming the low-end people still work wth knowledgeable colleagues, who 
>> do the code reviews and possibly wash up afterwards to.    It is easy to 
>> be 'productive' doing a small portion of the job.
>
> "low-end people" are, by definition, below average.  For the nth time for 
> those who aren't paying attention, I'll restate the original claim:
>
> "a good programmer can be 100x productive as an *average* one".

Come on, Ian!

For that statement to mean anything on earth you shall fill with meaning the 
terms:
- "good programmer"
- "average programmer"
- "productiveness of the programmer"

Until that the whole debate is no different from "how many angels can dance 
on the top of a needle".

If anyone here actually means it, pleas state at least what you want to mean 
by average. In simple language it has no single meaning.  Or if you mean the 
math function "average" applied, then state to what measure.  Until then we 
can;t tell who is above/below and whether the set is not actually empty. 
Why assume a certain spread to an unknown measure.

(Or better yet let's admit it's just a play of words, that just must not be 
taken seriously, and especially getting annoyed at each other.) 

In article <h5ftie$2v1n$1@news.ett.com.ua>, pasa@lib.hu says...

[ ... ]

> For that statement to mean anything on earth you shall fill with
> meaning the terms:
> - "good programmer"
> - "average programmer"
> - "productiveness of the programmer"
> 
> Until that the whole debate is no different from "how many angels can dance 
> on the top of a needle".

For the current discussion, all of those really revolve around the 
last -- i.e. what is meant by productivity. I'd measure it in terms 
of function points implemented per unit of time. Other people might 
prefer to use lines of code -- under the right circumstances (within 
a given project, all using the same language, etc.) that can be 
reasonable, but especially across languages it becomes difficult to 
compare meaningfully.

From there, about all you really need to define for average is what 
average you want to use: the arithmetic mean, the harmonic mean, the 
geometric mean, the median, the mode, etc. If you were going to use 
the mode, you'd also have to define your strata as well, but I don't 
think it's suitable here, so I wouldn't bother. While most people 
find the arithmetic mean the most understandable, given the claimed 
variability, the geometric mean would probably be a better choice.

In this context, it seems nearly certain (at least to me) that "good 
programmer" was intended to mean "highly productive" or (probably) 
"most productive."

-- 
    Later,
    Jerry.

Ian Collins wrote:

> In answer to that, I'd point you to the original claim: "a good
> programmer can be 100x productive as an *average* one". 
> 
> So an experiment might be to take a randomly selected group of 10
> programmers and compare their team output over ten day with the
> mythical super programmer who should produce the same output in one. 
> A larger sample size might give a better average..

10 programmers working for 10 days is /not/ 100 times one programmer
working for one day. This is a classic: see The Mythical Man-Month, if
it shouldn't be obvious. For coordinating the efforts of 10 programmers,
10 days is not much.

A better test would be to give the 10 programmers each 4 months (100
working days), and see how the classification of all 11 looks like. Or
make teams of 2 and give them 2 months.

Gerhard

Balog Pal wrote:
> "Ian Collins" <ian-news@hotmail.com>
>> Balog Pal wrote:
>>> IMO the camp talking about little differences just cheat in the result by 
>>> assuming the low-end people still work wth knowledgeable colleagues, who 
>>> do the code reviews and possibly wash up afterwards to.    It is easy to 
>>> be 'productive' doing a small portion of the job.
>> "low-end people" are, by definition, below average.  For the nth time for 
>> those who aren't paying attention, I'll restate the original claim:
>>
>> "a good programmer can be 100x productive as an *average* one".
> 
> Come on, Ian!
> 
> For that statement to mean anything on earth you shall fill with meaning the 
> terms:
> - "good programmer"
> - "average programmer"
> - "productiveness of the programmer"
> 
> Until that the whole debate is no different from "how many angels can dance 
> on the top of a needle".

I think that was my point!  I didn't make the original claim.

-- 
Ian Collins

Gerhard Fiedler wrote:
> Ian Collins wrote:
> 
>> In answer to that, I'd point you to the original claim: "a good
>> programmer can be 100x productive as an *average* one". 
>>
>> So an experiment might be to take a randomly selected group of 10
>> programmers and compare their team output over ten day with the
>> mythical super programmer who should produce the same output in one. 
>> A larger sample size might give a better average..
> 
> 10 programmers working for 10 days is /not/ 100 times one programmer
> working for one day. This is a classic: see The Mythical Man-Month, if
> it shouldn't be obvious. For coordinating the efforts of 10 programmers,
> 10 days is not much.

The suggestion as no more ridiculous that the original claim!

-- 
Ian Collins

On Aug 4, 11:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:

> > As I said, you might start with the documentation at the SEI
> > site quoted above.  Particularly
> >http://www.sei.cmu.edu/publications/key-publications.htmland
> > the link to process improvement.  Most of what they suggest has
> > been around for awhile, and has proven its value.

> James, have you read

> "CMMI or Agile: Why Not Embrace Both!"?

> http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf

A long time ago.  But that's not really the point.  The most
important aspects of CMMI address a higher level---not so much
what to do, but how to decide what to do.  Thus, CMMI doesn't so
much say that you have to use code reviews instead of pair
programming, but rather specifies criteria by which you can make
such a choice.  Some aspects of agile programming can probably
be adopted into any process; some may even improve it (depending
on the rest of the process).  But you don't adopt them because
they've been sold as agile; you adopt them as part of a larger
process, because they result in a measurable improvement in your
productivity.

What I miss in the agile programming literature is this
measuraable.  There are a lot of claims, but they all seem to be
comparing with using no process at all, and they all seem to be
more feeling than actual measurement.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 5, 1:56 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:

> > I wasn't going to respond any further here, since the
> > argument is really "Everyone I've ever worked with is
> > incompetent" (from Andrew)

> That is a childish misrepresentation of what I said.  If you
> don't understand where the statement "a good programmer can be
> 100x productive as an average one" comes from than my guess is
> you haven't worked with any *really* good programmers.

And that's insulting, because I have worked with really good
programmers.  A lot of them.  And I know a lot more, including
some of the very best (go to a meeting of the ISO C++ committee,
and you'll see what I mean), none of whom claims to be able to
write a good program without help---in fact, I find it a
consistent characteristic of the very best (people like
Stroustrup, for example) that they are generally the quickest to
acknowledge that good programs require teamwork, that you can't
do it alone.

> Surely you don't claim to have worked with every programmer on
> Earth?

I'm an independent consultant, and have been for 25 years.  I've
worked with a very large number of different people.  And I know
enough about human beings to know the expected degree of
variance.  I repeat: Superman only exists in comic books.  No
one is 100x better than "average", in anything.  No one is
perfect, and capable of producing a perfect work, in any field.
In most engineering fields, this has been acknowledged, and
there is often even a legal requirement for review.  In software
engineering, we're not there yet; the fact that bad software
is tolerated, and even widely used, is proof of that.  (And of
course, review isn't perfect either, since the reviewers are
also fallible humans.  So we occasionally have bridges that
fail.  The percentage of bad bridges, however, seems to be to be
a lot less than the percentage of bad software.)

> Given that you have not, why isn't it possible that
> some of the programmers you have not worked with are
> significantly better than the best programmer you have worked
> with?  You must concede it as, at a minimum, logically
> possible.

As I said elsewhere, Superman only exists in comic books.  I've
worked with enough different programmers to be able to have a
very good idea as to the variance.  Some are five times more
productive, no doubt.  I wouldn't exclude even ten times more
productive.  But that's an upper limit.

Beyond programming: take any human activity, and you'll not find
people 100 times better than the average.  (For activities like
programming, which require special training, the "average" of
trained people, of course.)

> Given that it is possible, why do you so fervently deny it?

Because it isn't possible.  Superman only exists in comic books.
People (in general, not just in programming) don't show that
degree of variance in ability, at least not in the positive
direction.  (It's an interesting question why.  A genetic defect
or some such can cause extreme variance, but it's always
negative.)

> I would quite happily accept you saying that you have not seen
> the phenomenon - but you are claiming that it doesn't exist
> because you haven't seen it.  When someone digs a trench like
> this they usually have a vested interest in their position
> being true:

> The fact is a lot of engineering process designers and project
> managers would love it if programmers were homogeneous
> interchangeable parts.

There's a difference between homogeneous and a 100x difference.
Programmers aren't homogeneous.  Different programmers are most
skilled in different aspects, and even when they're best area is
the same, there is a distinct, measurable difference in their
abilities there.  But with the exception of some (very few)
remarkably bad people, the difference isn't more than about five
times.

Note that different programmers have different skill sets.  As a
consultant, I've often been used to provide "missing"
skills---the permanent employees were better than me in
application domain programming, but weren't that good in other
areas, like threading, or low level library stuff.  In a very
real sense, saying that x is 100x, or even just five times,
better at programming doesn't mean anything, since different
aspects of programming require different skills.

When you see someone performing 100x better than someone else,
you'll find that the environment he's working in plays a major
role, and not just his competence.

> It would make a managers job so much easier that some even try
> to bury their head in the sand and pretend that this is the
> case.  X programmers produce Y lines of code with Z errors. :)
> Unfortunately it just doesn't gel with reality.

That's for sure.  Different programmers have different skill
sets, and can vary globally in competence.  Just not to the
degree you claim.

> Programmers vary greatly in their level of productivity (yes
> as much as 100x).

Different environments can cause a 100x difference in the
productivity of a single programmer.  (At least twice, I've
worked in environments which guaranteed negative performance,
regardless of how skilled the programmer.)

> I repeat: I have seen this firsthand, I have heard firsthand
> account, it has been written about in books.

I've heard a lot of war stories, too.  People (myself included)
like to exagerate, and memory can play cruel tricks.  That's why
measurement is so important.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 5, 4:08 pm, "Balog Pal" <p...@lib.hu> wrote:
> "Andrew Tomazos" <and...@tomazos.com>
> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:

> >> I wasn't going to respond any further here, since the argument
> >> is really "Everyone I've ever worked with is incompetent" (from
> >> Andrew)
> >That is a childish misrepresentation of what I said.  If you
> >don't understand where the statement "a good programmer can
> >be 100x productive as an average one" comes from than my
> >guess is you haven't worked with any *really* good
> >programmers.

> I'm quite sure James worked with some of those.

> What I seriously doubt from reading many his posts, that he
> worked with bad ones. And mor importantly with many average
> ones.    And if you cut the first 80% of measuring data,
> certainly different figures will emerge.

I've worked with many different types.  What I've seen is that
the environment makes a big difference---once or twice, I've
been in an environment where even the best programmer couldn't
produce anything good.  And I've worked in one place where even
very average programmers (and one or two definitely below
average) produced good code.

On the whole, if you want to produce good code, it's best to
have at least one or two distinctly better than average people;
software isn't that cut and dried yet, and you do need some real
creativity.  But an exceptionally good programmer in a bad
environment will still be less productive than an average
programmer in a good environment (where he will, for example, be
encouraged to recognize his limits, and ask for help when
necessary).

I tend, here, to talk mostly about the better places I've
worked, and not mention the worst (where management seemed to go
out of their way to ensure failure).  The large differences in
productivity that I've seen, however, have more to do with
different processes, than with different levels of programmer
skills.

> Being able to find the good places to work, and restrict to
> only those is a good thing -- but not too widespread.

On the whole, I think I've been fairly lucky.  Being a
contractor has meant that when I did end up in a bad place, I
could leave quickly.  And with the time, I've learned to ask the
right questions during the interview---I interview the potential
client as much as he interviews me.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Jerry Coffin <jerryvcoffin@yahoo.com> writes:

> In article <7cljlxicei.fsf@pbourguignon.anevia.com>, 
> pjb@informatimago.com says...
>
> [ ... ]
>
>> Have a look at the figure #3 on page 9 of this report:
>> 
>>     http://www.haskell.org/papers/NSWC/jfp.ps  
>> 
>> Notice that it has been written by a Haskell advocate.  Compare the
>> development time of Lisp vs other programming languages...
>
> To get anything meaningful, you need to look at more than just that 
> one figure. First, you need to take into account that this was 
> development of a prototype, not real code. Second, you need to look 
> at the date on the paper -- 1994. [...]
> All in all, it's an interesting paper, and I'm glad you posted the 
> link -- but I don't think it provides much support for conclusions 
> about C++ or Lisp.

I agree that this kind of experiment should be re-done more
serriously, on complete projects, and with the conditions of today,
such as access from the internet to libraries and documentation,
modern language features and development environments, etc.

-- 
__Pascal Bourguignon__

On Aug 5, 10:15 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Ian Collins:

> > Andrew Tomazos wrote:
> >> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
> >>> I wasn't going to respond any further here, since the
> >>> argument is really "Everyone I've ever worked with is
> >>> incompetent" (from Andrew)

> >> That is a childish misrepresentation of what I said.  If
> >> you don't understand where the statement "a good programmer
> >> can be 100x productive as an average one" comes from than
> >> my guess is you haven't worked with any *really* good
> >> programmers.

> > Like James, I don't believe one human can be two orders of
> > magnitude better at a chosen occupation than another.  The
> > other simply wouldn't graduate.  If he or she did and
> > managed to con their way into a job, they wouldn't stay
> > employed for long

> Your argument wouldn't be much different with one order of
> magnitude, and that's commonly observed.

Is it?

> So where does the argument go wrong? It's simply that the
> argument assumes that the requirements for graduating and
> holding a job, in a technical profession, have to do with
> productivity and/or quality, a sort of monotonically
> increasing function, whereas in reality there can be little
> direct connection between technical ability and success, and
> whereas success can have more to do with conformance and
> social issues. In fact, a recent career guide in Norwegian
> "Dagens N=E6ringsliv", a leading economics newspaper in Norway,
> cautioned strongly against doing too well while at the lower
> rungs of the ladder because one is then viewed as a threat
> both by co-workers and by one's boss, and reader comments were
> uniformly positive that at last some reality was discussed.

My argument only concerns best compared to average.  I'm aware
that on the negative side, there are some real outliers, which
make you wonder how they did get a diploma.  But they're
outliers, not average, and they're rather rare (and often do
have problems getting a job).  On the positive side, there seems
to be an upper limit to human ability, regardless of the field
of endevor.  It's certainly true for most fields, and I see no
reason to think that it's different for programming.

> >> Programmers vary greatly in their level of productivity
> >> (yes as much as 100x).  I repeat: I have seen this
> >> firsthand, I have heard firsthand account, it has been
> >> written about in books.

> > Care to cite the references?

> Third google hit on "programmer productivity", citing e.g.
> Steve McConnell, Randall E. Stross and [clc++m] mod (now
> inactive) Robert C. Martin:
> <url:http://www.devtopics.com/programmer-productivity-the-tenfinity-facto=
r/>.

> It's so common and well-known that it has its own name.

It's a relatively wide spread misconception.  If you'll look at
the quoted text, McConnell mentions that it also applies to
teams---that definitely suggests that it is more of an
environmental effect than a difference in actual programmer
ability.

There is a difference between programmers, and some are better
than others.  But the difference is nowhere near 100x, and most
of the time, the difference depends on which aspect of
programming you're considering---I'm much better at working on
e.g. threading problems than I am in numerics, and I've met
programmers much better than me in numerics who had serious
problems with threading.

> Note that this fact, the observed reality,

The "observed reality" seems to be mostly annecdotal, and not
measurable.  And doesn't square with what is measurable (in
other domains).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 5, 10:27 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Ian Collins wrote:
> > Andrew Tomazos wrote:
> >> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
> >>> I wasn't going to respond any further here, since the
> >>> argument is really "Everyone I've ever worked with is
> >>> incompetent" (from Andrew)

> >> That is a childish misrepresentation of what I said.  If
> >> you don't understand where the statement "a good programmer
> >> can be 100x productive as an average one" comes from than
> >> my guess is you haven't worked with any *really* good
> >> programmers.

> > Like James, I don't believe one human can be two orders of
> > magnitude better at a chosen occupation than another.

> Again it depends on what "better" means.  How are we going to
> measure it?  Are we going to compare someone who's been in the
> field for decades, and constantly making sure their knowledge
> is current, to someone straight out of college?  You would
> probably get close to 100x difference in any method you chose
> to measure their code quality and production.

That's not necessarily true.  Part of being "good" (and I
believe that most programmers are good) is being able to
recognize your limits.  If the recent grad, even average, is in
a conducive environment, he'll be able to recognize when he
starts getting in over his head, and ask questions, or look the
information up.  It will take more time than someone who's
already encountered the problem, but not 100x more.

Still, you do have a point.  If you're fully familiar with the
domain, and have already implemented enough similar programs,
you know exactly what to expect, and you've already seen all of
the problems that can occur, and know the solutions to them
without thinking.  In such cases, compared to someone who's
unfamiliar with the domain, who knows what the difference can
be.  Maybe I've been lucky, but on all of the projects I've
worked on, there's been enough novelty that there's never been
someone that prepared in advance.  And would you consider
someone who's writing what is essentially the same code for the
fifth time "better", just because he can write that code (and
not necessarily anything else) much faster than anyone else.

> I'm of the opinion that good developers do something extra on
> the side to keep themselves updated.

I'm of the opinion that good management ensures that its
developer keep up to date:-).

> They read books, experiment with stuff they can't experiment
> with at work, and they continue to bring in new, fresh ideas.
> A lot of people are simply not motivated to do this but think
> going to work and getting the job done is enough.  I frankly
> don't know what it's like in the larger companies but I see
> this quite a lot.  Nothing wrong with it if that's what you're
> about but someone who goes the extra mile is going to be
> better (no matter how much of a star you were in school) and
> in many cases that difference will be significant.

Obviously, if you've only done Java, your first project in C++
will take more time that you or I would require:-).

    [...]
> >  If he or she did and managed to con their way into a job,
> > they wouldn't stay employed for long

> Again, it depends.  If you're talking about a big company that
> has lots of money and can hire the best then I'm sure you're
> right.

Actually, I think it's easier to hide incompetence in a big
company.  If the company's small enough, and someone is truly
incompent, either they recognize it and replace him, or they go
out of business.  (The few outliers I've seen---truly
incompetent people---have been in big companies.)

    [...]
> So I think that though the 100x figure is a bit extreme I do
> believe there can be significant differences between
> developers,

Again, I don't dispute that there will be significant
differences.  What I do argue is that there won't be anything
near 100x between average and best---for some reason, the
extreme differences always seem to be on the negative side
(although it's rare, I've seen total incompetence), and that the
environment will often (always?) make a bigger difference: One
of the best programmers I've known had a negative productivity
on the project where I met him; all of the programmers on that
project had negative productivity---management ensured to that.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

"James Kanze" <james.kanze@gmail.com>
On Aug 5, 4:08 pm, "Balog Pal" <p...@lib.hu> wrote:
>> I'm quite sure James worked with some of those.

>> What I seriously doubt from reading many his posts, that he
>> worked with bad ones. And mor importantly with many average
>> ones.    And if you cut the first 80% of measuring data,
>> certainly different figures will emerge.

>I've worked with many different types.  What I've seen is that
>the environment makes a big difference---once or twice, I've
>been in an environment where even the best programmer couldn't
>produce anything good.  And I've worked in one place where even
>very average programmers (and one or two definitely below
>average) produced good code.

>On the whole, if you want to produce good code, it's best to
>have at least one or two distinctly better than average people;
>software isn't that cut and dried yet, and you do need some real
>creativity.  But an exceptionally good programmer in a bad
>environment will still be less productive than an average
>programmer in a good environment (where he will, for example, be
>encouraged to recognize his limits, and ask for help when
>necessary).

Exactly!  That is what I implied in a previous post.  This way you measure 
in the impact of the envirionment in the individual performance -- and reach 
the very different figures.

The most amount of impact of the god programmers is not in the lines of code 
they cranked out by hand -- and using them to write much code themselves 
would be a serious waste.  The value comes from their view, insight, 
knowledge, exprerience, (...) applied to the whole team. making it tick, and 
fare toward the target.  ( what makes the comparision even more moot... ;)

Sure, the average programmer can write a ton of working code if he receives 
design and code reviews, mentoring, and supervision as necessary.

But left on his own devices, the story is different.  It is interesting (and 
so sad) to look at projects that got abandoned by the good programmers and 
being maintained by the "average". Picking up all the antipatterns in the 
book quite soon, and declining.

>I tend, here, to talk mostly about the better places I've
>worked, and not mention the worst (where management seemed to go
>out of their way to ensure failure).  The large differences in
>productivity that I've seen, however, have more to do with
>different processes, than with different levels of programmer
>skills.

Yeah, and the others (Noah?) estimate that your "better places" are the tiny 
minority of sw producing places.

>> Being able to find the good places to work, and restrict to
>> only those is a good thing -- but not too widespread.

>On the whole, I think I've been fairly lucky.  Being a
>contractor has meant that when I did end up in a bad place, I
>could leave quickly.  And with the time, I've learned to ask the
>right questions during the interview---I interview the potential
>client as much as he interviews me.

Exactly. As expected. :)  What is very good, just makes you view of the 
world very much filtered.  Especially to the extent.

"James Kanze" <james.kanze@gmail.com>
> So I think that though the 100x figure is a bit extreme I do
> believe there can be significant differences between
> developers,

>Again, I don't dispute that there will be significant
>differences.  What I do argue is that there won't be anything
>near 100x between average and best---for some reason, the
>extreme differences always seem to be on the negative side

It is just artefact of the arbitrarily picked measuring methods.

Say you want to compare people on long jumping. (this is just parable, not 
aiming accuracy, substitute actuel values where necessary)

Current sport way is to make 5 jumps and take the length of best in cm. So 
AvgJoe can measure 600, and the worl recorder 900.  50% diff. It is insane 
to think the best coud jump 10x let alone 100x the distance.

However, suppose we have a different way to do the competition: an arbitrary 
distance D is picked, and candidates must jump over that "chasm".  Everyone 
keep jumping until falling in or saying enough. And you get X points for 
every success and, Y (some negative value) for a fail, B as base.

Now comparing the points will make a very different spectrum 100x times 
difference easy to reach (after we overcome some adjustment for div0 and 
play with X,Y,B).   Especially tweaking D, after the other numbers are set.

The second measuring method may look weird at first, but probably has a 
better value guessing evolutionary value of the performance.

On Aug 6, 12:19 pm, "Balog Pal" <p...@lib.hu> wrote:
> "Noah Roberts" <roberts.n...@gmail.com>

> > Jerry Coffin wrote:

> >> In overall productivity, A's change took .1 + .75*10 =3D 7.6
> >> man hours. B's change took 1 + 1.5*10 =3D 16 man hours. The
> >> 10x factor for the original change is now just over 2x --
> >> and in all honesty, even that's probably being generous.

> > OK, this is pretty good analysis but one thing it leaves out
> > maybe is the time that a "bad" programmer can add to
> > discussion time.

> I'd approach from the other direction.  The average programmer
> planted the otiginal bug in the code, being unaware of stuff
> like 'you initialize variables'  'you read the F*ing
> warnings', and so on.

What kind of average programmers are those?  I've yet to meet a
programmer who didn't know that variables have to be
initialized, and the treatment of warnings has always been a
matter of policy, which even the worst programmers respect.
Errors like uninitialized variables do creep in, because
programmers (even good ones) are human beings, and make
mistakes.  A weaker performer may make more, but even the best
programmers aren't exempt from them.

Of course, if an error has been pointed out to you in a code
review, you tend to pay more attention to what caused it in the
future.

> I observed organisations, especially bosses tend to not
> calculate with prevention at all.

That depends on the organization.  An ounce of prevention is
worth a pound of cure, and good organizations know this.

> Instead, measuring 'hard work' in the amount of visible sweat.
> :(

No.  In the poorly managed places I've worked in, "hard work" is
measured by being seen at work late in the evening.  Whether
you're actually doing anything or not.  (In this regard, Martin
Suter's "Business Class" is well worth reading.  I'm not sure
that it's been translated into English, however.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 6, 3:54 pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Aug 6, 7:57 am, Ian Collins <ian-n...@hotmail.com> wrote:
> > Noah Roberts wrote:
> In trying to understand where the 100x factor comes from
> consider:

In trying to understand anything, don't speculate, measure.

    [...]
> Have a look at the results of one of the completed marathon
> matches at TopCoder.com.  You can see the problem statement,
> the finalists and their code.

What you can't see is how they developed it?  Whether they
worked alone, or in a group?  What technical environment they
were working in?  There's absolutely nothing which would make me
thing that the "winner" would be productive in the environment I
work in, or that some of the lower placers wouldn't be more
productive than the winner if they were in the same environment.

> 1. Get the winner of the recent TopCoder marathon match "Fred".
> 2. Get the next problem statement.
> 3. Give Fred a day to do it.
> 4. Assemble a team of 10 average programmers - give them 10 days to do
> it.
> 5. See who wins.

> My money is on Fred.

If the program can be implemented in a day, I don't know.  If
Fred can implement it in a day, it can't be significant, and I
certainly wouldn't put a team of 10 programmers on it.  If Fred
can implement it in a day, however, two or three average
programmers won't take more than two or three days, unless there
is something in the environment which prevents them from being
normally effective.

I might add that I can't find anything at the site which says
how the programs are judged, or how they are deamed "correct" or
"good" or anything else.  In fact, off hand (and I'll admit that
I've only made a superficial visit) the site more or less looks
like a scam to get software developed at less than the going
price (and probably significantly less than generally accepted
minimum quality).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

"James Kanze" <james.kanze@gmail.com>

>> I'd approach from the other direction.  The average programmer
>> planted the otiginal bug in the code, being unaware of stuff
>> like 'you initialize variables'  'you read the F*ing
>> warnings', and so on.

>What kind of average programmers are those?  I've yet to meet a
>programmer who didn't know that variables have to be
>initialized, and the treatment of warnings has always been a
>matter of policy, which even the worst programmers respect.
>Errors like uninitialized variables do creep in, because
>programmers (even good ones) are human beings, and make
>mistakes.  A weaker performer may make more, but even the best
>programmers aren't exempt from them.

'Coding standards', guidelines, etc, are written for who? Not the average 
programmers? All of them include the 'DO init the $%#$% variables'.  IMO 
because the practical obseravation is is just not happening.

The 'creep in' is true, please think about how it actually happens:

- I do not init the variable where created, because it will get value later 
on, before use
- that later on  is avoided on some code paths that still lead to use.

And this creates the ital difference: the good programmer will more likely 
shape the code to prevent the situation altogether (i.e defining variable 
where initialized, not C90-way), or well aware of all the paths.   The 
average one isn't.  Also the first will do a self-review of the paths and 
run tests with proper values, the other will not (often enough).

Yeah, human beings do mistakes, Murphy does not sleep, and sometimes the 
good programmer too misses some combination of events, or just makes a typo 
putting the good value in the wrong variable, then keeps reading his code as 
if it had the correct text.

But the average is not just ht by Murphy, but by the limitation of his 
thinking. Keeping all the relevant info in the head, skill to see all the 
relevant combos, and so on. and/or the attitude to do stuff properly instead 
of cutting some corners.


>Of course, if an error has been pointed out to you in a code
>review, you tend to pay more attention to what caused it in the
>future.

Of course my ass.  my experense shows huge organizations are filled up with 
completely ignorant people caring little about the project, and in general 
about anything besides their desk and salery.

Having that genuine drive to do the job WELL and paying attention is in 
itself a trait in the above-average club.    And it will stay that way as 
long as serious selection process will be forced on programming, and clients 
can start winning lawsuits for malpractice and bad products.  (not in 
visible future).

>> I observed organisations, especially bosses tend to not
>> calculate with prevention at all.

>That depends on the organization.  An ounce of prevention is
>worth a pound of cure, and good organizations know this.

Yes, and they appear pretty rare.

>> Instead, measuring 'hard work' in the amount of visible sweat.
>> :(

>No.  In the poorly managed places I've worked in, "hard work" is
>measured by being seen at work late in the evening.

Err, and what is "no"?

> Whether
>you're actually doing anything or not.  (In this regard, Martin
>Suter's "Business Class" is well worth reading.  I'm not sure
>that it's been translated into English, however.)

That is the same thing I say, the visibility-based development. The boss 
can't tell real work from anything, so "being around late" is one of his 
best guesses of performance.
Possibly discounting instances he found  someone on quake or a forum during 
daytime, that can mess up the picture even more.
Read the story Jerry linked recently up this thread.

On Aug 7, 3:17 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <h5ftie$2v1...@news.ett.com.ua>, p...@lib.hu says...

> [ ... ]

> > For that statement to mean anything on earth you shall fill with
> > meaning the terms:
> > - "good programmer"
> > - "average programmer"
> > - "productiveness of the programmer"

> > Until that the whole debate is no different from "how many
> > angels can dance on the top of a needle".

> For the current discussion, all of those really revolve around
> the last -- i.e. what is meant by productivity. I'd measure it
> in terms of function points implemented per unit of time.
> Other people might prefer to use lines of code -- under the
> right circumstances (within a given project, all using the
> same language, etc.) that can be reasonable, but especially
> across languages it becomes difficult to compare meaningfully.

At least part of the argument centers around what we mean by
"good" code.  Just implementing a function point isn't
sufficient, the implementation has to be "sufficiently correct"
and "sufficiently maintainable".

> From there, about all you really need to define for average is
> what average you want to use: the arithmetic mean, the
> harmonic mean, the geometric mean, the median, the mode, etc.

And what you're averaging.  If you're using the median over all
human beings on earth, then the 100x factor is probably too
low---I'd bet that over half of the world's population can't
program at all.  The claims only make sense, however, if you're
talking about professional programmers---people who are paid to
program for a living.  And within that group, there is an elite,
but the difference between the elite and the average isn't
anywhere near a factor of 100---more like three to five.

> If you were going to use the mode, you'd also have to define
> your strata as well, but I don't think it's suitable here, so
> I wouldn't bother. While most people find the arithmetic mean
> the most understandable, given the claimed variability, the
> geometric mean would probably be a better choice.

I was actually thinking of the median.  But I don't think it
matters too much---most programmers are probably fairly bunched
near the center.

> In this context, it seems nearly certain (at least to me) that
> "good programmer" was intended to mean "highly productive" or
> (probably) "most productive."

In what environment.  Productivity depends more on the
environment than on the individual programmer---I've seen
environments where even the best programmer couldn't be
productive, and in well run shops, "average" programmers can be
very productive.  Since it depends so much on the environment,
productivity can vary greatly, because there is a great variance
in environments.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 31, 7:25 am, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:

> > Without some sort of process, you don't know whether your
> > software is doing what it is supposed to do, or how good you
> > really are.  Noah was very right about one thing: you have to
> > measure.

> Ah, but measure what?

Everything:-).

Seriously, it is a difficult question.  One of the reasons I
keep coming back to errors per KLOC is because it is easily
quantified and measured.  Most other aspects, many just as
important, aren't so easily quantified and measured.  In my
experience, code with few errors tends to be easier to maintain,
because the techniques used to reduce the errors also make code
more readable.  But I can't quantify that.  And customer
satisfaction is even vaguer, at least in some environments.
(I've worked on a number of systems were all that was required
was that the program work as specified.  24 hours a day, 7 days
a week, without interruption.  No crashes or incorrect behavior,
and the customer was satisfied.  But that's certainly not
sufficient for a lot of programs.)

> I've always judged my my code by either customer satisfaction
> and (lack of!) support revenue with a single customer or field
> defects for applications with many, unknown, customers.

How do you quantify the customer satisfaction?

Of course, there are many aspects to consider.  I think you're
an independent---in a very real sense, your code is "good" if it
brings you repeat business, and bad otherwise.  (But I think
you're professional enough to set your standards a bit higher
than just that.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 31, 5:25 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:
> > Noah was very right about one thing: you have to
> > measure.

> Actually, what I said was that in order for something to be
> empirically based there must have been a measurement done.

> I don't agree with you that software "goodness" is something
> that can be measured.  In fact, I can't think of any
> "goodness" that is possible to measure.  Various things that
> various people think are "good", sure, but "goodness" is a
> subjective term that can't be empirically measured or applied.

Well, if we're going to compare it, we need something
empirically based, because otherwise, it's just words in air.

> For example, you are using "goodness" to mean, "lack of
> errors."  We can measure errors, somewhat, but since not
> everyone agrees with your use of the term "good" we haven't
> objectively measured "goodness".  This is why when speaking
> empirically it is best to use objective terms like "lack of
> error" instead of "goodness".  Then people know WTF you're
> talking about.

Maybe my point of view has been deformed by having worked on
critical projects, but code which crashes isn't good, no matter
what other criteria it fulfills.  Not crashing isn't a
sufficient condition, but it's a necessary one.

And the measure of "good" is somewhat subjective.  I didn't
intend to publish a book (or even write as much as I have on the
subject)---I simply intended to point out (and insist on the
fact) that programming requires teamwork.  In a very real sense,
doing anything well requires some sort of teamwork, and
programming isn't an exception.  The classical image of the
genius hacker working alone doesn't correspond to today's
reality; the programs we write are too complicated.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 5, 3:32 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> James Kanze wrote:

    [...]
> Just to look at some of the questions that are asked here
> daily which show fundamental misunderstandings or surprising
> lack of even the most basic knowledge -- and those are asked
> by the ones who find Usenet. And not all of those asking such
> questions are newbies just trying to learn the language.

I've seen one or two real duds in industry---the mentor assigned
to help me get up to speed in C++ in my first professional use
of the language (I'd written the usual String, AssocArrayOf and
RegularExpression classes on my home computer before) once
complained that there must be an error in the compiler, since it
said "missing semicolon" on line x, and there was a semicolon on
line x---he also explained to be that a clever trick to get a
line to compile was to put two slashes at the start of it.  But
they've been by far the exceptions: one or two in over thirty
years of professional programming.

Note too that not knowing a language is not proof of
incompetence.  There was a time I didn't know C++.  There was
even a time I was working professionally and didn't know C.  Not
being able to learn is a serious problem, especially in our
field, but such people tend not to get jobs in our field, or at
least not to keep them, since it does change so rapidly.  And
while I know that there are exceptions, employers, at least here
in Europe, are becoming more or less computer savey, and the
cock and bull stories that would get you through an interview 20
years ago don't work today.  In fact, in some ways, the problem
is just the reverse---potential employers will go to extremes
checking out your C++ knowledge (which you could easily acquire
on site, if you were hired), but will ignore whether you can
communicate and work well with the rest of the team (which is in
many ways more important).

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 30, 6:37 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> Christof Donat wrote:
> >> Because I don't accept that any human being can be perfect,

> > That automatically leads to the conclusion that any group of
> > human beings can never be perfect. Just maybe closer to
> > perfect than a single human that is part of the group.

> Or visa-versa.  A human alone has X number of flaws.  A group
> of humans has XN number of flaws and often times the X's
> complement each other to create new flaws so you have XN + Z
> number of flaws such that for any n in the group the non-flaws
> about that person cannot possibly counter the flaws in the
> entire group.

It depends on how the group is organized.  I know that the
intelligence of a mob is the intelligence of the dumbest person
in the mob, divided by the number of people in the mob.  But
normally, software organizations aren't organized like mobs.  I
also know that in critical systems, it is usual to have several
systems performing more or less the same work (pair
programming:-), in sum), because the failings of one system will
not overlap with those of the other system.  In a well run
organization, that's the way it works---the errors one person
makes are caught and corrected by another person.  You don't
have to use pair programming---in fact, I think that there are
even more effective alternatives---but code that has been
written by one person and not even looked at by another is very
suspect.  And I suspect, although I've no measurements to back
me up here, that two people, using pair programming (meaning two
people in front of one keyboard for all programming activity),
will take less than half the time that a single person, working
alone, will take to produce a program "sufficiently correct" and
"sufficiently maintainable", for all reasonably non-trivial
programs and all reasonable definitions of "sufficiently
correct" and "sufficiently maintainable".  (Again, I'm pretty
sure that even better methods exist.  But I'm definitely sure
that pair programming is more effective than lone wolf
programming.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jul 30, 6:31 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:
> > Because I don't accept that any human being can be perfect,
> > and that he can produce a significant work without errors.
> > Empirical evidence supports me in this: to date, no human
> > being has ever produces a perfect work, in any field.  And
> > they've been trying for a long time.

> But you haven't told us why "good software" must be "perfect
> software".

Because, of course, I can't:-).  Perfect software doesn't
exist---even teams make mistakes.  And I guess good is somewhat
arbitrary---some people think that Windows (or Linux) is good.
Shit, when I first started C++, some people claimed that g++ was
good.  Today, g++ is one of the better C++ compilers, but it's
still far from being what I would consider "good".  When I
started C++, on the other hand...  One of the bugs I encountered
was that it didn't call destructors on local variables if your
returned from a function, as opposed to running off the end.
But there were still any number of people to defend it.

> From my perspective it doesn't require a perfect human to
> develop _good_ software..convenient thing too because
> otherwise there'd be no such thing as good software, written
> by teams or otherwise.

Agreed.  But surely there must be some sort of minimum quality.
It's a moving target (what was considered "good" software 30 or
40 years ago would count as junk today), and the exact minimum
might depend on the context, but while somewhat vague and
imprecise, it does seem to make sense, to me, to talk about
"good" software.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 7, 12:22 pm, "Balog Pal" <p...@lib.hu> wrote:
> "James Kanze" <james.ka...@gmail.com>

    [...]
> >On the whole, if you want to produce good code, it's best to
> >have at least one or two distinctly better than average people;
> >software isn't that cut and dried yet, and you do need some real
> >creativity.  But an exceptionally good programmer in a bad
> >environment will still be less productive than an average
> >programmer in a good environment (where he will, for example, be
> >encouraged to recognize his limits, and ask for help when
> >necessary).

> Exactly!  That is what I implied in a previous post.  This way
> you measure in the impact of the envirionment in the
> individual performance -- and reach the very different
> figures.

> The most amount of impact of the god programmers is not in the
                                   ^^^
That's an interesting typo:-).

> lines of code they cranked out by hand -- and using them to
> write much code themselves would be a serious waste.  The
> value comes from their view, insight, knowledge, exprerience,
> (...) applied to the whole team. making it tick, and fare
> toward the target.  ( what makes the comparision even more
> moot... ;)

> Sure, the average programmer can write a ton of working code
> if he receives design and code reviews, mentoring, and
> supervision as necessary.

And the best programmer can't really write working code at all
without some design and code reviews, and supervision.  It's a
continuum: the best programmers aren't perfect, and the medien
isn't really that bad either.  There are certainly some
programmers who would be better off working in a different
field, but they seem to have become an increasingly small
minority.

> But left on his own devices, the story is different.

Working in absolute isolation, it's hard to say.  A lot depends
on the requirements.  If something totally new is required, the
chances are better with one of the "exceptional" programmers,
but they're far from 100%, and I've seen some pretty average
programmers hit it lucky as well.  Most programs, however, don't
really need anything not already known.  And average programmers
are capable doing that.  Perhaps even better that the elite,
because they don't get bored by it as quickly.  (Note that while
an elite programmer improves the performance of the average
programmers in the team, the reverse is true as well.  Because
he is relieved of the less challenging parts, the elite
programmer doesn't get bored as quickly.)

And note well that the difference in competence between the
elite and the average is between three and five.  Not one
hundred.

    [...]
> >I tend, here, to talk mostly about the better places I've
> >worked, and not mention the worst (where management seemed to
> >go out of their way to ensure failure).  The large
> >differences in productivity that I've seen, however, have
> >more to do with different processes, than with different
> >levels of programmer skills.

> Yeah, and the others (Noah?) estimate that your "better
> places" are the tiny minority of sw producing places.

That's not my impression.  It's been a long time since I've had
to turn down an offer because the company looked bad.  And I
typically interview for quite a few places before deciding.
Judging from the interviews I've had, the quality of management
has increased enormously in recent (last 10 or 15) years.  (Of
course, if for some reason you're stuck at one of the bad
places, this doesn't help you.)

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

In article <h5h7rq$eo2$1@news.ett.com.ua>, pasa@lib.hu says...

[ ... ]

> - I do not init the variable where created, because it will get
> value later on, before use
> - that later on  is avoided on some code paths that still lead to use.
> 
> And this creates the ital difference: the good programmer will more likely 
> shape the code to prevent the situation altogether (i.e defining variable 
> where initialized, not C90-way), or well aware of all the paths.   The 
> average one isn't.  Also the first will do a self-review of the paths and 
> run tests with proper values, the other will not (often enough).

Code that requires tracking every path and ensuring initialization in 
every one is (almost by definition) fragile, and should generally be 
avoided if possible -- one of the most common forms of maintenance is 
to add code for something that wasn't previously taken into account, 
which almost inevitably creates a new path through the code, and with 
it a new chance for the variable to remain uninitialized.

IMO, it's better to plan for that, by (for example) creating a type 
with a ctor, so initialization becomes nearly impossible to avoid -- 
either the ctor takes an argument, so the code won't compile without 
supplying an initializer, or else a default ctor is supplied so it'll 
be initialized even if no initializer is supplied.

> But the average is not just ht by Murphy, but by the limitation of his 
> thinking. Keeping all the relevant info in the head, skill to see all the 
> relevant combos, and so on. and/or the attitude to do stuff properly instead 
> of cutting some corners.

IMO, the ability to keep all relevant info in your head is 
counterproductive more often than not -- people who can do so, tend 
to depend on doing so far too often, leading to code that's quite 
fragile when handled by anybody with even slightly less ability in 
that specific direction. Code should not only BE bug-free when 
written, but be written to remain bug free.

-- 
    Later,
    Jerry.

In article <bc03ef3d-ade1-45d9-be75-e9143937d6b7
@q35g2000vbi.googlegroups.com>, james.kanze@gmail.com says...

[ ... ]

> At least part of the argument centers around what we mean by
> "good" code.  Just implementing a function point isn't
> sufficient, the implementation has to be "sufficiently correct"
> and "sufficiently maintainable".

Well, yes. The time measured should not just be for the initial 
implementation, but over the life of the project. 

Even that is somewhat of a simplification though: something that's 
implemented sufficiently poorly can (and often will) lead to extra 
work in other parts of the project. In theory, you'd like to measure 
that as well, but it's usually almost impossible to do so -- 
especially in the (frequent) case of a good (or at least accurate)
implementation of a poor specification.
 
> > From there, about all you really need to define for average is
> > what average you want to use: the arithmetic mean, the
> > harmonic mean, the geometric mean, the median, the mode, etc.
> 
> And what you're averaging.  If you're using the median over all
> human beings on earth, then the 100x factor is probably too
> low---I'd bet that over half of the world's population can't
> program at all.

Hmmm...I think it's safe to guess that fewer than 1% can program at 
all. I'm not even certain that half the world's population is really 
even literate (no, I'm not trying to be elitist in saying that, only 
observing that there are quite a few places where literacy rates 
really are very low -- including some where teaching certain people 
to read is illegal or considered immoral).

> The claims only make sense, however, if you're
> talking about professional programmers---people who are paid to
> program for a living.  And within that group, there is an elite,
> but the difference between the elite and the average isn't
> anywhere near a factor of 100---more like three to five.

I don't think even that much is needed. A 100x difference between 
elite and average would imply a 10000x difference between elite and 
"bottom".

To put that in perspective, assume there are 2000 working hours a 
year. That multiplies out to the worst taking five years of full time 
work to match one hour by a top programmer.

If you just picked somebody at random off the street, in less than 
five years they could learn to program enough to do at least as much 
as a really good programmer could do in an hour.

-- 
    Later,
    Jerry.

On Aug 7, 9:33=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Aug 7, 12:22 pm, "Balog Pal" <p...@lib.hu> wrote:
>
> > "James Kanze" <james.ka...@gmail.com>
>
> =A0 =A0 [...]
>
> > >On the whole, if you want to produce good code, it's best to
> > >have at least one or two distinctly better than average people;
> > >software isn't that cut and dried yet, and you do need some real
> > >creativity. =A0But an exceptionally good programmer in a bad
> > >environment will still be less productive than an average
> > >programmer in a good environment (where he will, for example, be
> > >encouraged to recognize his limits, and ask for help when
> > >necessary).
> > Exactly! =A0That is what I implied in a previous post. =A0This way
> > you measure in the impact of the envirionment in the
> > individual performance -- and reach the very different
> > figures.
> > The most amount of impact of the god programmers is not in the
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^=
^
> That's an interesting typo:-).
>
> > lines of code they cranked out by hand -- and using them to
> > write much code themselves would be a serious waste. =A0The
> > value comes from their view, insight, knowledge, exprerience,
> > (...) applied to the whole team. making it tick, and fare
> > toward the target. =A0( what makes the comparision even more
> > moot... ;)
> > Sure, the average programmer can write a ton of working code
> > if he receives design and code reviews, mentoring, and
> > supervision as necessary.
>
> And the best programmer can't really write working code at all
> without some design and code reviews, and supervision. =A0It's a
> continuum: the best programmers aren't perfect, and the medien
> isn't really that bad either. =A0There are certainly some
> programmers who would be better off working in a different
> field, but they seem to have become an increasingly small
> minority.
>
> > But left on his own devices, the story is different.
>
> Working in absolute isolation, it's hard to say. =A0A lot depends
> on the requirements. =A0If something totally new is required, the
> chances are better with one of the "exceptional" programmers,
> but they're far from 100%, and I've seen some pretty average
> programmers hit it lucky as well. =A0Most programs, however, don't
> really need anything not already known. =A0And average programmers
> are capable doing that. =A0Perhaps even better that the elite,
> because they don't get bored by it as quickly. =A0(Note that while
> an elite programmer improves the performance of the average
> programmers in the team, the reverse is true as well. =A0Because
> he is relieved of the less challenging parts, the elite
> programmer doesn't get bored as quickly.)
>
> And note well that the difference in competence between the
> elite and the average is between three and five. =A0Not one
> hundred.
>
> =A0 =A0 [...]
>
> > >I tend, here, to talk mostly about the better places I've
> > >worked, and not mention the worst (where management seemed to
> > >go out of their way to ensure failure). =A0The large
> > >differences in productivity that I've seen, however, have
> > >more to do with different processes, than with different
> > >levels of programmer skills.
> > Yeah, and the others (Noah?) estimate that your "better
> > places" are the tiny minority of sw producing places.
>
> That's not my impression. =A0It's been a long time since I've had
> to turn down an offer because the company looked bad. =A0And I
> typically interview for quite a few places before deciding.
> Judging from the interviews I've had, the quality of management
> has increased enormously in recent (last 10 or 15) years. =A0(Of
> course, if for some reason you're stuck at one of the bad
> places, this doesn't help you.)
>

I recommend not working as an employee of a company that
supports homosexuality.  That's one of the reasons I started
Ebenezer Enterprises -- to prevent having my work being used
to support immorality.  Unfortunately today the majority of
companies are supportive of homosexuality.  50 years ago I
don't think there were any that corrupt.   "In Defense of
Homophobia" by Jonathan Katz is helpful in this area --
http://wuphys.wustl.edu/~katz


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

On Aug 7, 2:30=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> I'll admit that I've only made a superficial visit

How about making a non-superficial visit before drowning us further in
your ignorance?

You seem to have plenty of time to write 20 posts of drivel per day,
but you don't have 30 seconds to review clear evidence.

I can tell by what you said about TopCoder that you have no experience
with it, or a programming competition like it.

Here, I will spoon feed you:
1. Go to TopCoder.com
2. Sign up
3. Go to COMPETE > MARATHON MATCHES
4. Go to STATISTICS > MATCH ARCHIVE
5. Pick a recent competition.
6. Click around until you find:
       - the detailed problem statement
       - the test cases
       - the precise scoring system
       - exact specification of the system on which the code is run
       - the final leaderboard
       - the code from each of the submissions

Come back when you have an *informed* opinion to share.  Everything
you said about it was laughable.
  -Andrew.

* Andrew Tomazos:
> On Aug 7, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
>> I'll admit that I've only made a superficial visit
> 
> How about making a non-superficial visit before drowning us further in
> your ignorance?

Some heat detected ...  ;-)


> You seem to have plenty of time to write 20 posts of drivel per day,
> but you don't have 30 seconds to review clear evidence.

Heh.

Let's not devolve further to the stage of putting names and derogatory terms in 
the subject line.

But yeah, some of those guys 'n gals are *very* good, very very smart, but the 
code they write at competition is generally (at least what I've seen of it) 
unmaintainable, using cryptic shortname macros to generate loops and so on.

It seems that the number of characters to type is a main factor in such 
competitions, so to do well I think one must practice that macro usage.

Of course one must also be smart enough to solve the problems, and ideally be 
free of distractions.



Cheers,

- Alf

James Kanze wrote:
> On Aug 4, 11:34 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
> 
>>> As I said, you might start with the documentation at the SEI
>>> site quoted above.  Particularly
>>> http://www.sei.cmu.edu/publications/key-publications.htmland
>>> the link to process improvement.  Most of what they suggest has
>>> been around for awhile, and has proven its value.
> 
>> James, have you read
> 
>> "CMMI or Agile: Why Not Embrace Both!"?
> 
>> http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf
> 
> A long time ago.  But that's not really the point.  The most
> important aspects of CMMI address a higher level---not so much
> what to do, but how to decide what to do.  Thus, CMMI doesn't so
> much say that you have to use code reviews instead of pair
> programming, but rather specifies criteria by which you can make
> such a choice.  Some aspects of agile programming can probably
> be adopted into any process; some may even improve it (depending
> on the rest of the process).  But you don't adopt them because
> they've been sold as agile; you adopt them as part of a larger
> process, because they result in a measurable improvement in your
> productivity.
> 
> What I miss in the agile programming literature is this
> measuraable.  There are a lot of claims, but they all seem to be
> comparing with using no process at all, and they all seem to be
> more feeling than actual measurement.

You're probably correct there. Getting reliable comparisons between any 
two processes is an expensive task. The only real way to do it is to do 
a project twice in parallel, once with each process.

-- 
Ian Collins

On Aug 7, 2:48=A0pm, Andrew Tomazos <and...@tomazos.com> wrote:
> On Aug 7, 2:30=A0pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > I'll admit that I've only made a superficial visit
>
> How about making a non-superficial visit before drowning us further in
> your ignorance?
>
> You seem to have plenty of time to write 20 posts of drivel per day,
> but you don't have 30 seconds to review clear evidence.
>

I've been reading Kanze's posts for years and would hardly
describe them as drivel.  His posts are generally thoughtful
and sometimes insightful.


Brian Wood
www.webEbenezer.net

On Aug 7, 11:18=A0pm, "Alf P. Steinbach" <al...@start.no> wrote:
> But yeah, some of those guys 'n gals are *very* good, very very smart, bu=
t the
> code they write at competition is generally (at least what I've seen of i=
t)
> unmaintainable, using cryptic shortname macros to generate loops and so o=
n.

Yes, I'm not suggesting that the code written for a competition is the
same as that written for production.  There are many factors not
tested.  I do however contend that there is a *significant*
correlation between general programming ability and scoring ability at
those sort of competitions.  If we accept that assertion, than we can
see hard evidence of the 100x factor.  In any case I ask the reader to
compare the submitted code, and make their own judgements.
  -Andrew.

On Aug 7, 2:51 pm, "Balog Pal" <p...@lib.hu> wrote:
> "James Kanze" <james.ka...@gmail.com>

    [...]
> The 'creep in' is true, please think about how it actually
> happens:

> - I do not init the variable where created, because it will get value lat=
er
> on, before use
> - that later on  is avoided on some code paths that still lead to use.

> And this creates the ital difference: the good programmer will
> more likely shape the code to prevent the situation altogether
> (i.e defining variable where initialized, not C90-way), or
> well aware of all the paths.   The average one isn't.

And that is simply not true.  Every C++ programmer I've ever met
knows to initialize variables at the point of declaration, and
does so.  Every coding guideline I've met requires this.

I don't know where this idea comes from that "average"
programmers are all idiots, and that there are just a few
"super-programmers" out there who know what they are doing.
Most professional are just that: professional.  And they do a
pretty good job.

> Yeah, human beings do mistakes, Murphy does not sleep, and
> sometimes the good programmer too misses some combination of
> events, or just makes a typo putting the good value in the
> wrong variable, then keeps reading his code as if it had the
> correct text.

Exactly.  That's why we have code reviews---so that someone
"outside" can read the code.  But that's true for everyone, from
the raw beginner to the top expert.

> But the average is not just ht by Murphy, but by the
> limitation of his thinking. Keeping all the relevant info in
> the head, skill to see all the relevant combos, and so on.
> and/or the attitude to do stuff properly instead of cutting
> some corners.

Average or expert, the programmers keep the functions small
enough that keeping everything in one's head for the entire
function is not a problem.

> >Of course, if an error has been pointed out to you in a code
> >review, you tend to pay more attention to what caused it in
> >the future.

> Of course my ass.  My experense shows huge organizations are
> filled up with completely ignorant people caring little about
> the project, and in general about anything besides their desk
> and salery.

And that's just wrong.  I've worked with a number of big
organizations (Siemens, Alcatel, T Mobile...), and I've never
found a service filled up with completely ignorant people.

> Having that genuine drive to do the job WELL and paying
> attention is in itself a trait in the above-average club.

The genuine drive is a result of management, not of the
individual.

> >> I observed organisations, especially bosses tend to not
> >> calculate with prevention at all.
> >That depends on the organization.  An ounce of prevention is
> >worth a pound of cure, and good organizations know this.

> Yes, and they appear pretty rare.

It varies, but they seem a lot less rare now than, say 20 years
ago.  It takes time, but management is learning how to manage
software development.

> >> Instead, measuring 'hard work' in the amount of visible sweat.
> >> :(
> >No.  In the poorly managed places I've worked in, "hard work" is
> >measured by being seen at work late in the evening.

> Err, and what is "no"?

There's no visible sweat in staying late:-).

> >Whether you're actually doing anything or not.  (In this
> >regard, Martin Suter's "Business Class" is well worth
> >reading.  I'm not sure that it's been translated into
> >English, however.)
>
> That is the same thing I say, the visibility-based
> development. The boss can't tell real work from anything, so
> "being around late" is one of his best guesses of performance.

In one of Suter's articles, it was just the opposite.  The boss
took staying late as a sign that the person didn't know how to
manage his time.  It varies.  But whatever... bad management
certainly exists, and while it isn't as omnipresent as it used
to be, most places could still do with some improvement.

> Possibly discounting instances he found  someone on quake or a
> forum during daytime, that can mess up the picture even more.
> Read the story Jerry linked recently up this thread.

I'm familiar with it.  There was a time it was more or less true
in a lot of places.  That's a lot less frequent today than when
it was written.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 7, 6:58 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <h5h7rq$eo...@news.ett.com.ua>, p...@lib.hu says...

> [ ... ]
> > - I do not init the variable where created, because it will
> > get value later on, before use
> > - that later on  is avoided on some code paths that still
> > lead to use.

> > And this creates the ital difference: the good programmer
> > will more likely shape the code to prevent the situation
> > altogether (i.e defining variable where initialized, not
> > C90-way), or well aware of all the paths.   The average one
> > isn't.  Also the first will do a self-review of the paths
> > and run tests with proper values, the other will not (often
> > enough).

> Code that requires tracking every path and ensuring
> initialization in every one is (almost by definition) fragile,
> and should generally be avoided if possible -- one of the most
> common forms of maintenance is to add code for something that
> wasn't previously taken into account, which almost inevitably
> creates a new path through the code, and with it a new chance
> for the variable to remain uninitialized.

> IMO, it's better to plan for that, by (for example) creating a
> type with a ctor, so initialization becomes nearly impossible
> to avoid -- either the ctor takes an argument, so the code
> won't compile without supplying an initializer, or else a
> default ctor is supplied so it'll be initialized even if no
> initializer is supplied.

Alternatively, you initialize in the definition (which is, of
course, what the constructor does).  Every coding guideline I've
seen requires this, and I've rarely seen code which doesn't do
it.

> > But the average is not just ht by Murphy, but by the
> > limitation of his thinking. Keeping all the relevant info in
> > the head, skill to see all the relevant combos, and so on.
> > and/or the attitude to do stuff properly instead of cutting
> > some corners.

> IMO, the ability to keep all relevant info in your head is
> counterproductive more often than not -- people who can do so,
> tend to depend on doing so far too often, leading to code
> that's quite fragile when handled by anybody with even
> slightly less ability in that specific direction. Code should
> not only BE bug-free when written, but be written to remain
> bug free.

It depends on the level.  There's always something you have to
keep in your head, if only when moving your eyes down three
lines from the declaration.  In well written ("good") code,
there's no place where there's very much, and it's all obvious
with a quick glance at the function.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 7, 11:18 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Andrew Tomazos:

> > On Aug 7, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
> >> I'll admit that I've only made a superficial visit

> > How about making a non-superficial visit before drowning us
> > further in your ignorance?

> Some heat detected ...  ;-)

When you don't have any real arguments.  The site is certainly
not anything a professional would use.

    [...]
> But yeah, some of those guys 'n gals are *very* good, very
> very smart, but the code they write at competition is
> generally (at least what I've seen of it) unmaintainable,
> using cryptic shortname macros to generate loops and so on.

The requirements for winning some prize are different than the
requirements for professional work.

> It seems that the number of characters to type is a main
> factor in such competitions, so to do well I think one must
> practice that macro usage.

> Of course one must also be smart enough to solve the problems,
> and ideally be free of distractions.

And be motivated to do work for almost nothing.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Aug 8, 12:33=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> > >> I'll admit that I've only made a superficial visit
> > > How about making a non-superficial visit before drowning us
> > > further in your ignorance?
> > Some heat detected ... =A0;-)
>
> When you don't have any real arguments. =A0The site is certainly
> not anything a professional would use.

Why not?

> > But yeah, some of those guys 'n gals are *very* good, very
> > very smart, but the code they write at competition is
> > generally (at least what I've seen of it) unmaintainable,
> > using cryptic shortname macros to generate loops and so on.
>
> The requirements for winning some prize are different than the
> requirements for professional work.

There is a strong correlation.  Strong enough to demonstrate the
spectrum of programming ability.

> And be motivated to do work for almost nothing.

What the hell are you talking about?
  -Andrew.

Andrew Tomazos wrote:
> On Aug 8, 12:33 pm, James Kanze <james.ka...@gmail.com> wrote:
> 
>>> But yeah, some of those guys 'n gals are *very* good, very
>>> very smart, but the code they write at competition is
>>> generally (at least what I've seen of it) unmaintainable,
>>> using cryptic shortname macros to generate loops and so on.
>> The requirements for winning some prize are different than the
>> requirements for professional work.
> 
> There is a strong correlation.  Strong enough to demonstrate the
> spectrum of programming ability.

How strong?  Where has this been documented?

>> And be motivated to do work for almost nothing.
> 
> What the hell are you talking about?

The prizes on offer don't justify the effort required to win them.

-- 
Ian Collins

In article <a6d81112-aeec-473d-8856-d48a580dec39
@m20g2000vbp.googlegroups.com>, james.kanze@gmail.com says...

[ ... ]

> It depends on the level.  There's always something you have to
> keep in your head, if only when moving your eyes down three
> lines from the declaration.  In well written ("good") code,
> there's no place where there's very much, and it's all obvious
> with a quick glance at the function.

Well, yes. The people who study such things claim most people's 
short-term memory is good for 5 items, plus or minus three. I'm not 
sure there's much point in trying to limit yourself to 2, but I'd be 
extremely wary of going much beyond 6 or so if there's any reasonable 
way to avoid it...

-- 
    Later,
    Jerry.

On Aug 8, 11:34=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >>> But yeah, some of those guys 'n gals are *very* good, very
> >>> very smart, but the code they write at competition is
> >>> generally (at least what I've seen of it) unmaintainable,
> >>> using cryptic shortname macros to generate loops and so on.
>
> >> The requirements for winning some prize are different than the
> >> requirements for professional work.
>
> > There is a strong correlation. =A0Strong enough to demonstrate the
> > spectrum of programming ability.
>
> How strong? =A0Where has this been documented?

Yeah, okay.  I mean that in my judgment and experience I would expect
a fairly strong correlation - however I leave it to the reader to look
at the details and make their own assessment.

> >> And be motivated to do work for almost nothing.
>
> > What the hell are you talking about?
>
> The prizes on offer don't justify the effort required to win them.

My comments are isolated to the marathon matches, of which I doubt the
resulting code is put into production.  I'm not sure the motivation to
compete in a programming competition is created by the prizes.  It is
a game in a way.  A test of skill with hard scores.  It's easy to say
programmer X is better than programmer Y - but provided you accept the
correlation with "real" programming - this is a way that programming
ability can be empirically proven and compared.
  -Andrew.

"Andrew Tomazos"

>>
My comments are isolated to the marathon matches, of which I doubt the
resulting code is put into production.  I'm not sure the motivation to
compete in a programming competition is created by the prizes.  It is
a game in a way.  A test of skill with hard scores.  It's easy to say
programmer X is better than programmer Y - but provided you accept the
correlation with "real" programming - this is a way that programming
ability can be empirically proven and compared.
<<

And if you want a guy to carry heavy stuff around (or move your household), 
you certainly will get the best results with the weighlifting champ... :-o

Brian Wood wrote:

> I recommend not working as an employee of a company that
> supports homosexuality.  That's one of the reasons I started
> Ebenezer Enterprises -- to prevent having my work being used
> to support immorality.  Unfortunately today the majority of
> companies are supportive of homosexuality.  50 years ago I
> don't think there were any that corrupt.   "In Defense of
> Homophobia" by Jonathan Katz is helpful in this area --
> http://wuphys.wustl.edu/~katz

*plonk*

I'm afraid to flush...a pile this big might get stuck.

Andrew Tomazos wrote:
> On Aug 7, 11:18 pm, "Alf P. Steinbach" <al...@start.no> wrote:
>> But yeah, some of those guys 'n gals are *very* good, very very smart, but the
>> code they write at competition is generally (at least what I've seen of it)
>> unmaintainable, using cryptic shortname macros to generate loops and so on.
> 
> Yes, I'm not suggesting that the code written for a competition is the
> same as that written for production.  There are many factors not
> tested.  I do however contend that there is a *significant*
> correlation between general programming ability and scoring ability at
> those sort of competitions.

I'm not so sure.  I've seen too much code that is unmaintainable because 
it was given to some lone wolf who could supposedly achieve the 
impossible: a complex product delivered in simple product time.  Whole 
slews of code that nobody wants to even look at because all the triple 
indirections and casting hacks make them dizzy.

James Kanze wrote:
> On Aug 5, 10:27 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>> Ian Collins wrote:
>>> Andrew Tomazos wrote:
>>>> On Aug 4, 11:14 am, James Kanze <james.ka...@gmail.com> wrote:
>>>>> I wasn't going to respond any further here, since the
>>>>> argument is really "Everyone I've ever worked with is
>>>>> incompetent" (from Andrew)
> 
>>>> That is a childish misrepresentation of what I said.  If
>>>> you don't understand where the statement "a good programmer
>>>> can be 100x productive as an average one" comes from than
>>>> my guess is you haven't worked with any *really* good
>>>> programmers.
> 
>>> Like James, I don't believe one human can be two orders of
>>> magnitude better at a chosen occupation than another.
> 
>> Again it depends on what "better" means.  How are we going to
>> measure it?  Are we going to compare someone who's been in the
>> field for decades, and constantly making sure their knowledge
>> is current, to someone straight out of college?  You would
>> probably get close to 100x difference in any method you chose
>> to measure their code quality and production.
> 
> That's not necessarily true.  Part of being "good" (and I
> believe that most programmers are good) is being able to
> recognize your limits.  If the recent grad, even average, is in
> a conducive environment, he'll be able to recognize when he
> starts getting in over his head, and ask questions, or look the
> information up.  It will take more time than someone who's
> already encountered the problem, but not 100x more.

Yeah, and part of being a "bad" programmer is being too damn stubborn. 
It's actually easier to get graduates to create nice code than some 
"experts".  One example: I had the misfortune of working under someone 
who insisted exceptions slow down code too much and that the standard 
library should not be used.  Sure, he had years more experience working 
than I did but boy was it a PITA to write decent code under THAT guy's 
perview.

So you can have the opposite problem too.
> 
> Still, you do have a point.  If you're fully familiar with the
> domain, and have already implemented enough similar programs,
> you know exactly what to expect, and you've already seen all of
> the problems that can occur, and know the solutions to them
> without thinking.  In such cases, compared to someone who's
> unfamiliar with the domain, who knows what the difference can
> be.  Maybe I've been lucky, but on all of the projects I've
> worked on, there's been enough novelty that there's never been
> someone that prepared in advance.  And would you consider
> someone who's writing what is essentially the same code for the
> fifth time "better", just because he can write that code (and
> not necessarily anything else) much faster than anyone else.

Actually, I'd only consider him better if he was able to write it in a 
week because he's already got all he needs in libraries that are all 
unit tested and proved out in other products....all he has to do is tie 
it together nicely.  That's kind of my job though: managing the products.

> 
>> I'm of the opinion that good developers do something extra on
>> the side to keep themselves updated.
> 
> I'm of the opinion that good management ensures that its
> developer keep up to date:-).

Perhaps, but still...a developer that is self-motivating is better than 
one which needs to be pushed all the time.  The former will go further 
with less push than the later.

One of the things I look for in college recruits is that they interned 
somewhere.  Too many don't...they just do the work they're required to 
do for class and that's it.  No going out to get more.  IMO someone that 
graduated without interning isn't usually worth even interviewing.
> 
>> They read books, experiment with stuff they can't experiment
>> with at work, and they continue to bring in new, fresh ideas.
>> A lot of people are simply not motivated to do this but think
>> going to work and getting the job done is enough.  I frankly
>> don't know what it's like in the larger companies but I see
>> this quite a lot.  Nothing wrong with it if that's what you're
>> about but someone who goes the extra mile is going to be
>> better (no matter how much of a star you were in school) and
>> in many cases that difference will be significant.
> 
> Obviously, if you've only done Java, your first project in C++
> will take more time that you or I would require:-).

Not what I'm talking about actually.  I'm talking about the difference 
between someone who is interested in programming vs. someone that 
couldn't care less and just wants to get by.

On Aug 11, 9:35=A0pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> I do however contend that there is a *significant*
> correlation between general programming ability and scoring ability at
> those sort of competitions.
>
> I'm not so sure.

Did you take a look at the submitted code as I suggested before making
this judgement?  Did you compare the winning entry with an average
scoring one?
  -Andrew.

On Aug 11, 9:48 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> James Kanze wrote:

    [...]
> >> I'm of the opinion that good developers do something extra
> >> on the side to keep themselves updated.

> > I'm of the opinion that good management ensures that its
> > developer keep up to date:-).

> Perhaps, but still...a developer that is self-motivating is
> better than one which needs to be pushed all the time.  The
> former will go further with less push than the later.

I don't think it's a black and white situation.  In my
experience, the vast majority of programmers are willing to
learn, and to keep up to date.  They don't always realize that
it's necessary, or know how to do it, though.  This is where
management comes in---it creates the atmosphere which encourages
such learning, and provides the means to do it.  It can often be
things as simple as promoting or giving a bonus to someone who
has made the extra effort to learn something new, or providing
the necessary information (books, etc.) where it is easily
accessible to all, and encouraging people to use it *on*
*company* *time*.  (Given the speed our field evolves, I would
expect close to a fourth of all time to be spend in further
learning.  Two hours a day, in an eight hour day.  One of the
management problems I often see is that management expects all
eight hours to be booked to some specific project---it should
insist that at least two hours be booked to further training.)

> One of the things I look for in college recruits is that they
> interned somewhere.  Too many don't...they just do the work
> they're required to do for class and that's it.  No going out
> to get more.  IMO someone that graduated without interning
> isn't usually worth even interviewing.

I've run into that once or twice---one person once told me that
he'd just finished five years of only learning, and now that he
was out of college, he didn't want to learn any more.  But in my
experience, such people seem to be the exceptions.  On the other
hand, when management insists that all time be booked to some
project, and frowns on it when you read a technical book in the
office, a lot of people won't make the additional effort to keep
up to date in their own time.

    [...]
> > Obviously, if you've only done Java, your first project in C++
> > will take more time that you or I would require:-).

> Not what I'm talking about actually.  I'm talking about the
> difference between someone who is interested in programming
> vs. someone that couldn't care less and just wants to get by.

In my experience, most programmers are interested in
programming.  But not only in programming---they have families,
and other interests as well.  And 35-40 hours a week is already
a lot of time to spend on any one area of interest.  It's up to
management to ensure that they can read about new technologies
and experiment in that 35-40 hours.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

Ian Collins wrote:

> Gerhard Fiedler wrote:
>> Ian Collins wrote:
>> 
>>> In answer to that, I'd point you to the original claim: "a good
>>> programmer can be 100x productive as an *average* one". 
>>> 
>>> So an experiment might be to take a randomly selected group of 10
>>> programmers and compare their team output over ten day with the
>>> mythical super programmer who should produce the same output in
>>> one. A larger sample size might give a better average..
>> 
>> 10 programmers working for 10 days is /not/ 100 times one programmer
>> working for one day. This is a classic: see The Mythical Man-Month,
>> if it shouldn't be obvious. For coordinating the efforts of 10
>> programmers, 10 days is not much.
> 
> The suggestion as no more ridiculous that the original claim!

What's ridiculous?

-- 
Gerhard

Gerhard Fiedler wrote:
> Ian Collins wrote:
> 
>> Gerhard Fiedler wrote:
>>> Ian Collins wrote:
>>>
>>>> In answer to that, I'd point you to the original claim: "a good
>>>> programmer can be 100x productive as an *average* one". 
>>>>
>>>> So an experiment might be to take a randomly selected group of 10
>>>> programmers and compare their team output over ten day with the
>>>> mythical super programmer who should produce the same output in
>>>> one. A larger sample size might give a better average..
>>> 10 programmers working for 10 days is /not/ 100 times one programmer
>>> working for one day. This is a classic: see The Mythical Man-Month,
>>> if it shouldn't be obvious. For coordinating the efforts of 10
>>> programmers, 10 days is not much.

>> The suggestion as no more ridiculous that the original claim!
> 
> What's ridiculous?

I thought this thread was done!

The original claim in my first paragraph.

-- 
Ian Collins