Theory-building and why employee churn is lethal to software companies (2022)

Theory-building and why employee churn is lethal to software companies (2022)(baldurbjarnason.com)

36 points by RyeCombinator 1 year ago | 11 comments

larrik 1 year ago |

I recognize this is an extract from a larger book I haven't read, but my main reaction is: prove it.

All of this reads to me like a software developer complaining at the pub.

The wording is strong and the premise that "employee churn is lethal to software companies" is an extreme claim. Yet, not one company is used an example of one that died due to employee churn.

In short, I don't buy it. There's generally only a tenuous relationship between software quality and business success to begin with, and history has shown over and over that the importance of software quality is far more important at the beginning of a business (or product) than after it's established. So to claim that employee churn kills entire companies needs a lot to back that up, starting with numbers (which there are none in here)

f1shy 1 year ago | |

My 2 cts: churn has objectively a cost. At some point that cost can kill a business. Where exactly is that point, depends on many different factors. There is to my knowledge, in this regard, nothing special about software, that cannot be said about other development activities.

bunderbunder 1 year ago | | |

I would guess that, like technical debt, churn is something you can have both too much and too little of. Stagnation also has a cost. When I work with teams that have had the same members for a long time, it seems that they've always lost their edge. They get attached to their existing code, and resistant to making changes that might require major alterations to it. To the point of pushing back hard against new business goals.

I think that from the business folks' perspective, you might say they're no longer playing to win, they're just playing to not lose. Which, in many portions of the tech space, is a recipe for inexorable decline.

from-nibly 1 year ago | |

I think lethal is a bit exagerated. I think developers often underestimate the resilience of a company.

Howrver, if you read the related programming as theory building it explains these thoughts in greater detail.

It explains a lot about how code becomes legacy and the friction that comes in from inheriting a 0 handoff software project.

somestag 1 year ago | | |

I'm continually shocked at how well companies can continue on despite serious internal problems. I do think it usually catches up with them though, and there are a lot of "terminally ill" products out there that are going to die eventually. I've seen those projects first hand, and I've seen the slow decay of the product that happens when a company loses control of its tech stack. It can take years.

I think that cuts both ways though, because I think even the business people would be shocked at how well things can seem to work despite serious dysfunction. If an entire team dies off but 3 months later things seem "fine," the business types will just assume everything is as good as it ever was. I know it's popular these days to say that good tech and good business are not always the same thing, but I do think that many of those same businesses would be a little worried if you actually convinced them that their tech was coming off the rails and was only going to get worse. Some businesses just want to be acquired and don't care what happens after that, but not every business thinks they're on a clock.

If you're big enough, like say you're a trillion dollar megacorp, then important teams folding up and being reborn is just part of your ecosystem. I've seen big tech power through churn for years with nothing but human wave tactics until the business climate changed enough that the team in question became less critical, and that's when they let it die.

toomuchtodo 1 year ago |

https://news.ycombinator.com/item?id=34328069 - Jan 2023 (420 comments)

nzach 1 year ago |

> The death of a program happens when the programmer team possessing its theory is dissolved.

I really like this quote. And if we look at what is generally called "legacy software" it mostly fits pretty well with this description. And I agree with the idea that to have a proper living program you need people with experience in this specific domain, consequently if you have too much churn in your team your programs can die.

But I think this only one side of the story, and probably its the side we have least influence over.

Another component for this problem is how easy is to understand a program. Imagine your program is distributed and you need a consensus algorithm. In a broad sense both Paxos and Raft are good solutions for your problem. But by choosing Paxos you are making things harder for anyone who needs to join this team in the future.

And this is just due the fact that people generally have a hard time understanding how Paxos work. Sure, there are several techniques one could use to limit the impact of choosing Paxos can have over a program. Its not that hard to isolate networking behind an interface and treat Paxos as an "implementation detail". But the reality is that predicting what things should be completely isolated is pretty hard, especially if your prediction needs to happen 5 years in advance. And when you don't properly isolate these things they spread all over your codebase.

This is why I think the metric "how easy is to explain this code?" is pretty important. If we want to create successful programs (which one way to measure would be "programs that outlive their original teams") we need to be mindful about how we structure our code. "Literate programming" is probably a good way to think about this, in the end of the day we are writing code for other humans to read and understand. If that wasn't important we could all be working with minified source files.

moffers 1 year ago |

I like the idea, but I feel like in the context of an enterprise there can be other non-coder roles to help maintain a mental model for future “generations”. As a Technical Product Manager I don’t help with coding often, but usually will create onboarding documentation centered around the “theory” of the system’s programming to help cut down on churn if we bring in new resources.

cadamsau 1 year ago |

Missing from the complaint is “too much” churn. But then it’s boring and obvious. Too much employee churn is lethal to any company.

Not a huge insight.

But if we could somehow arrive at the answer to how much is too much, it’d be something that can be optimized for. And we’d live in a fascinatingly different world.

dmoy 1 year ago |

I think this is true, at least the underlying concept.

Yea the program in code does exist as a thing that will do exactly what it says in a deterministic (mostly? lol) fashion, since it's, you know, a computer.

But a team's ability to modify the code, to fix inevitable problems or add new features, depends on the mental model of the code that exists in their head(s). That's also why there's a massive increase in complexity of a project as soon as it gets too big to fit inside one person's head.

btown 1 year ago |

One of the things I find myself needing to push both junior _and_ senior developers to do is "if you are thinking about code being anywhere adjacent to 'subtle' or 'weird,' or think that something might become a design pattern for future code, or something that was copied from other code but differs subtly, or you consulted StackOverflow... write the comment that's in your head/leave a breadcrumb as an actual comment in the codebase." And, frankly, this sometimes means commenting-out rather than deleting code, if the historical code was necessary to understand the context for why the improvement is warranted.

I wholeheartedly agree with the OP that "churn" can result not only from staff members leaving, but also from them shifting focus to other projects or even just growing in skillsets over time. Which is why it's vital to document the mindset you had as you were coding.

One of my favorite books, Vernor Vinge's Hugo-winning _A Deepness in the Sky_, uses the term "programmer-archaeologist" - https://akkartik.name/post/deepness is a great (spoiler-free) quote on the notion. Writing for your future archaeologists - who may very well happen to be your future self! - is a great mental model to have.

(And read Deepness - despite its branding as book 2 in a series, it's arguably best to read it standalone first! It's simultaneously an action-packed popcorn novel and a mind-bending set of discussions on linguistics and cultural relativism as they pertain to mechanisms for societal control, in a way that makes the reader part of that very conversation. Highly, highly recommend.)