Is bus factor well understood?

Is the bus factor something completely wrong as it's understood? Is the way it's dealt with wrong? Couldn't it be looked at as a management and staffing failure instead of the fault of the one developer? Scenario: you have a single member of your team that can do things that no one else can do. First off - how did you get to this point? So you have someone with a lot of specific knowledge. Why can't your other developers read documentation? Why can't your other developers ask for help or read code? Why are they on your team if this is the case? If you don't have documentation or readable code, why did leadership accept these pull requests? If you don't have pull requests, jesus christ what are you doing? Say you've prepared in these ways, but developers still can't make changes as well to existing code. Where are your tests? If it's not tested, why not replace it? If your team members can't even replace it, what are they doing on your team? Common solutions: make the member of your team do pair programming, teach, or take on weaker members of the team as apprentices. Okay, so you didn't know any of this stuff or you're just a bad developer and now you have a low bus factor. Why actively cripple the only person getting things done? Get them to write documentation and write tests as mentioned before. Get people to rip things out that no one understands as mentioned before. Final solution: get rid of the team member. You've had a low bus factor for a long time and your team can't recover. Everyone's morale is low, people have gotten lazy. Move your teams around to get people who can keep up, fire the other members, but for the love of god don't fire your best developer. Not having a consistent team is like having a class with people doing their postgraduate mixed with an elementary school class for special needs kids. Classes are separate for a reason, and you should break up your teams accordingly. Put the people who are going to make macaroni drawings in art class, and put the postgraduate in a room and let him work. So, this brings me back to my original point. Why is this understood as a problem of the guy walking in front of the bus? It's the guy standing on his shoulders, the manager, and the people he's dragging behind him, his colleagues, that are a big part of the problem. It shouldn't take an oncoming bus to get off of his back.

>>4683 >Why is this understood as a problem of the guy walking in front of the bus? The premise is false because it is not always understood that it is the "hit by a bus" guy's fault. You are likely speaking from your limited experience. I also have no demographic studies to back this claim up but anecdotally this hasn't been the case in places I've worked. It's been the management's responsibility to task people with technical documentation wherever I've worked. If leadership don't lay out guidelines like "Provide stable images" or "document your code" or "write a decent readme" or "put all your code on our repo", it is the leadership's fault. If these rules do apply and the employee does not follow them, the burden would fall on the employee but ultimately it would be also their direct supervisor's responsibility for not checking in and making sure the guidelines are being followed. What's the context of your rant? Did somebody hurt you?

>>4685 And from what I've seen documentation initiative has gone beyond writing software and into hiring, HR, and customer service.

>>4685 There has been a lot of talk about bus factor at my work ever since that article where a team had to fire their best developer. I also looked up common management approaches to bus factor and didn't like what I saw. Hoping to prevent some lainon from making a mistake.

>>4683 Fun game. >Why can't your other developers read documentation? There is no documentation. >Why can't your other developers ask for help Busglitterboy does not have time to help mortals. >or read code? Understanding the whole system by only reading source code would take a long time. You cannot do nothing but read source code for 10 months, you will get fired. >If you don't have documentation or readable code, why did leadership accept these pull requests? Because busglitterboy is solo in charge of pull requests with no oversight. >If you don't have pull requests, jesus christ what are you doing? This is a retarded question. The only companies that wrote perfect code from day1 ran out of money before release and closed down. >Where are your tests? No tests. >If it's not tested, why not replace it? Because you can't replace something without being able to test it? This is a weird question. >If your team members can't even replace it, what are they doing on your team? Presumably you are speaking from a competence stand point? While we're on the subject of testing, I actual wrote unit tests and busglitterboy deleted them because keeping the tests passing was slowing him down (this value we get from the untrusted network should never be negative so why do we need to waste time checking for that hurr durr). >make the member of your team do pair programming, teach, or take on weaker members of the team as apprentices. busglitterboy does not have time for this bullsoykaf. Even the cto may not be able to force him. >Why actively cripple the only person getting things done? I don't know what this is supposed to mean. >Get people to rip things out that no one understands as mentioned before. Sales already sold the next feature we didn't even start working on yet. There is no time or resources to rewrite things that basically already work. >Get them to write documentation and write tests as mentioned before. busglitterboy refuses and tells you he does not have time while we watches youtube at lunch. I'm not sure if you didn't express yourself well or if you just don't have much industry experience yet but I'm not convinced.

>>4696 >Understanding the whole system by only reading source code would take a long time. You cannot do nothing but read source code for 10 months, you will get fired. I am not saying read the entire codebase. I am saying read things as needed. >This is a retarded question. The only companies that wrote perfect code from day1 ran out of money before release and closed down. Having pull requests doesn't mean you don't let in anything that's not perfect. It just means someone makes sure commits are up to standard. >Because you can't replace something without being able to test it? This is a weird question. Code that is unintelligible and untestable is legacy. Programmers should replace code as needed when addressing bugs for incremental improvement. >I actual wrote unit tests and busglitterboy deleted them because keeping the tests passing was slowing him down How many tests are we talking? >busglitterboy does not have time for this bullsoykaf I was saying don't do that >There is no time or resources to rewrite things that basically already work. You don't have time to NOT incrementally improve your code. If you have no way to check that you're not causing 5 bugs by fixing one, make sure that you're not causing 2. That way the second and first points will be tested for the next infinity bugs in that area. >busglitterboy refuses and tells you he does not have time while we watches youtube at lunch. Everybody needs a break. See what I'm saying? You get out of this little by little, no one cures a company overnight by throwing out someone they put into a difficult situation. Your particular bus boy sounds completely rotted. He needs a long break and a fresh team.

The "bus factor" illustrates why Agile methodologies are so important. Agile methodologies revolve around a task mangament system (ie like a Trello board) and so you have a clear and visible list of thing that need to be done, who is working on it, who is not up to speed, etc. Both huge tech companies (ie Yahoo) and small startup have gone belly up simply because they were relying on "rock stars" to get stuff done only to find out these people were unable to architect the systems they claimed they could. There are two major problems, one is that there is too much fluff and buzzwords being thrown around at high level meetings that get taken as as actual work instead of the bullsoykaf it actually is. Again, Agile methodologies can expose a lot of this bullsoykaf. And also HR has to do a better job of assessing the ability of applicants. And people who are already hired need to be vetted to bring them up to speed with what ever technologies are being used. Again, Agile methodologies are a good way of exposing 'rock stars' who are hoarding critical parts of the system by showing exactly who is responsible for what tasks.

Relevant: https://medium.freecodecamp.org/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde And a response: https://medium.com/@deusexmachina667/you-fired-your-top-talent-i-hope-youre-happy-cf57c41183dd

>>4698 >I am not saying read the entire codebase. I am saying read things as needed. I'm talking about a company with a mature and complex product, not some useless silicon valley web app you can draw on the back of a napkin. >Code that is unintelligible and untestable is legacy. Programmers should replace code as needed when addressing bugs for incremental improvement. Programmers cannot do this without management buyin or collaboration with busglitterboy. Neither of which you will have if you are in this situation to begin with. >You don't have time to NOT incrementally improve your code. Yes, this is correct in the long term but busglitterboys and companies that nourish them are never thinking past the next release deadline. >Everybody needs a break. It is not acceptable to say you are too busy to do a task that will genuinely help your company and coworkers and then dick around on youtube instead. >See what I'm saying? You get out of this little by little, You can't without the help of management and/or busglitterboy. >no one cures a company overnight by throwing out someone they put into a difficult situation. Busglitterboys are actively damaging the long term survival of the company. It *is* their fault. Just like it is the tumor's fault for killing the cancer patient. They need a good manager to give them a slap or be fired.

>>4723 I'm not going to continue elaborating my points. Sounds like you're in a tough situation. My intention was not to encourage point-by-point breakdowns of my questions, but rather to get different viewpoints on commonly held beliefs about bus factor. I am here to learn more about this sickness of the industry. I would appreciate your thoughts on what you think your company should do. I would also like to discourage inflammatory talk about who has more industry experience, the bigger project, etc. If you'd like to include that information or ask for more details, that's fine, but don't compare it unfavorably with other people who have shared no such data. We've all seen different things. I don't think you've said anything awful, but I'd like to nip that in the bud.

>>4725 >I would also like to discourage inflammatory talk about who has more industry experience, the bigger project, etc This kind of context is important because you are looking at everything through a single dimension. When you say things like this: >Where are your tests? If it's not tested, why not replace it? If your team members can't even replace it, what are they doing on your team? Yes it's that easy when your project is just some web thing with zero consequences for making a mistake. Some people have serious jobs though. Projects where you can't just rewrite some random thing because you feel like it and go "oops it didn't work sorry guys no big deal".

>>4731 If you would like to know my experience level for context I will be happy to comply.

>>4732 >If you would like to know my experience level for context I will be happy to comply. You're going to tell me you have 35 years experience or something? This is a common fallacy in our industry. People think that because they made it X years without getting fired, that somehow makes their opinions more valuable. You fail to realize that any monkey who can type on a keyboard can get a job writing code. This is an anonymous image board, I don't care who you are I only care about what you say. What I am saying is that this easy-peasy-just-rewrite-everything approach does not work in all industry sectors. You saying "but I'm really old" is not a valid response.

>>4733 I only mean that I am happy to end the speculative discussion of experience through posting more or no details. No details it is.

>>4735 I realize I dug myself a hole by saying your opinions are naive and indicative of someone with little experience and then said experience doesn't matter as much as people like to pretend it does anyway. I don't think that a purely anecdote based discussion like this is a good match for an anonymous image board but good luck I guess.

>>4696 This guy. He gets it. Thanks, you saved me from writing the same thing you just did