Actually, the hardest task is probably correctly assigning the junior programmer to tasks which he's likely to be able to accomplish, and watching him carefully when it doubt. :-)
But this job can be made easier by documentation. Part of the documentation job that the senior programmers need to do is clearly explain where that complicated 10% of the codebase lies, and what level audience each section of it was written for. Good documentation and testing techniques should also tie business requirements to specific sections of the codebase, if only for verification purposes. ("Yes, the billing section works!"). The major and minor business premises and code specific assumptions should also be documented in case of change.
From that documentation, it's much easier to see who can work on which sections of code. First of all, if the code was written for a more advanced background than a programmer has, he doesn't get assigned to it.
If the new business requirements don't challenge any of the assumptions, then the new code can be slotted directly in for the old. If the novice can write the code, then he can do the maintenance.
If some of the lesser assumptions of the code have changed, minor re-design may be needed. With some guidance and direction from a design architect, the problem can probably be delegated to an intermediate progammer.
If some of the major assumptions about the code have changed, then it will probably take some serious design work on the part of the senior architect, and possibly be delegated to the senior programmers to work on.
If all of the major assumptions about the code have changed, it may be time to write a new codebase. ;-)
--
Ytrew
In reply to Re^7: improving the aesthetics of perl code
by Ytrew
in thread improving the aesthetics of perl code
by tcf03
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |