Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I interviewed for a job at a company where they said their policy is to make sure that at least 2 people understand any piece of code, just in case one of them "goes on vacation". They also said that some people don't last more then a few months at this company, although many have stayed for years.

I think I get the message: They are inclined to fire people right away who don't like the work culture or who don't integrate into their cliques. But is there another interpretation?

share|improve this question
It's prudent to cover your code with more than one developer if you can. During the interview, feel free to ask why your job is available and any feedback they can give you for the turnover rate. Otherwise, how would we know? –  JeffO Aug 25 '11 at 21:35
They also said that some people don't last more then a few months at this company -- Did you ask why? That would almost be a reflex action for me. –  Robert Harvey Aug 25 '11 at 21:38
@Robert Harvey: Also ask if they serve Soylent Green in the cafeteria on Tuesdays. –  FrustratedWithFormsDesigner Aug 25 '11 at 21:56
Flannakopilis: Yes. There is another interpretation. There is never only one, ever. –  doppelgreener Aug 25 '11 at 23:12
I wouldn't worry much: the part about 2 people is just safety, to avoid losing time if the key developer is away (for any reason, planned or unplanned) which is a good thing: trust me it sucks if you can never be away when none of the other devs can pick up the project and continue it, you can't advance further in your career. –  wildpeaks Aug 26 '11 at 3:53

5 Answers 5

Possibly... Maybe they want you to work harder. It may just be a new employee joke. Or it may be exactly what they said. We can't read minds. Especially if we can't see the person :-)

share|improve this answer

I'd be inclined to think they are thinking about the "Bus factor"

...a software project's bus factor (also known as truck factor, or bus/truck number) is a measurement of the concentration of information in individual team members. The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar. A high bus factor means that many developers would need to be removed before the project would necessarily fail.

"Getting hit by a bus" could take many different forms. This could be a person taking a new job, having a baby, changing their lifestyle or life status, or literally getting hit by a bus: the effect would be the same...

share|improve this answer
...and if some people don't last more than a few months, maybe the company is located across the road from the bus depot? ;) –  FrustratedWithFormsDesigner Aug 25 '11 at 21:49
This - one of the things I am trying to do is ensure other people have a notion of my code and what's going on with it. Frankly, those buses are brutal, and one never knows when one will swoop down on you... –  Paul Nathan Aug 26 '11 at 0:14

I have a problem with the whole concept. They should do team code reviews where everyone on the team understands the code, not just two.

share|improve this answer
That would be ideal. If the code-base is huge, it's hard for everyone to understand everything, so maybe they try to break the program down in such a way that for each "chunk", at least 2 people can be experts in that section. –  FrustratedWithFormsDesigner Aug 25 '11 at 21:48
If the codebase is too big for a single person to grok, perhaps this explains the "some people don't last more than a few months" statement. –  Christopher Mahan Aug 25 '11 at 22:03
Good in theory, hard to do in practice. Imagine a code base with several million lines of code. You will end up wasting certain peoples time just to strive for a 100% ideal that you probably never need. –  JensG Nov 2 '14 at 10:49
@JensG: Several million lines of code? 100 000 lines are enough. Even less, if you want people to really understand the code and not only to know where to find what. –  Giorgio Nov 2 '14 at 12:19
I think at least 123456 lines of code. Maybe 2 more. –  JensG Nov 2 '14 at 18:54

I don't normally saying the policy is to have 2 people that are expert on any piece of code would be trying to send a message. They just want to be sure they can continue operating if any one person leaves (or goes on vacation, actually), which eventually will happen at any company.

However, not having people last more than a few months, or generally having high turnover, is a red flag.

I'm not sure from the question why you took their policy as an implied threat, or why you already believe they have cliques, but it doesn't sound like you are feeling good about working there.

If you have any way to speak informally to some current or former employees it sounds like it would be good to know more about the work environment. Maybe you can find former employees on a social networking site?

share|improve this answer

You interpreted that everyone who leaves is fired, and that might be accurate but people may also leave because they don't feel that they fit the job. In Ontario it's standard (it may be law) that in the first 90 days of a new employment either party can terminate the employment for any reason. Not everyone is a good fit and not every job is as interesting as the ad for it.

As for the 2 people part of your question, it's undoubtedly the bus factor that was pointed out in this answer. You can safely substitute "go on vacation" for "die", "quit" or "leave the company or not be available to consult on a programming role for any other reason".

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.