You've successfully subscribed to PTSD Engineer
Great! Next, complete checkout for full access to PTSD Engineer
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.

Do developers fall under buses?

The bus factor evaluates the dangers of information and capabilities not being shared among the team.

PTSD Engineer
PTSD Engineer

Monday morning


Project Manager: "What happened? Why are you crying?"

Wife of the Rockstar developer: "James got hit by the car yesterday. It was dark, and he wore that black hoodie he loves. He just went for a walk."

Project Manager: "Bad?"

Wife of the Rockstar developer: "Pretty bad. He's still unconscious."

Project Manager: "You have my deepest sympathy. I will inform the team now."

Monday daily standup

Project Manager: "We start with sad news. James had a terrible accident yesterday. He is in bad shape. We will do everything as the company to help him and his family in these tough times."

Developer #1: "What about the project? He knows everything about our queueing system. We were always afraid of that."

Developer #2: "It's not the best time to think about project. He is fighting for his life."

Developer #3: "We're not doctors—we can't help him. We're launching this week. Queueing system is such a big chunk of code."

Developer #1: "F*ck, we got hit by bus factor."

direct hit
Photo by Hermes Rivera / Unsplash

The bus factor evaluates the dangers of information and capabilities not being shared among the team.

It's a sad fictional story, but it should act as a precautionary tale. Things happen.

Countless scenarios could put a project at risk:

  • Bad management firing key worker. Developers are replaceable, right?
  • Developer who likes extreme sports
  • Family matters: divorce, child sickness, parents dying
  • Inheritance/large sum of money won
  • Mental breakdown. I saw many developers in startups go through a crisis
  • Terminal illness. You don't want to work on the project if you found you have cancer
  • Developer behavior: left for a better, fake illness, and unplanned vacation

My project is safe. I'm working in IT for ten years already, and it's just another bullshit theory. Everyone is loyal. These are excuses you will hear.

Protecting from the bus factor is hard work.

Should we be paranoid? Yes, to some extent.

It's similar to some companies saving on security and thinking chances of the attack are slim. The moment your startup shows up on TechCrunch—hacker city — attacking you for fun and profit.

Photo by Markus Winkler / Unsplash

How to find the bus factor?

Is there a formula that I can use to say if I'm in danger? There are analytical approaches. I will go through them because that's fair to see different points of view.

Let me stop you for a second.

Do you want to mitigate risks? I have one word for you. Awareness.

Mind junior programmer sigh, boring meeting, documentation task lying forever in backlog. There is no app for saving from bus, yet.

Lines of code approach

I am not a fan of this one, because it's such an outlier.

If you have experience as a developer, you know that producing software is complex — LOC is shit. You won't find teammates' commitment from one metric.

The team leader will rarely have high LOC, but he is essential. The lead will spend most of the time mentoring, pair programming, designing solutions. This approach will show that he is not critical.

Obscure knowledge identification

Gather developers from your project and ask them straightforwardly.
What are the most obscure places in our application?
What areas in code don't you like to touch?
Is there something that only one of us understands?

Try to make things friendly. It's hard to talk about failures or things that barely work. With time you will pick those areas and can start knowledge sharing, refactoring.

Love is the Answer
Photo by Hannes Richter / Unsplash


Relax, make it easyyyy

My preferred solution because it's an ongoing process. We're not waking up one day and think, "We wrote shitty code. Let's make it readable now" — refactoring is a different problem. Every pull request should be reviewed in terms of readability. Always strive for making your code readable — less technical debt, better happiness index of programmers, faster onboarding process. With better readability, you become more resilient. You won't be taken down fight when developers leave.

Imagine person working in the future on the code you wrote as American Psycho. Is your code good enough that they won't go ballistic on you?


It's one of the more easy answers to the problem, but probably the easiest to go wrong. Creating documentation is part of being a developer, but it's easy for docs to become outdated, or writing could be terrible. Covering the whole application with documentation sounds like Mission Impossible. Focus on the most crucial areas first, mitigate the risks as soon as possible.

Remember that code could also be self-documenting. Writing functional tests is also a viable solution — it's an art in itself.


Open-source? You must be kidding me. It's not about going open-source
for the business part of the application. If the company created a custom library
for handling images that is not a business advantage, consider going open source. Why? Other developers could love your solution, use it,  creating a backup plan
if something awful happens. Getting credibility on Github could also help in hiring talent.

Pair programming

Two people.
One computer.
One keyboard.

Sit together to work on the problems, and magic happens. There are still folks that think it's a terrible waste of time — it's just a tool. Pair programming sessions are exhausting, but they bring a lot in terms of reducing the bus factor.

Now is the time for developers to ask all the awkward questions that they were afraid to ask before. Next time your principal developer will sit to work on obscure place in application, propose that he/she do pair programming sessions to spread the knowledge. You will thank yourself in the future for that decision.

Record technical meetings for future reference

Listen to an extremely controversial idea. I've been in companies that believed in the concept of sharing ideas, no matter the costs. Audio recordings are an invasion of privacy that not many developers can agree. Still, we are living in the times when Transcription API exists, and creating a ton of documentation by just attending meetings could be a deciding factor. Sooner or later, someone will try it. Skimming through conferences, you couldn't participate in or coming back to them months or years to jolt your memory. It could kill creativity, and everybody would be especially careful not to say something bad — in the end, it's probably not worth it.

Thanks for reading.

Best regards,
PTSD Engineer

PTSD Engineer

Pour one glass of wannabe writer, pour one glass of programming passion, spice it up with some anxiety, and you get PTSD Engineer.