How to revoke individual code ownership

Question

While reading this other question, I wondered me about this opposite.

I was in a project mainly driven by only one guru developer. Then, me and another three people were added to the project. But the time went on and for every feature needed, its implementation required constantly intervention of him because we were not very knowledgeable on the system. Besides, the architecture and design of the system lacked of clarity and I would say (very confident) there were areas where they became pretty convoluted, really.

Assuming enough competent people, how to handle the case where only one guru knows everything about the design and implementation of one relatively complex project?

Answer 1

Like many things in computer/software, divide and conquer. You can start with a specific module or feature and give committee the rights to design and implement.

Answer 2

oddly enough, my answer is pretty much the same as in the other thread - if you want to migrate to collective code ownership, you must have unit tests. These will

• instruct the noobs (unit tests make excellent how-to illustrations)
• document the requirements (unit tests, unlike written documentation, must always be up to date)
• expose the rough edges of the guru's design
• spread and embed knowledge of the system
• provide a safey net when the noobs start touching the guru's golden code

Answer 3

You can start an internal wiki. Then you and other non-guru developers can collaboratively write down your own understanding of current design and architecture. You can then ask the Guru to edit the wiki to iron-out the inaccuracies in your description.

This way a better all of the non-guru developers will improve their understanding of the design. Shortcomings of the design/architecture will also be high-lighted in documented form.

You can extend the idea to capture the design of new sub-systems and their interfaces with existing modules.

Answer 4

Walk in short steps.

No guru could handle everything and there are always some 'menial' upkeeping tasks you could take from him to make his life easier. By doing so and working closely with the initial developer you could gain some knowledge of the application architecture and logic while establishing a working relationship and trust in the team.

Spend this time documenting your architectural findings in Wiki. If by this time the application is more or less working draw some class diagrams ana worklflow charts for the complicated areas which will help everyone to understand what's going on. That will help everyone including your guru to get some insights on the possible refactoring activities you may plan in the future.

At some point start to work on the small and non-critical parts of new functionality. If they will be done well the guru will not have any problems with helping you to work on something more advanced.

Answer 5

You've got two main issues here. The first issue is how do you get the level of knowledge of the other team members up to the point where they are able to make changes without breaking the gurus code. Part of that is just a confidence thing, so making sure that there is a safety net (as Steven A. Lowe perfectly described it) of things like automated build and test regimes will help there. In some cases getting the other team members to contribute tests can be a way of getting them more familiar with the gurus code. (assuming that the guru hasn't already implemented 100% code coverage testing already...)

Get the guru to participate in or run the code reviews for new additions to this area.

The second issue is how to get the guru to loosen their control over this piece of code. If they've gone from being the sole developer/designer/tester to a situation where others are coming in to muddy their otherwise perfect design, the guru is likely to show some reluctance. The automated testing will assist in this as the guru will be able to see that modifications made by other team members haven't actually broken anything, contrary to the guru's worst fears.

Get the guru to actually teach the other team members about this chunk of code. Hold some formal training, run by the guru, so that they have a chance to point out what they see as the important elements of the design. This will give them a warm fuzzy feeling, but will also provide useful design information to the new team members of a sort that probably won't be conveyed through normal documentation.

---

This is generally a tricky balancing act. On the one hand the guru probably has a vision for the design of this area of code. They are going to want to ensure that everything fits well with this vision. Assuming that the vision is good to start with, this is no bad thing.

On the other hand you don't want to be stuck with the guru being the only person who can maintain/modify this code, or even worse that they actively reject involvement from other parties.

It's not going to work in the scenario described in the original question, but the best method of dealing with it is to not allow the guru to become so entrenched in their pet code in the first place. If they're any good, let them design it, and set the vision - and get someone else to actually help to write it from the start.

Answer 6

Here my thoughts:

• If only one guru knows how to go on in the development of the software, then the project is in danger. Nevertheless, there are cases when a "one-man-show" project creates unexpected success and just needs some more developers to go further.
• In most cases, it is ok to assume that the new guys are eager to participate in the development. Therefore, You can focus on not scaring them away.
• The guru will spent most of his/her time to teach the new guys about the design. Make this an assigned task for the guru. This way, the new guys are not "stealing his time".
• Tell the team, that there are new developers to support development. This may be obvious, but until said aloud, there former code owner may have a feeling as if his baby was taken away from him.
• Make sure, that the team members know each others assignments. If a developer knows, that his peer has to work on module X, he will likely drop or ease his code ownership on X.
• Pair and make pairing an assignment.

Summary:

• It's hard to say no, if Your project leader will get You some new team members and asks You kindly to show them how to lighten Your burden.
• Marketing is not only about products it's also about assignments and team members ;)