One of the components in our product, (let’s just call it DW for this discussion), is basically the fruits of one man’s labor. It was designed and developed and has been extended and maintained by one developer, my colleague Pierre.
For the company, you always want to have multiple engineers that are capable of working on a component. This gives project leadership more flexibility in developing the project plans and in responding to unforeseen plan challenges and changes. Above all, it provides some redundancy in case that one-man-gang elects to leave the company.
From the developer perspective, if you are the only developer capable of working on a component, it is almost impossible to move away from that component to other exciting opportunities within the company – you sort of become chained to the component. Management is not real keen on letting you work on something else if you are the only one that knows what that component is all about.
On the other hand, being a one-man-gang has distinct advantages:
- You understand all aspects of the software so you are much more productive when it comes to extending the software with new function and more efficient at fixing bugs.
- Because you understand the history of the software, the quality of the enhancements you make is usually higher – you don’t venture into high-risk areas in the design blindly and you have a lower rate of regression defects (fixing one bug, but introducing another because you didn't understand the ramifications of the initial fix on the system).
- The architecture and design is usually much cleaner and more cohesive– the software has one creative vision (and doesn’t suffer from the too many cooks in the kitchen phenomena).
- You feel a much greater sense of personal responsibility and pride in the work. (Yes, even in multi-national corporations, that is still possible.)
I was a one-man-gang for about 4 years before joining my current team and it was a blast.
Well, Pierre had the nerve to take a couple of weeks of vacation this summer and yours truly has been selected to be Pierre’s backup (along with my co-worker Roseanne) until July 30. So this means that, as our product release heads down the homestretch, if any bugs are found in DW over the next couple of weeks, I get to fix them. Under extreme schedule pressure. While still doing my normal day job and owning my own component.
I was selected because I worked with Pierre last September on DW for about 2 whole weeks before being given another assignment and Pierre liked the work that I did and recommended to our manager that I could “cover DW with no problems”. Thanks Pierre.
Might as well look on the bright side and make lemonade. DW is built on the Eclipse framework and I have been really interested in doing that kind of work (and being able to put it on my resume) for about 5 years. So that is exciting. Plus, the boss has promised that I can work on DW in the next release of our product – development on that will start in the fall. I like working with Pierre, so I am stoked about that.
So if I can just get through the next couple of weeks, I will be good to go. On the other hand, if our Test Team opens some deep (non-trivial) bugs on DW between now and next Friday, my blogging time over the next couple of weeks will probably be drastically reduced and I am going to be hating life.
So my work happiness the next couple of weeks is going to depend on how many bugs our Test Team finds in Pierre’s baby. Crossing my fingers cause it is really no fun to fix bugs in a code base that is 40,000 lines of code that you didn’t design or implement.
Is July 30th here yet?
