It’s Our Code

Background

I’m sure what I’m about to talk about here doesn’t just relate to programming–it relates to any team-based project where everyone works on a small portion of the big picture. My experiences are primarily geared toward writing code in teams, so try to find parallels in your own work/experiences if you’re not a programmer. Anyway, enough of that.

When someone puts a lot of effort into something, they’ll often take great pride in the finished product. Of course, it’s great that they do! They’ve slaved away at something at work for days, weeks, or months, and it’s finally working/implemented. Other people are using it and it’s doing its job as expected. Awesome!

What kinds of things could possibly go sour here? If you have experience working in teams to complete a project, you might have some ideas.

Ownership

You don’t own anything. You don’t own a single sentence or character you type and share with your team. You don’t own the title you came up with for the document, the name of a class or interface in your code, the conventions for indenting your variable declarations, the overall file & folder structure of your code, or even the Powerpoint you want to show to the sales and marketing department. If you’re on a team, you’re creating content for your team and your team assumes ownership of it (technically, I guess your company owns everything you do… but… stick with me on this one for a bit).

Ownership becomes a big problem in team environments. Person A worked on Item X, so Person A is assumed to be the owner of Item X. Now every time someone wants to use Item X, they need Person A. Simple? Yeah, that’s a simple system, but it’s absurd. Why don’t I just work on the most important part of the project, encrypt it, and secure my job for the rest of eternity? It’s hard to swallow sometimes, especially after pouring a lot of time and effort into something, but when you’re part of a team you should always be working in order to create things for your team. This has two major benefits:

• You’ll adjust your perspective to be that of your entire team when you’re making something. (i.e. Am I working to their standards? Am I using their conventions? Can someone else understand what I’m writing here? Will this be easy for them to use? Can someone easily come along and modify my work to improve it in the future? etc…)
• You remove the people bottleneck.

Ask the Experts

Instead of ownership, people should be considering “expertise”. What’s the difference? Well, someone who owns something is entirely responsible for it. If you want to use it, you ask the one owner. If you want to change it, you ask the one owner. If someone asks you about it, you better direct them to the one owner. The one owner becomes the bottleneck for whatever they own.

An expert is someone who has extensive knowledge in the area and there can be more than one. If you want to use something, you consult one of the experts for proper usage. If you want to modify it, you consult the experts. If someone asks you about it, you can direct them to any of the experts. See the difference? You widen (or eliminate?!) the bottleneck. You increase how robust your team is in terms of responsibilities.

What happens if Bob is sick for a week and he’s the only one who knows how to use the data layer when a big customer bug comes in? What happens when your co-op student who wrote your patented fizz-buzz algorithm leaves to go back to school and no other developer knows how to maintain the code? If there’s only one owner in each of these situations, you’re in a bad spot. If there are several experts who are knowledgeable in the area of code in question, you’re laughing.

Keep in mind, there aren’t only changes in your development staff–your code base is dynamic too.

Code Changes

One huge benefit that software has over almost any other product is that it’s dynamic. You can build something now that works, that may not work next week, that can be fixed the week after, and then later completely rewritten the week after that… and… well… you get the idea. Sure. I know you’re capable of thinking of situations where this doesn’t work with software or products that can somehow get the same benefit, but I’m not contesting that. The point is that software is (usually) flexible and dynamic and you need to treat it like that.

When a group of people has control over software, they can guide the direction it grows in. You get multiple people who are knowledgeable in the direction that the software can take and you leverage the group’s knowledge and experience collectively. Obviously consulting every single person on the team to change a single line of code is overkill, but at least you can find a happy medium in terms of architectural and API changes.

Your code changes because unless you executed the waterfall approach to programming 100% perfectly, your architecture is likely going to change. It’s just a fact of life. But there’s absolutely no reason to freak out. Embrace it. You’ve written unit tests for a reason, right? You’ve used interfaces and designed a nice clean API to decouple your code and make such changes easy. Duh! So don’t worry! You have a couple experts in the area of code that needs to change, so either they can tackle the changes or guide one of your more junior developers.

The same thing should hold true for any process or on-going project that is dynamic. Take measures to ensure that changes in the project or workflow can be done by anyone and don’t jeopardize the whole operation.

Tips

Here’s an assortment of tips (and hopefully some parallels for the non-programming types):

• Use some sort of revision control. When something bad happens with your work, you always want the ability to press a figurative undo button. Look into something like Git, Subversion, or Mercurial. There are others out there too! Source control software isn’t just great for programmers… If you’re collaborating on a document of any kind, you can leverage source control to manage the revisions of the document.
• Use tools that allow working on things in parallel. Again, source control helps here for programmers… but find solutions that mirror this. Look at Google Docs! You can literally work with people at the exact same time!
• Practice and embrace the fact that you don’t own anything… It all belongs to your team, collectively. Keep that in mind or your team may start finding better team players! You want everyone to feel like what they are working on is for the team.
• When you have something that’s dynamic and changes (like code), take the necessary steps to facilitate and embrace changes. Take precautions to ensure changes don’t mess everything up (unit test & code review!)

Summary

When you’re working in a team, you need to be thinking about your team. What you’re working on belongs to your team and shouldn’t be treated as your personal pet project that you control. This works best when you have multiple “experts” that have knowledge in a given area that can make changes or guide others to make the required changes. If you’re working on something that is dynamic or changes often, you can ease some pains by planning for change. Don’t resist it and fall apart when changes finally happen.

The post It’s Our Code appeared first on Dev Leader.