This article originally appears on Luke's blog
I've been meaning to write this for quite a while, as the bus factor is something I've (literally...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for posting. I'm familiar with the issue..
In my experience, a healthy level of knowledge sharing is one of the hardest things to achieve within a team. Especially if you start using 'unfamiliar' techniques or libraries.
I'm a fan of
READMEfiles at the solution level, containing:With this information you can run the project and make a change. And when the time comes to make changes in the unfamiliar part you can learn it by copying and pasting from Stack Overflow :P
Wrapping up,
READMEwon't solve your 'bus-factor' problem but it's a cheap way to alleviate some of the pain.README files are good, but they have the same issue as any other documentation: developers don't like updating (obviously there are exceptions to that generalization).
I wrote an article about how to make developers update frequently their documentation and how to detect regularly the bus factor.
Hope it can bring some new ideas :)
Thanks! That's a fantastic idea and one I'll definitely bring up with my team.
I think that
READMEsuggestion mostly stems from past annoyances with projects that make you figure it out all yourself :)You mentioned your experience with wikis. I wonder, how did that work out? Was it well adopted? What sort of information would you put in there?
For one thing I like that it's hypertext.
Overall wikis have been good. We use the full Atlassian Suite so Confluence interops with everything else. The big problem is that the wiki isn't linked to the code at all, so things can change and people always forget to update. The only real solution we've found is to try and be vigilant about Documentation. Since we do code review on all branches it might make sense to try and have the reviewers also catch any documentation updates that are required.
I used to use the term bus factor but people have found that too gloomy (they don't want to think about death). I've therefore started using the term lottery factor instead when talking about other people's bus factor: "If people win the lottery and walk out the door with not a care in the world".
Although, I still think about it as the bus factor when thinking about my own work.
My mentor calls it "getting hit by the lotto bus".
Great thoughts!
Having a team wiki is great for tasks like generating certificates, team accounts etc.
Also, I'm a fan of team collaboration. Code reviews, open seating, whatever works for your team. Have the junior devs sit with the senior devs and talk about what each are doing. Have demos. Be open. You should never be completely in the dark about anything going on throughout the team. :)
Jess often utters the phrase "bus factor" to me, as either a reminder to get caught up on documentation etc. or my propensity to walk around New York City in a cloud of thought as buses wiz by.
In Canada the cars just stop for you 🇨🇦 😝
Only if you're a pedestrian 😝
I'm not a big fan of technical documentation on code except where absoultely necessary. What's worse that having no documentatino is having misleading and outdated documentation, especially when you can't ask the author anymore.
To reduce the bus factor, and just because it's good coding, I recommend:
Good topic Luke Bearl.
I really liked this post.
The idea of documentation is crucial on a organization.
Many people don't like it. But it's important.
It ends up being more important to ourselves.
Another technique that can help reduce the bus factor, is "Parity". Working in pairs can help reduce this bus factor.
Sometimes it seems wasteful of resources, having two people in one task. But for critical cases it's worth it.
Recently, I wrote about the common mistakes people make on the daily scrum.
Take a look at this:
tfsolucoes-tecnologicas.com/14-com...
I hope you like it. And maybe it will help with a good communication on your team work. Communication is crucial.
Hi Ted, very good points. I agree that every team should look at every technique that they can to see if there is anything out there that will work well for that team in order to reduce the reliance on a few people.
I enjoyed your article on issues with daily scrum as well :).
I like the term “inverse bus factor”, in other words, “how many people need to be hit by a bus before the project starts to run smoothly?” 😂
Fingers crossed most of us don't work in organizations like that.
The term is to "increase the bus factor", not reduce it.
Guess it depends on the definition.
If the "bus factor" is how vulnerable your organization or project is to someone leaving or become unavailable, I think you'd want to reduce it that factor.
Do you have other definition than en.m.wikipedia.org/wiki/Bus_factor ?
Yes, the one I just described. The one the article also appears to be operating on.
Generally speaking, I don't think it is a rigorously defined concept. I've never heard it used in the way the Wikipedia article suggests; indeed, the "rare alternative definition" it suggests is more common parlance in the few times it has come up in any kind of conversation.
what you call the bus factor some people call job security:
twitter.com/thepracticaldev/status...