We have a pretty complex project with 100 or so classes, multiple custom elements, etc. We have a new senior programmer who will work on this project.
How should we approach the task of introducing the senior programmer to the project? How can we make sure the programmer does not break some other feature while fixing the current one? I have seen too many similar situation.s Sometimes, new bugs are not noticed immediately — but pop up months later.
Shall I direct the programmer by first giving them smaller tasks and waiting for them to finish them? Or there is a better solution?
I am asking this because I don’t want to become micromanager but I also don’t want to have nasty bugs created because of my bad approach to the new programmer.
5
We have a pretty complex project with 100 or so classes, multiple custom elements, etc. We got a new senior who will work on this project.
This actually a small project, unless the classes have been allowed to grow to thousands of lines of code. A project of 100 classes should be easily managed by one or two developers.
How can we make sure he does not break some other feature while fixing the current one?
After every change, you should run automated tests to largely ensure that no features were broken. However, I get the impression that you do not have such tests. In that case bugs are almost inevitable, and they will occur more and more frequently as the size of the code increases. You can mitigate this somewhat by carefully reviewing code before it goes into production.
I have seen too many similar situation and such bugs are not noticed immediately, but sometimes months later.
This is a result of inadequate testing. Errors in programming are inevitable. All we can do is reduce the frequency. The first line of defense is automated tests.
Shall I direct him by first giving him smaller tasks and wait him finish them?
You should have him work on tasks with another experienced developer. Perhaps they will both learn something.
… I also don’t want to have nasty bugs created because of my bad approach to new guy.
Automated tests will largely prevent this. Whenever a bug is discovered, create a test that fails. Then fix the bug so that the test passes.
I think you can take two approaches, one could be giving the new person a piece of work where something a bit isolated would be developed (e.g. a new page/screen) this way the developer can explore the current project and check how some things were already done in the past.
While doing this piece of work he/she will also start taking some decisions related to the design of the new piece of work that he/she is working on. This can lead to questions and discussions that can be useful for the developer to get more understanding on the project and how things have been done. You can also make peer reviews on the work or do some pair programming at the beginning of the task.
Another approach can be to give small assignments related to support, like fixing small bugs. On this case I agree with kevin cline that automated can be extremely helpful to make sure that everything is still ok.
Get him to run a regression test pack on parts of the system that he’ll be working on. I would do that prior to allowing them make any changes in code.
Once they are comfortable with how the application works, get them bug fixing. Peer review bug fixes to get a good idea on their skill set.
He will break your application, but that’s what regression and unit tests are for. If you don’t have these, then be prepared to take a hit.