What would you say to bosses that think programming jobs are interchangeable?

Question

I'm in this software company, and I've only experienced two managers so far, but both view programming jobs as not much different from laying bricks. They always emphasized we should take on each other's jobs at any time.

As a result, our code has "group-ownership" -- no one owns anything, and no one is responsible for anything either. Or, in other words, everyone owns everything, and everyone is responsible for everything. If anything breaks, anyone may be dispatched to put out the fire, regardless of who created the problem. If you open up the code, it is quite chaotic, because different people have different ways doing things. Moreover, fixing other's code without much time allocated to understanding it first quickly ends up with patches upon patches upon patches. This never bothers our bosses, because they are result oriented; i.e., they never bother to look at anything down at the code level.

Someone might not believe it, but it is absolutely true, and we are a pure software company!

The justification they have is that when everyone is responsible for everything, when anyone takes a vacation, others can/should just swap right in and cover him/her, so s/he can enjoy vacation at any time. Once a guy had been preparing for a new module for more than a month, then took a vacation, and right before he left, he told our boss all the issues were settled, and it was ready to start coding. So on the next day's scrum, my boss told me, we've got to get this done next week, can you pick it up please?

I just couldn't believe what I heard, that guy prepared it for more than a month, but had never shared his findings with anybody else, and now my boss wants me to pick it up, out of the blue, without any prior knowledge, and finish it within a week.

I can't remember the details but I was lucky enough to find some logistic reasons/excuses to dodge the lethal bullet. He doesn't have the concept that taking over others' work midway is the most painful thing for programmers.

Is this common for software companies? How would you suggest for me to break the bad news to these (clueless) guys, that programming is much different from laying bricks, without them feeling embarrassed, and also convincing them, because they both strongly believe that everyone should be responsible for everything?

Answer 1

I'd tell them they are right, so how are we going to achieve that goal in practice?

In principle, this is a laudable and achievable goal. Let's look at the specifics:

If every single developer is working in isolation on their own little island with their own style and making their own choices independently this is a recipe for disaster. How will their work integrate with that of others? What if they are sick or on holiday? What if, god forbid, they get into an accident and become unable to work or even die? If they are the only person who knows how their code works and it takes a significant investment of time for their co-workers to understand that person's work, this threatens the continuity of the company!(This is sometimes referred to as the Bus Factor)

At the same time, every developer has their own set of skills and specialisations. Not everyone will be equally proficient with everything and that's okay! That's why you're working together as a team towards a common goal after all.

So what should be done in order to achieve a workable situation?

Firstly, the team should sit together and either choose a set of coding guidelines to adopt, or put together its own set. This eliminates the 'chaos' factor from the code: since everyone will be doing things in the same way, it should be much easier for fellow programmers to understand how things work.

Secondly, a system should be put in place that provides opportunity for the sharing of knowledge. If all of your time is expected to be spent writing code, there's no time to share knowledge, so the problem remains. Programmers should either have the time to document their code or to actively share their knowledge with others, or ideally both. Guidelines should also be established for the documentation of code to prevent potential issues that would arise from incomplete or insufficient documentation. While an expert might be able to understand a feature with a few short lines, someone who doesn't work with the feature regularly will need a little more information to get up to speed. The documentation should provide enough information for the second case.

Ideally, this knowledge sharing is supported by regular reviews of each other's work. This provides the reviewer with an opportunity to increase their knowledge of the code and at the same time helps your team increase the overall quality of the code since the extra set of eyes will help catch possible mistakes. It also helps the team in increasing their understanding of the overall quality of the product. If a lot of things have to be solved in a 'hacky' way then obviously the quality of the product will be a lot lower than if the same problems could be solved with nice clean code.

To steal the barber analogy, the ideal is that all the barbers(coders) will be able to finish each other's work because:

• they all use the same set of hairstyles

• they all cut with techniques and tools that are either the same or at least equivalent

• they document their progress on the haircut using an agreed system, noting what they've done, how they've done it and why they've done it that way

• they regularly take a bit of time to review each other's work, helping them become familiar with it

To address the OP's 'attitude' towards the issue, it may very well be that in reality, with the time the programmers have (due to deadlines and expectations on how their time is spent) and the highly specialised nature of each programmer's work, this goal is unachievable in practice. Regardless, it's much easier to help your managers see for themselves why the goal is unachievable, then to state that this is the case and then have to defend it. Therefore, if someone proposes something you see major issues with, try to respond with a constructive attitude i.e. "Sure, but how are we going to solve X, Y and Z?" rather than responding with a negative response i.e. "That's never going to work, because of X, Y and Z!". This helps the management to perceive you in a more positive light and in the end it is likely to generate a better and more pleasant working environment.

If achieving goal A means spending a lot of time, effort or money in solving problems X, Y and Z then it might not be worth the trouble, but this is a decision that management should make, so it is our job as employees to provide them with the necessary information to come to a well informed decision.

Answer 2

Collective code ownership is a thing within Agile development and it generally is considered a Good Thing. But it seems that your boss(es) have just taken one thing they like from the agile manifesto that fits them and ignored all the others.

For this to work you need to have a team that works tightly together and communicates often. Most assignments should be solved by pairprogramming, code reviews should be common and early, there should be a high degree of tests to inspire confidence in quality, preferably you develop using testdriven development, etc, etc.

That there is a common code standard isn't even an agile thing, its just common sense.

Answer 3

I think the problem is with you and not with your managers.

different people have different ways doing thing

You need to stop that right now, set coding standards, start working with designs and do become exchangeable.

When one of my coworkers goes on a vacation we get a document of what he's working on, what that progress is and what outstanding issues are and most important where the documentation is.

I think the heart of the problem is that you should start working more as a team.

And if you can't get there as coworkers it's the job of management to make that happen, they're paid for that.

Answer 4

Collective code ownership where each programmer can work on each part of the software equally well is an ideal that should be aimed at (because the benefits are real), but takes hard work to reach.

The team needs to enforce one style of programming so that code is immediately recognizable to everybody. The team needs to do strict code reviews so that knowledge of a bit of code is shared as soon as it is written, and the common standard of quality is ensured. You need to use a "definition of done" that makes sure that nothing is called "done" until it is documented, tested and reviewed. New members of the team need to get time and training to get up to speed with all the technologies used.

If the managers demand the results of such a process without first investing in implementing it, they are being unrealistic.

I think you should discuss with your colleagues what kind of changes you would like to make to your workflow to make this more possible, like starting with code reviews or pair programming, or agreeing on a common coding style.

Then, go to your managers, and say something like

I know you would like all programmers to be exchangeable, so that we can all work on any issue that may come up. However, we aren't there yet -- all of us actually know our way around only part of the codebase, and it's hard to adapt to other people's way of working. However, we do think it is a good idea, and we propose to implement X and Y to start working towards that goal.

Answer 5

It seems to me that the developers and the managers have staked out extreme opposite positions on the spectrum from individual code ownership to joint responsibility.

The developers could do more to approach the managers' ideal:

• Coding standards. It should not be chaos because different people have different ways of doing things.
• Consider pair programming. That way, at least two people understand every change.
• Get into the habit of looking for root causes, not applying patches on patches. I think most experienced programmers have had to track down bugs in code they did not write. It does take time and effort to do it right.
• Document, review, document, review.... The design that the person had been working on for a month should have been written up and understood by several people.

You may not be able to get all they way to the extreme flexibility the managers want, but you should be able to get well beyond there only being one person who can work on each piece of code. You may at times need to tell them "Joe or Nancy could do that faster", and let them decide whether to pay the cost for somebody else to pick it up.

Answer 6

Short answer: Point out how ridiculous it is.

I've actually run into this before, and I simply said something like:

Would you go to a podiatrist if you needed brain surgery? They're both doctors, right?!

Or

Do you go to a tailor to get your hair cut, because tailors use scissors just like hairdressers?

Then point out that there are very different skill sets associated with each specialisation. Tell them that programming is the same. Some developers are highly skilled in one area but are completely clueless in another.

It's not saying that you couldn't learn the other skills, but it would take time and a willingness to want to.

Answer 7

You wrote,

no one owns anything, and no one is responsible for anything either. Or, in other words, everyone owns everything, and everyone is responsible for everything

Those are two extremes (perhaps you should look for a middle way between the two extremes), and a false dichotomy.

Is this common for software company?

Depending on the number of programmers there are various possibilities.

One is to assign a team (of several) to each component. Expect anyone/everyone in the team to be responsible (if necessary) for (anything within) the whole component. A team might or might not have a single chief developer or team leader, who might or might not also be the team's official point of contact between the outside world (management and QA).

A minimum I recommend is code reviews. Each person is responsible for their own development, and takes days to code some new feature, and then one or more other people spend hours to review what's been finished and tested and checked in. The code reviewer[s] can suggest changes and can reasonably be expected (by management) to have understood what they reviewed. For example a review comment (before they accept or 'sign off' on the change) might be, "I don't understand this, you'd better rework it a bit and/or explain it better", or "what does this do, what's the function (e.g. visible in the functional spec.) that it's implementing, where's the automated functional regression test which will test this").

After (if) they do sign off on a change, it's reasonable for a manager to come along and say, "Look Bob's on holiday and/or has quit the company; we think there's a problem with this module you reviewed and/or we want to add a new feature to it. Could you have a look at that? You're familiar with (not to mention responsible for) it already, since you did code reviews when it was implemented."

Code reviews have many purposes, including:

• Cross-training on what components do and how they're implemented
• Ensuring common/consistent standards (of coding, documentation and/or testing)
• Quality Control (i.e. "white box" testing, looking for potential bugs)

Answer 8

Once a guy had been preparing for a new module for more than a month, then took a vacation, and right before he left, he told our boss all issues settled, and it was ready to start coding. So on the next day scrum, my boss told me, we've got to get this done next week, can you pick it up please?

There you have a manager who dropped his brain.

Yes, for each developer there should be at least one other he's intimately working with (pair-programming and the like) on each individual task (including hashing out the design for a new module), who should thus be able to take over without undue re-work at any moment.

But that's not the same as saying there's no overhead to switching mid-flight:
It should be about the same overhead, or ideally a bit less, as if the original developer dropped that task without tying up loose ends to handle some emergency, and then had to ramp up again after a week of working on something else.

Now, if you aren't the one he worked with on that task, you have only his notes, and however good they are (which is probably not stellar, or considering your description more like very patchy to non-existant), they simply cannot encompass all the details your co-worker worked out in that month.

It's like going to the hospital and taking the time for one doctor to carefully assess your condition over a month with repeated checkups, blood-samples, EKG, radiography and whatever else seems useful, and then going to the surgeon to treat you immediately, never letting the two communicate anything useful.

---

If you aren't the one he worked with, you should point out which co-worker did, and also warn that even though he would have a far easier time taking over than you, there is still a considerable cost, as he wasn't the one doing the preparation himself.

If there is no-one else intimately familiar with that preparation, you should mention that there should have been, and (depending on how the research was documented), that you might need anywhere from x% (your best guess as to the documentation and what you overheard) to the full time of starting from scratch.

---

In the end, it seems to be management failure:
The team-lead has to get together with the other developers and hammer out a coding-standard, as well as getting started to actually do pair-programming, unit-testing, code-reviews and all the other activities for ensuring quality and spreading the knowledge in the team.

Answer 9

Is it common? Not that much. But it can be set up to work.

The idea beyond is to avoid people as Single Points of Failure. Of course, it comes with a cost, and programmers pay the cost. That's why your boss will be tough to convinced it's a bad idea. He has all the advantages, and you all the drawbacks. Still, it makes sense.

It makes sense it you spend time with other programmers to exchange knowledge and practice. This can be done by reviews, pair-programming, or anything else that works for you. I've been in a team of 22 where one consultant(there since years) was spending most of his time roaming in the corridors instead of programming. He was the glue of the team, and at least 15 people in the team could work on the programs I did make. It can be anything else that suits the need, informal discussions, coffee-machine exchange of knowledge.....

But it has a cost. Worth to pay IMHO, but if everyone works on the same technology, it shall not be too costly. The cost is an heavy communications overhead. That's more what you shall communicate to your boss, as his idea is not bad in itself. Just, he has to understand it's an investment with non-immediate rewards.

Answer 10

The justification they have is that, when everyone is responsible for everything, when anyone takes a vacation, others can/should just swap right in and cover him/her, so s/he can enjoy vacation any time.

I know of one company (Menlo Innovations) that rotates "everyone" around "every" project on a set schedule. There is a way to make it work.

Management has set this as a goal, but have completely abdicated the responsibility of doing what is necessary to make it work. More people will need to be hired along with longer delivery schedules. They can justify this by demonstrating long-term results and not being held hostage by some guru who thinks he's the only person on the planet capable of coding his particular project.

The real problem with this is trying to implement some practice in isolation. They should have considered complimentary practices like: team development, testing, more extensive documentation, daily meetings to share and get everyone up to speed on what others are doing.

Answer 11

I think the following is a well-balanced conclusion, unfortunately someone just don’t like to hear it. I have received repeated requests to remove them. In a democratic world, every voice deserves to be heard. You don’t like to hear it is one thing, but trying to silence me is another thing, which isn’t very good IMO. So here it is again, my conclusion, killed from my OP.

Conclusion

I think it is time for us to stop the discussion and move on from this now. After carefully review, I've pick the one "constructive answer suggesting a constructive solution" as the answer. But in fact, all answers are very good, I wish I can pick more than one as the answer.

From the answers, I realized that it is a quite a controversial topic, that opens my eyes, because before that I was thinking my bosses are clueless. Now I realize that I was clueless before.

As Patricia Shanahan put, "the developers and the managers have staked out extreme opposite positions on the spectrum from individual code ownership to joint responsibility", and I can clearly tell which answers/comments are from managers:

• "A manager should always be able to ask someone else to pick up for a dev on vacation"
• "I think the heart of the problem is that you should start working more as a team."
• "What you need to do is not involve your manager"
• "The team needs to find a way to share this knowledge using code reviews, design reviews, pair programming and in general - Talking with each other"

Before you made such conclusion, please consider again the following fact, that guy prepared it for more than a month, but has never shared his finding with anybody else, and now my PM wants me to pick it up without any prior knowledge and finish it within a week. And moreover the fact that, for us to submit vacation request, we need at least a month, and more often we submit it two or three month ahead of the vacation. From this, I believe everyone would know where actually the problem is. I totally agree with TripeHound,

Probably more important than "The team needs to..." is "Management needs to allow the team to..." and accept that there will be major hit to productivity while this happens.

Admit it or not, the real problem has been pointed out by gazzz0x2z: "it comes with a cost, and programmers pay the cost. That's why your boss will be tough to convinced it's a bad idea. He has all the advantages, and you all the drawbacks", and I personally agree with RemcoGerlich, "If the managers demand the results of such a process without first investing in implementing it, they are being unrealistic", because afterall, as put by no comprende, "It takes time to re-understand even one's own code after not seeing it for a while, so it would certainly take time to understand someone else's. And, you can only pack so much in to your head: learning other people's stuff will not stick for long. There is a practical limit to sharing responsibility for code", "It would be good if all the Management team could exchange jobs also".

Ok, I know I've pushed it too far, and most managers here might not agree with me. So, let me stress, these are my own personal views, and let's end the discussion and move on. That's also the main reason I pick the one "constructive answer suggesting a constructive solution" as the answer -- managers and developers need to understand each other better, and more often than not, it is the managers that need to understand developers better. With such understanding, and the constructive solution, we will be there, just it won't happen overnight.

Answer 12

I'm in this software company, and funny thing is, I've only experienced two managers so far, but both these two managers view programming jobs not much different than laying bricks. They always emphasized, you guys should take on each others jobs at any time.

Thats a thoroughly ridiculous notion. Programming is a highly specialised field and different aspects of programming require vastly different skill sets. The best you can do is point that out to them. While analogies to other professions might be poinient and fitting (Tailor cutting hair, etc), your bosses might not believe them, so point out some of the massive differences in programming, like how different UI design is from performance testing, for instance.

But yeah, you should definately try to dispel that notion from your managers, lest they have a very harsh awakening when they find out just how wrong they are.

Answer 13

You can standardise coding conventions, tools, folders and way of doing things. But you cannot make it equal the knowledge about some intrincated functions and how some parts of code works. That's only owned for the ones who spend hours thinking about that. Explain to your bosses that its not laying bricks at all, I had to deal bosses ignorant like these, they are from the construction field and try to use the same standards at software industry, I cannot explain to you that it leads to big disasters, failed projects and high turnover of really good developers. Explain that to them. Every piece has its own way to work and is specific to business requirements. For exemple, you have a "brick" which can do some plus operation, another one minus and divide operation, someday one guy ask for a derivative or matrix function calculus can you compare such "brick" with the previous one? The guy who programmed the new matrix calculus has time to share its knowledge and at same time, stay at Schedule time? I don't think so.