Subj : Re: Software Job Market Myths
To   : comp.programming,comp.software-eng
From : CTips
Date : Sat Jul 02 2005 08:05 am

shelley@osel.netkonect.co.uk wrote:

> You're right. I had made certain assumptions, perhaps unwarranted. I
> know good practices - agile or not - can amplify capability

There is another assumption here - that there are practices that are 
universally good. I suspect that for any practice there are situations 
in which it would detract from productivity, and there are many 
practices which when applied to the wrong people would degrade their 
capability.

Quoting from the message you were responding to "Good programmers 
provide short & accurate estimates..". In my opinion, thats complete BS. 
If you've never done something similar before, how can you know how long 
it takes?

For instance, brining up an RF card. Theoretically, it should take a 
couple of days to a week. In practice it can take a couple of months, 
before one has figured out all the incompatibilities with the 
documentation, mismatches in the hardware etc.

Or what happens when you have to go back and replace a 3rd party 
component because it caused the program to crash, and you've just spent 
2 extra weeks before identifying that it was the cause, and then you 
have to spend another 2 weeks rewriting the component.

We generally use one of two approaches when setting up schedules:
- get the job done, and it takes as long as it takes
- here's how much time we have, try and get as much done as possible


 > but it is
> still the individual variability that is most marked.
> 
> The very 'best' (perhaps exceptional  is a better word) programmers I
> have known have been, if not weird then at least a little unusual and
> both an opportunity and a risk in a project.

The problem is really one of management - if you can't grok their 
capabilities and/or motivations (and most managers cant - if they could, 
they probably wouldn't be managers), you can't control/direct them, and 
you end up with the risk that they don't do what you wanted them to, 
either because you didn't make them understand the (nuances of the) 
problem, or because you couldn't keep them focused.

Also, typically, if you have one of these people, why would you want 
anyone else on the project? It has to be pretty large (100kloc+) and/or 
partitionable before not having them do it solo pays off.

> They think faster and better, and are often impatient with the rest of us.
 > These types are easy to regonize but the capabiity is difficult to
 > characterize. Not error free, not balanced, not always right, but...
>

.