Richard Bergmair's Blog

==> Kraken Technologies writes about how they organise their very large Python monolith.

I’m a big fan of layered (or even linear) dependency structures, too. Here is a simple trick I use in my Lua codebases: The layout of my source code files usually looks like this:

01_foo/
  03_foo.lua
  04_bar.lua
  15_whatever.lua
02_bar/
  22_whatever.lua
  56_something.lua

It has always bothered me that codebases don’t have a beginning and an end and that, therefore, it’s difficult for a reader to know where to start when they just want to read the codebase.

So, my approach is to impose this linear order and only allow code that comes later to depend on code that comes earlier, never the other way around. This way, you can read through the code rather easily. As you look at any piece of code, it will only depend on code you’ve already looked at, so you don’t have to constantly jump through the codebase as you read.

I’ve also found that failure to correspond to a linearisable dependency structure is a “code smell” and that, as I try to eradicate that code smell, I frequently end up with code that’s better in all kinds of ways.

#computers   |   Jul-19 2023

==> There are three big logical fallacies that account for why maybe 80% (in my totally subjective estimation) of any given MBA curriculum, and 100% of any given management fad, is baseless and grounded in nothing.

The first is the fallacy of the cargo cult: “Apple is doing X, and it co-occurs with their success. Therefore, if we do X, we will also be successful.” Not true, because co-occurrence does not imply causation, and without a causal link between Apple doing X and Apple being successful, there is no reason to believe that, if we do X, we will also be successful.

The second is getting confused about conditional probabilities and ignoring confounding factors: “Many billionaires are college dropouts. Therefore, dropping out of college will increase your chances of success.” Not true, because college dropouts as a proportion of billionaires are not the same thing as billionaires as a proportion of college dropouts. And then there are confounding factors. For example: One good way of becoming a billionaire might be to be in tech in the 90s. This gives you two confounding factors, namely the “how” of how one might become a billionaire (tech) and the time period (the 90s). Suppose you now look at the people who were in college in the 90s and who already have a proven capability as programmers. In that case, you might be able to look at the proportion of billionaires among those who were in that situation and who dropped out versus those who didn’t. But, besides not getting confused about conditional probabilities, that takes creativity around coming up with possible confounding factors, and it takes a lot of work because of the experimental controls you’d have to put in place.

The third is the fallacy that poker players call “resulting” and its interaction with the PDCA (plan-do-check-act) method, a religious observance among MBAs. “We have process P, and while executing on P flawlessly, we had bad outcome X. Therefore, we need to change P to avoid X in the future”. Not true. Business deals with stochastic processes, just like poker does. In poker, it is perfectly common to have a flawless assessment of the strength of one’s hand, flawlessly execute the play which is provably optimal given that hand, and then lose the hand. Losing a hand does not trigger the need to change one’s strategy or the method whereby one assesses the relative strength of each hand. When your boss asks, “What went wrong here?” then by answering, “Shit happens.” you might very well be saying the most logical thing possible. But two psychological principles make it difficult to have that conversation. The first is selective attention. Your boss’s layer of the hierarchy will likely be exposed, with great salience, to the one thing that went wrong on your layer of the hierarchy while being comparatively blind to the 99 things that went well. So, their estimations of the relative probabilities of outcomes given process features might be wildly biased. The second principle is roughly this: Changing the process is what makes your boss’s job psychologically meaningful, so that’s what they’ll be motivated to do. So, the PDCA cycle doesn’t tell managers what to do (because of resulting). And it doesn’t even tell them where to deploy their attention (because of biasing their perceptions to negative outcomes). Then what exactly is it good for?

#business   |   Jul-03 2023