Iyfjky

Question

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.

As the result, our code has a "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 who created the problem. If you open up the code, it is quite a chaos, because different people have different ways doing things. Moreover, fixing other's code without much time allocated understanding them first, will 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 just couldn't 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 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 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?

I just can't believe what I heard, that guy prepared it for more than a month, but has never shared his finding with anybody else, 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 detailed but I was lucky to find some logistic reasons/excuses to dodge the lethal bullet. I.e., he doesn't even have the concept that taking over others' work midway is the most painful thing for programmers.

Is this common for software company? How would you suggest for me to break the bad news to these (clueless) guys, that programming are much different than laying bricks, without them being felt embarrassing, and also convince them, because they both strongly believe in everyone should be responsible for everything?

Hooookay folks, lots of chatting and discussion here. Keep in mind comments are not for extended discussion - everything got moved to chat. Please take further meta-discussion to that chat room, too. Thanks! — Jan 7 '16 at 19:01

score 144 · Accepted Answer · 2016-05-18 06:30:58Z

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.

Yay, a constructive answer suggesting a constructive solution. — Jan 4 '16 at 13:23
It would be good if all the Management team could exchange jobs also. President is out? No problem. — user37746, Jan 4 '16 at 18:38
"It would be good if all the Management team could exchange jobs also", Haha, that's a good one, a really good one. — Jan 5 '16 at 2:13
"If they are the only person who knows how their code works and it takes a significant investment of time for their coworkers to understand that person's work, this threatens the continuity of the company!" My boss calls this the Bus Factor. — Jan 5 '16 at 6:09
Writing code is a bit harder than cutting hair. A better analogy might be designing a building. One architect leaves, and the next comes in and finishes. If the first architect had only finished drawing in 95% of the supporting girders, the second architect would have to notice this. It may be non-obvious. A lot of communication would be required. — Jan 7 '16 at 11:37

Fredrik 4,33521429 · Answer 2 · 2016-01-04 07:45:22Z

up vote
138
down vote

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.

answered Jan 4 '16 at 7:45

Fredrik

4,33521429

67

+1. I think the OP is trying to solve the wrong problem - it's quite clear there is no communication going on either within the devs or between them and management. A manager should always be able to ask someone else to pick up for a dev on vacation; so they need to organise (and enforce if necessary) knowledge sharing.
â€“Â Julia Hayward
Jan 4 '16 at 8:58

2

I agree with the both of you. The expected practices are good and they are trying to push you to use these methodologies, now the mind shift needs to happen. 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
â€“Â Sigal Shaharabani
Jan 4 '16 at 10:50

7

@SigalShaharabani 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.
â€“Â TripeHound
Jan 4 '16 at 12:57

4

@TripHound Well... not really. The management doesn't care and it will never care, that's simply the way things are. Development is the responsibility of the developers - it's their dayjob. The key thing is to keep delivering while you make those changes - learn from the experience of companies like Netscape/Mozilla. And don't treat "code reviews, pair programming..." as separate from development in any way. If the tests aren't green, the code isn't ready. If the build doesn't run, the code isn't ready. If the code wasn't reviewed, it isn't ready. It will make your life much easier :)
â€“Â Luaan
Jan 4 '16 at 13:48

7

@Zibbobz (and @Luaan) It's both: the developers must want to make a change, ideally led by someone who knows how to make that change (not the same as someone who knows the destination); management must encourage this change and be aware/accept that during such change productivity will probably drop.
â€“Â TripeHound
Jan 4 '16 at 16:24

Â |Â
show 8 more comments

score 83 · Answer 3 · 2016-01-04 18:40:10Z

up vote
83
down vote

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.

edited Jan 4 '16 at 18:40

answered Jan 4 '16 at 9:12

Pieter B

1,664513

10

How is this a problem with OP and not with the managers? OP should be able to adopt different coding standards, but should he follow the standards that bob uses or the ones that bill uses?
â€“Â Taemyr
Jan 4 '16 at 11:14

24

@Taemyr Bob and Bill and the OP should get together and agree on coding standards. The job of the managers is to make that process happen if Bob, Bill and the OP can't.
â€“Â Pieter B
Jan 4 '16 at 11:34

9

"I think the heart of the problem is that you should start working more as a team." => We REALLY need a "+100" button for individual sentences in this forum.
â€“Â Wesley Long
Jan 4 '16 at 16:46

4

I have never worked on a team that I didn't lead where anyone but me cares one bit about coding the same way. How do you suggest that the OP get everyone to agree on and follow coding standards, assuming he/she is not team lead?
â€“Â Amy Blankenship
Jan 4 '16 at 17:20

2

Where in your answer do you say it's a management job to get the programmers to set coding standards, working with designs, and becoming interchangeable? Maybe you should edit it to make that stand out.
â€“Â Amy Blankenship
Jan 4 '16 at 18:38

Â |Â
show 10 more comments

Communityâ™¦ 1 · Answer 4 · 2016-01-05 02:39:29Z

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.

I think this answer would be improved by listing steps for the OP to get the kind of buyin necessary to do that last paragraph. IME usually one programmer cares about this sort of issue and the rest don't want anyone else telling them how to code. — Jan 4 '16 at 17:23
@AmyBlankenship: I agree about one programmer caring, but I can't add an answer to that problem (as I haven't found out how to do that yet, as one programmer on the team...) and I feel it would go too far beyond the question as asked. Anyway he needs to convince management, things can change if management starts pushing for change. As just a team member with a management that doesn't care in my experience you can't do enough. — Jan 4 '16 at 19:05
The "style of code" argument is overstated. A shared style may solve some team issues, but it does not solve the underlying problem. A style guide is helpful is because developers are code illiterate. The developers need to practice reading other code to become literate. ...A person who can only read their own English papers is not English literate and a developer who can't read other developers' code is equally illiterate. ...If this is you don't be sour, instead download and rewrite a major opensource project monthly for 4-6 months. You will be amazed at how easy reading code becomes. — Jan 8 '16 at 15:16
@Nathaniel: I'm thinking of my esteemed colleague who writes functions of 800+ lines, that I find unreadable, and that he considers a matter of taste. He doesn't understand my classes with lots of small methods. Of course our code reading skills can always be improved, but I'd prefer to have some kind of agreement on this. Of course putting emphasis on tests would sort of solve that too (he is unable to unit test his functions). — Jan 8 '16 at 15:24
If someone is using methods to practice procedural programming in an OO language, they should be corrected. There is plenty of documentation for every language that shows proper use of methods. A method should only do work that is described by the name of the method. For example, if they happen to name their method DoAllTasksAssociatedWithTheCreationOfANewUserAndUserProfile then it may be large, but you should be able to consume it the same. You could point out that it has 2 concerns. On the other hand if it only says SaveUser and it does many other things they need to acquiesce. — Jan 8 '16 at 15:36

Patricia Shanahan 16.2k53256 · Answer 5 · 2016-01-04 09:47:58Z

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.

Agreed on all points except I'd much rather see good names (httpResponseData rather than data, for example) and tests (working and simple) than documentation. The latter is subjective, and is guaranteed to be incomplete (otherwise it would be code). — Jan 5 '16 at 11:13
@l0b0 I agree with you in regards to code. I beg to differ in things like specialized setups needed, specialized tools, differences between inhouse and standards and other things hard to know by reading the code and typically tribal knowledge. — Jan 5 '16 at 17:31
@l0b0 Code is much more difficult to read if interfaces are not documented thoroughly. I've sometimes had to dive several layers deep just to answer a simple question like "Is this pointer permitted to be null?". — Jan 5 '16 at 18:32

score 14 · Answer 6 · 2016-01-04 04:57:15Z

up vote
14
down vote

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.

edited Jan 4 '16 at 4:57

answered Jan 4 '16 at 4:50

Jane Sâ™¦

40.8k17125159

14

Skills crossover can be really great for business continuity. In my office I'm the only .net developer and we have a lot of c# floating around. If I get hit by a bus, they are shafted.
â€“Â Gusdor
Jan 4 '16 at 8:49

10

I don't think this answer applies here, because the OP doesn't mention a different skill set. It's about code ownership.
â€“Â Chris
Jan 4 '16 at 9:27

22

If you're going to podiatrist but he's sick, you expect the replacement podiatrist to get your dossier and pick up where the other left off.
â€“Â Pieter B
Jan 4 '16 at 9:36

3

@Chris If they're in the same team and have compatible skillsets, then I absolutely agree with you and my answer does not apply. However, the OP implies that there is a skillset differential (at least to me), which is why I answered as I did.
â€“Â Jane Sâ™¦
Jan 4 '16 at 9:59

11

This suggestion seems glib and sarcastic and unlikely to win the OP any favour with his/her bosses. Pointing out the issues in concrete terms (e.g. with reference to any literature on programmers' productivity) and offering some suggestions for how to improve things (e.g. agreed common coding standards) might be more constructive.
â€“Â nekomatic
Jan 4 '16 at 13:22

Â |Â
show 11 more comments

ChrisW 2,514717 · Answer 7 · 2016-01-04 15:29:17Z

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)

+1 for your breakdown of the code review process, instead of just saying "do code reviews". — Jan 5 '16 at 14:03
Agreed. The balance in agile is that developers should have areas of expertise and areas of responsibility, but that should form organically. In Agile Ownership is not a secure military facility where no one comes in or out. It is a shared space like a park and the park ranger is responsible for preventing its destruction and working with volunteers to improve the space for everyone. — Jan 8 '16 at 15:21
@Nathaniel Does "agile" use teams and/or team leaders assigned to components? E.g. I was once had a job where I was the most senior and "chief developer" with (eventually) 20 or 30 other developers: other people did their things (were assigned responsibility for developing specific components) but I expected in a pinch (e.g. if they quit) to be able to take over or reassign the maintenance of their code. — Jan 8 '16 at 15:29
20-30 developers is too large for an agile team. Generally when a team gets that large something serious is wrong. See weak code ownership: martinfowler.com/bliki/CodeOwnership.html — Jan 8 '16 at 15:53

gazzz0x2z 5,93621634 · Answer 8 · 2016-01-04 10:08:06Z

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.

score 6 · Answer 9 · 2016-01-04 22:47:46Z

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.

score 3 · Answer 10 · 2016-01-05 15:34:29Z

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.

For some reason, the edit link is disabled. The company is Menlo Innovations and the url is menloinnovations.com — Jan 5 '16 at 4:59
@Dancrumb - I corrected the spelling of innovations. The URL was correct. — user8365, Jan 5 '16 at 15:35
Gotta point out, very few organizations ever need daily meetings. Several per week, sure. But what occurred from Friday's standup and Monday morning's? bupkis. (unless you're like plotting out tasks at the hourly level, you'd have my sympathy) — Jan 7 '16 at 16:45
@ChrisMarisic - So in a Monday morning stand up meeting your going to say on Friday, I did nothing, nothing else has changed, so I'm just going to do today what I said I was going to do on Friday? — user8365, Jan 10 '16 at 13:17
@JeffO for the most part every single standup meeting i've been in pretty much goes "i'm working on what i said Today - X days ago" and maybe once or twice a week a person says "Finished Y, moved on to Z" which would be visible in any accessible status indicator (kanban board, backlog etc). The only other type of standup meetings I've ever been just turn into full meetings with people standing around for 30-75 minutes discussing something that half the team probably zoned out on minutes in. — Jan 11 '16 at 15:38

grn 7602516 · Answer 11 · 2016-01-08 23:25:58Z

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.

Magisch 16.5k134776 · Answer 12 · 2016-01-04 08:45:49Z

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.

I don't think this answer applies here, because the OP doesn't mention a different skill set. It's about code ownership. — Jan 4 '16 at 9:29
@Chris The general statement of the bosses applies here, though. "Programming jobs not much different than laying bricks" is what this is aimed at. — Jan 4 '16 at 9:29
It's not clear if the managers stated it like that, probably it's a phrase of the OP. — Jan 4 '16 at 9:34
"different aspects of programming require vastly different skill sets" is true, but a developer who is cross-skilled (even if only to an extent) in the jobs of other team-members is much more hire-able than one who insists on never leaving their own specialism. — Jan 4 '16 at 15:30
The current trend is for full stack developers, so it seems to be expected that some developers, at least, will have mastered multiple aspects of programming — Jan 4 '16 at 15:50

lambdapool 111110 · Answer 13 · 2016-05-12 13:01:15Z

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.

score 144 · Accepted Answer · 2016-05-18 06:30:58Z