Home > Archive > Software Engineering > April 2004 > How quickly can one become incompetent?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How quickly can one become incompetent?
|
|
| qa@somewhere.com 2004-04-17, 10:31 pm |
| Where I work there are many different software languages and platforms
used. Some of the systems don't need attention for years because they
run smoothly.
However I'm worried that when I do call upon someone to work on these
legacy systems they will not be fully competent. How long should pass
before I reassess their competence for these systems? I know there
will not be a fixed answer to this but can anyone tell me of a good
way of evaluating this?
What do the standards say?
Anybody got case histories or precedents?
Any help gratefully accepted.
| |
| Darrell Grainger 2004-04-19, 1:40 pm |
| On Sun, 18 Apr 2004 qa@somewhere.com wrote:
> Where I work there are many different software languages and platforms
> used. Some of the systems don't need attention for years because they
> run smoothly.
>
> However I'm worried that when I do call upon someone to work on these
> legacy systems they will not be fully competent. How long should pass
> before I reassess their competence for these systems? I know there
> will not be a fixed answer to this but can anyone tell me of a good
> way of evaluating this?
Define competence. Without such a definition it is hard to say when they
are no longer fully competent.
A standard rule of thumb for doing a root cause analysis (RCA) is to
perform the analysis within 30 days of the defect being fixed. This
implies that the developer will have forgotten enough of the fix to make
the RCA pointless. Does that means the developer is no longer competent on
the system? Not really, it is just not worth the effort to have the
developer re-analyze the defect again. Given the time the developer could
remember the details of the fix.
Another issue, how well is the system documented? Are you relying on the
developers to 'know' the system? Is the system not documented at all and
your concern is what if the developer forgets? What if the developer
quits. Someone will have to become competent on the system.
I remember some of my first commerical code. I wrote something for a
customer. I did it quick and dirty with no documentation. A year later I
had a customer wanting a similar thing. I figured I could just recycle the
old code. Took me w s to figure out what the code was doing and to be
confident enough in the code to know it satisfied the customer's needs.
This time I documented the code. A few years later I had a need for the
code again. Took me minutes to figure out what the code did. Same
programmer, same code. The only difference was the code was documented
this time.
Bottom line, if the system is documented well, the competency of the
developer should not be a concern.
> What do the standards say?
>
> Anybody got case histories or precedents?
>
> Any help gratefully accepted.
>
--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.president@whitehouse.gov
| |
| Kevin Cline 2004-04-20, 5:40 pm |
| qa@somewhere.com wrote in message news:<fvn3805i8hdom1om7tnhdd085thqg5ktvp@4ax.com>...
> Where I work there are many different software languages and platforms
> used. Some of the systems don't need attention for years because they
> run smoothly.
>
> However I'm worried that when I do call upon someone to work on these
> legacy systems they will not be fully competent.
You seem to be confusing competence and proficiency. I'm no longer
proficient with COBOL or ADA or VAX assembler, and never have been
proficient in JAVA, but would consider myself competent to work on
systems coded in those languages.
However, it would probably take me longer than someone who has been
working steadily on that same system for the past three months.
|
|
|
|
|