Time spent on "incidental complexity" (new features, key fixes, performance) versus time spent on "accidental complexity" (anything and everything else).
Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.
CTEs are extremely useful mechanisms for writing modular and easily maintainable queries, particularly around anything to do with ETL, graphs, and timeseries data. Highly recommend.
TL;DR: Keep your branches up to date. Feature flags are a huge red flag. Constant conflicts and the inability to have long lived branches is indicative of poor architecture and project layout.
Use "rerere" as a bandaid.
Why won't anyone think about the release managers.
I don't like this take. This post is for any engineering leader.
The Bus Factor is how hard your team would suffer if you - or anyone else on the team - got hit by a bus.
Ideal Bus Factor for all team members is 0. This might sound counter-intuitive at first, almost like "make everybody expendable", but it's quite the opposite and kind of the point.
Teams should be good enough that they are a) autonomous and b) there are no mysteries. In the ideal state, everyone understands how everything works. New employees should hit the ground running and be able to produce value immediately. Departing employees should feel comfort in knowing that there are no unknowns.
An ideal team with 0 BF across the board is desirable. It means that team members are fungible. It means that every single team member can fill in the gaps if someone is ill, or on vacation, or actually leaves or is removed.
More importantly, a 0 BF is a reflection of simplicity. The software, its build/test/deployment pipelines, documentation, and support, should all be cohesive and coherent. Siloing information in team members is bad, everyone should be able to build and deploy.
0 BF is a healthy metric, but it is absolutely 100% not measured in email rate, commit rate, PR rate, lines of code, timeliness, GitHub heatmaps, etc. Those metrics indicate nothing at all. Quite the oppositve. They are harmful, awful metrics.
Measuring people by these metrics is just monkeys on typewriters. More startups need to hear this.
> The Bus Factor is how hard your team would suffer if you - or anyone else on the team - got hit by a bus.
> Ideal Bus Factor for all team members is 0. This might sound counter-intuitive at first, almost like "make everybody expendable", but it's quite the opposite and kind of the point.
I've always heard bus factor described in the inverse fashion, as in "how many people would need to get hit by a bus for the project not to be able to continue", with the optimal number being the same as the number of people on the team. It sounds like the idea is the same, but I'm surprised to find out that the number people to convey the concept isn't always the same.
A number between 0 and 1 can easily scale to whatever company you have. A number that is different depending on how many is on your team is harder to compare between teams. I guess it depends on if you ask a programmer, administrator or mathematician what a logical system would be :-)
For sure! The simplicity of having the same ideal bus factor for all sizes definitely appeals to me, but maybe due to familiarity, I think I prefer the well-defined units from the version I cited. It's a bit of a https://xkcd.com/883/ situation in terms of how bad your imagination is for what "maximum suffering" would be.
> Teams should be good enough that they are a) autonomous and b) there are no mysteries. In the ideal state, everyone understands how everything works. New employees should hit the ground running and be able to produce value immediately. Departing employees should feel comfort in knowing that there are no unknowns.
I've worked on projects where we had engineers who were one of a countable handful of people in the world with their particular skillset.
The bus factor was most certainly 1 at that point.
> More importantly, a 0 BF is a reflection of simplicity. The software, its build/test/deployment pipelines, documentation, and support, should all be cohesive and coherent.
For projects which push the frontiers of what is possible, simplicity isn't an option. (Granted these are a small % of overall software projects that exist!) When something has never been done before, you aren't worried about keeping the code As Simple As Possible, you are worried about how the hell you can even do this particular thing.
I'm not saying the code should be low quality! However sometimes doing hard stuff involves complex code, and maybe a couple generations later people have figured out design patterns so the hard stuff can have less complex code, but that may be a decade down the line!
> grug understand all programmer platonists at some level wish music of spheres perfection in code. but danger is here, world is ugly and gronky many times and so also must code be
If you only build things that are so simple that anyone can understand the code on day one and you don't need any domain knowledge, then what is your value proposition?
If the most complex thing you can build is a todo-app, then I think you don't produce much value to society.
Being able to write code that is able to be understood by someone new to the project is a skill set. It is certainly one that is not universal. And it is certainly one that should be admired. Solving hard problems in the simplest way, with clear information about why/how it works is one of the most important skills of a developer, imo.
Not day one, but anyone should be able to follow the code using a debugger and understand it. If you write spaghetti code segments, it's high time to change them.
If you ask society what has helped them the most, you will be surprised to learn how many claims the todo-list (paper or app in whatever time frame) is their main way of actually getting anything done.
Um, I would argue that what has helped society the most is agriculture, sewage systems, healthcare, electricity and heating, etc. All of which are technological innovations.
Also, how many variations of a to-do app does the world need?
Agreed. People who are good at their jobs and confident in what they do actively try to make their Bus Factor as low as possible. If you have a high Bus Factor that means your employer keeps you because of what you have done in the past, not your potential to do great stuff in the future.
"You see, killbots have a preset kill limit. Knowing their weakness, I sent wave after wave of my own men at them until they reached their limit and shut down." - Captain Zap Brannigan
The military operates that way with 99% of their personnel, who are grunts, expected to only ever follow orders, to never think for themselves. They're expendable cannon fodder - think of them as pieces of hardware in a software company. But with the 1% at the very top (basically just generals), I'd say the bus factor comes into play, same as in any other organisation - certain individuals have all the knowledge of certain domains, and if enough of those individuals are taken out, the wheels grind to a halt. That's why targeted assassinations happen to the top brass.
Sure, if you manage to assassinate the entire command chain, things will go pear shaped.
I dare say you could likely assassinate half the command chain, and the military will still managed to get where they need to be, when they need to be there. Military command chains have levels of redundancy that civilian organisations wouldn't dream of.
As a concrete example, it's estimated that the British lost ~40% of their officers in the Battle of Albuera, and they still managed to repel Napolean's forces.
Came here to post this. I remember once when going back on ADHD meds, a very smart doctor adding 5mg of Dexedrine. At 5pm.
I asked him why he would prescribe a stimulant so late in the day. His reply was simply "it's so you can think of one thing instead of all the things".
There are two things that everybody misses about OAuth and they fly under the radar.
Nice to hear someone touch on one of them: you absolutely NEED to use a transaction as a distributed locking mechanism when you use a token.
This goes double/quadruple for refresh tokens. Use the same token more than once, and that user is now signed out.
It doesn't matter if your system runs on one machine or N machines; if you have more than one request with a refresh token attached in flight at once - happens all the time - you are signing out users, often via 500.
Refresh tokens are one-time use.
The other thing devs and auth frameworks miss is the "state" parameter.
Too complicated, not suitable for everyday authentication in my opinion.
Seriously, the way auth in general is developing right now, I think we approach a point of insecurity through obscurity.
And with applications states, you need to adapt the application logic to authentication and the application then would have to check if someone maybe stole your refresh token.
Most systems implement a grace period for refresh token reuse for similar reasons. Transactions don’t really solve it. (Ex: You open two tabs quickly, hitting the server with the original refresh token twice)
Sorry, but that doesn't work in real world applications. Multiple requests are fired simultaneously all the time. E. g. browsers starting with multiple tabs, smartphone apps starting and firing multiple requests etc.
Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.
See: Out of the Tar Pit.