everything flows – a celestial emporium of benevolent knowledge

Paying down technical debt won’t necessarily increase your velocity

(This piece is a work in progress, a placeholder for developing thoughts on technical debt and measuring the performance of software development teams. I will update it as my opinions change.)

An oft-cited benefit of paying down technical debt is that it will allow you to move faster. This is typically characterized in terms of increased velocity.

But if you are measuring velocity by factoring in “accidental complexity”, then when you remove the source of that accidental complexity, your velocity will not actually appear to improve. This point is well put by Moneyball for software teams: an imperfect heuristic for quantifying dev performance. This runs contrary to what we’d generally expect from a measure of developer velocity, and also contrary to the business case that is usually made for paying down technical debt: to simplify, reduced debt = increased velocity.

The aforementioned article presents a reasonable way out of the impasse of a) needing to factor tech debt into your estimates, b) wanting tech debt reductions to be visible as increased velocity i.e. more “story points” per cycle. (Whether it is necessary or desirable to adopt this approach is debatable, and personally I’d still bias towards avoiding measurement of velocity at all, and having developers do PERT estimates only as necessary. This seems to be less common outside small, high trust teams.)

But even if you are measuring velocity this way, it is entirely possible that you could pay down all the tech debt and still not have your velocity (as a measurement of essential complexity) increase:

new sources of accidental complexity can emerge that are not at all under your control, whether from vendors, dependencies that are suddenly EOLd or have hard to patch security flaws, and so on
eliminating a given set of sources of accidental complexity may enable your team to take on other types of projects that are subject to additional kinds of accidental complexity. These new tasks or projects may have higher business value, but that won’t be reflected on your velocity (or probably reflected anywhere because We can’t measure developer productivity). This is reminiscent of the way in which improving tail latency can actually cause median latency to increase: previously, requests from slow clients would time out or never be initiated in the first place, but after improving performance for those clients, their requests will now succeed, albeit at latencies greater than your current median.
even if your velocity does go up, will the signal be strong enough to be distinguishable from statistical noise (maybe one of your senior developers finally got their kid into an after school program and now they are back to “full performance” level)? do you have tools sophisticated enough to discern this?

Returning to the moneyball comparison from above: sport performance is generally easily and unambiguously measurable (did the ball go in the net?), and what it means to do well can be reduced to “win competitions”. Software development is inherently harder to measure, and has many axes along which something can be called “a success”. Moreover, whether a software project turns out to have been successful may not be discernible for months or years down the road, for reasons business or market reasons that have nothing to do with the development project “in itself”. For these reasons, it is at best a waste of time, if not actively harmful, to foist such methods into software management.

That said, my thoughts on this topic are always challenged by the ideas of Hubbard (e.g. How to Measure Anything) whose main argument boils down to, if it matters you can notice it, and if you can notice it, you can (at least sort of) measure it.

Is “success mostly results from luck and connections” a luxury belief?

I have been pondering this essay from Rob Henderson for a while, and will continue to do so: Luxury Beliefs are Status Symbols.

Much of it is well-argued and compelling. I need to consider it further before I can say how much I agree or disagree.

But one part is so poorly argued it merits mentioning. Henderson writes:

There are other examples of luxury beliefs as well, such as the downplaying of individual agency in shaping life outcomes.

A 2019 study led by Joseph Daniels at Marquette University was published in the journal of Applied Economics Letters.

They found that individuals with higher income or a higher social status were the most likely to say that success results from luck and connections rather than hard work, while low-income individuals were more likely to say success comes from hard work and individual effort.

Well, which belief is more likely to be true?

Plenty of research indicates that compared with an external locus of control, an internal locus of control is associated with better academic, economic, health, and relationship outcomes. Believing you are responsible for your life’s direction rather than external forces appears to be beneficial.

Here’s the late Stanford psychology professor Albert Bandura. His vast body of research showed that belief in personal agency, or what he described as “self-efficacy,” has powerful positive effects on life outcomes.

Undermining self-efficacy will have little effect on the rich and educated, but will have pronounced effects for the less fortunate.

According to Henderson this is evidence that this belief is a “luxury belief”. I have a few problems with this section

1. The framing

Henderson asks “which belief is more likely to be true?” and then goes on to discuss the benefits of believing one vs the other, which patently has nothing to do with a belief being true. Was this just bad editing? This is such a non sequitur, I don’t know what to make of it.

There is plenty of research (though what I was able to find in a brief internet search generally seemed low quality) on whether hard work vs luck vs other factors are contributors to success. Henderson does not consider any of that here.

Additionally, there is a large body of research, as Henderson states, on the benefits of internal locus of control (e.g. The happy personality) and it does support the idea that internal locus of control is correlated with happiness and achievement. But it seems like a bit of a jump to go from “people emphasize the important of luck and connections in having success” to “people have weak/less internal locus of control and therefore are more likely to be unhappy and achieve less”, which is the conclusion that Henderson implies. The data used in the paper under discussion come from the World Values Survey, specifically the questions here are:

An answer of “in the long run, hard work usually brings a better life’ carries a value of one (1) in the survey and an answer of ‘hard work doesn’t generally bring success – it’s
more a matter of luck and connections’ carries a value
of ten (10).

To me this seems more about achieving societal markers of success (income, savings, housing, cars), while internal vs external locus of control is more about an individual believing they are responsible for and in control of what they do.

I am obviously not an expert on these terms, nor deeply familiar with the relevant theory and research, so I may be wrong here, but it seems like a big analytical leap that Henderson is making here. The relevance of this research to Henderson’s claim needs to be argued but he assumes it is obvious and uncontroversial.

2. The research

Reading the original research paper, we see the following correlations between belief in luck/connections (there are some others as well, but these are the ones that stand out as most problematic for Henderson’s case, in my opinion):

with social class: 0.0834
with gender: 0.0678
with country’s GDP: 0.0844
with income: 0.0077

Henderson seems to latch onto the correlation with social class, but this leaves us with a few head scratchers, given his conclusions:

if this is a luxury belief, why is the correlation with income so much weaker than the correlation with social class?
why is there a correlation with GDP? are entire populations of wealthier countries more likely to adopt this view in order to distinguish themselves from other countries?
what’s with women? why are they so more drawn to this luxury belief than men?

It seems like Henderson had an idea, went around looking for evidence, found something resembling evidence if you squint right and ignore some things, and then just ran with it.

I understand that the piece of writing I’m discussing is not academic per se, but given that he frames it as a transcript of a talk he delivered at a “behavioural science festival” I found the lack of rigor in this part disappointing. It casts a shadow over the rest of the argument.

Installing a Boss 560BRGB stereo in a 2012 Mazda 5

I purchased this Boss 560BRBG aftermarket stereo from Crutchfield for my 2012 Mazda 5. Installation and setup was pretty smooth, facilitated by Crutchfield’s support documentation which really surpassed my expectations. If you’re looking to tackle a project like this I recommend buying from them vs Amazon. But a few things were still tricky or non-obvious, so I’m going to share some of them here in case others struggle with some of the things I did.

To be honest, if I had noticed the handy wiring guide Crutchfield mentioned in my purchase email, I probably wouldn’t have had several of these difficulties, but I somehow missed it until just now.

First of all, you are going to have to solder some wires

If you’ve ever done a project like this, that fact is probably obvious, but I naively assumed that the Crux SWRMZ-64C Wiring Interface that came with my package would mean the whole thing was just plug n play. I got all the dashboard panels popped off and the old radio removed before I realized this, then ran out of time and had to put everything back together and wait until the next weekend when I had time to tackle the soldering.

Fortunately I had recently acquired a soldering gun and been getting some practice. You could maybe use crimp connectors or some other method instead of soldering, but the soldering was not that difficult, provides a better connection, and is more fun.

Removing the panels to get at the guts

This part was actually kind of interesting, turns out most of the panels on your car just pop off with the help of some trim panel tools and a philips head screwdriver. Again, something that is probably obvious to many folks.

One bit of advice I got from somewhere on the internet for this step was: after you’ve unscrewed the gear shift nob and popped off the gear shift trim panel, you can press down a little white lever with your finger or screwdriver to shift the car into neutral, which makes it easier to remove the climate control assembly. You could probably just do this at the outset. Obviously make sure your parking break is on.

Soldering the stereo wires to the wiring interface

Basically you can just follow the wiring guide from Crutchfield here, and match similarly-colored wires to each other. However

The manufacturer’s manual that comes with the wiring interface incorrectly identifies one of the wires as blue, when it is actually (in my case) brown. This is the Steering Wheel Control (SWC) Phone wire, which won’t be used for anything if you have the same year/model Mazda and this stereo. I soldered it to the brown wire on the stereo which turned out to be unnecessary, but not actively harmful.
The blue wire of the power antennae is similarly useless for this car, as the antennae doesn’t require power. You can just plug the antennae jack into the back of the radio, and top the blue wire off with electrical tape. Easy.
Because Steering Wheel Controls are simply incompatible with this stereo, flipping the dip switches on the interface module is unnecessary. Additionally, connecting the two wires that come out the other side of this module is also unnecessary, you can just toss those away, or keep them in your electronic junk box forever until you die because you will never use them for anything so just throw them away.
There will be an extra module just hanging out that connected to your old stereo, but has nowhere to go with the new one. I’m not sure what this is for, possibly SWC, but either way you can just ignore it and leave it hanging around. This little white guy here, no home for you any more buddy.

Mounting the stereo

I mostly ignored the mounting instructions that came with the stereo itself as they were confusing and seemingly incompatible with the Metra 99-7521B Dash Kit that was part of the package, and necessary to ensure you don’t have a gaping hole remaining in your dashboard.

I don’t have any good advice for this part, other than “just do what seems like it will work, ensuring that the unit is securely attached, without putting undue stress on the wires”.

Hearing this thing actually play a CD was probably the most satisfying feeling of accomplishment I’ve had in years.

Hemmingway readability scores

Buffalo can buffalo Buffalo buffalo, but don’t do it too much. – grade 5
Buffalo can buffalo Buffalo buffalo. – grade 10 (obviously much harder to parse)

A corpuscle is an outmoded idea from the early modern period. Modern science eschews such terms in favor of atomism. – grade 6

Did a mote perchance alight upon your nape ere your sojourn? – grade 5

Schadenfreude beckons: would that I were able to resist it. But its force, an animal magnetism of sorts, calls me. I must yield. – Grade 3

Ruby and Fortran libraries

I’ve been trying to learn Fortran for reasons of: future job security; masochism; curiousity.

Since having a REPL for a language makes learning it so much easier, I wrote one in ruby, called frepl. It is pretty buggy, and needs serious refactoring, but mostly works. After having written it, I was informed that there are other such efforts, e.g. in Python, but after cursory examination, they seem a bit less REPL-y than frepl.

I also have been interested in calling Fortran from Ruby, with the ultimate goal of perhaps being able to benefit from Fortran’s superior array-handling abilities for doing machine learning work in ruby. Turns out this is somewhat possible with ruby-ffi. I say “somewhat” because it is not very ergonomic to call Fortran from Ruby, as far as I can tell, and of the solutions I’ve come up with, some seem unstable (as in, occasionally produce segfaults), especially when trying to interact with Fortran derived types.

The ruby-fortran FFI proof-of-concept is here, along with some benchmarks. As I suspected/hoped, Fortran is much faster than ruby at some array manipulation tasks, e.g. summing an array is ~10x faster, doing dot product is ~2x faster. I mean, when using Fortran without the FFI/Ruby overhead, I suspect the speed differences are even more pronounced–these numbers are specifically with regard to pure ruby vs. ruby-calling-fortran.

Configuring SoftEther VPN on Ubuntu with a firewall

DigitalOcean has a good article on setting SoftEther VPN on one of their droplets.

The instructions worked for me without just fine, with a couple exceptions:

1. When you attempt to use the command line vpncmd tool to set up the server, you may have to specify localhost:5555 rather than using the defaults.

2. You may have to create a group for the test user before creating them and assigning them to a test group. This can be done with the command `GroupCreate test`.

3. If you are using a firewall, you will need to open up the ports used by SoftEther. To figure out what ports it’s using, do `sudo netstat -atulpn | grep vpnserver`. By default, SoftEther will listen on TCP ports 443, 992, and 5555. If you’re using L2TP/IPsec, make sure UDP ports 500 and 4500 are open as well. If you’re using ufw for your firewall, you can see which ports are open/blocked with `sudo ufw status verbose`. To get an idea of which ports each VPN protocol you’re using requires, check out the SoftEther specifications.

Throttle outbound Spotify traffic

When working on a shared network with limited bandwidth, it’s sometimes nice to be able to keep listening to Spotify without ruining your co-workers’ Internet connections.

Spotify is P2P (the desktop app is, anyway), so you both receive data from other Spotify users and transmit it to them. Blocking the outgoing traffic entirely would be un-neighbourly (probably also a violation of TOS), and might even prevent streaming from working altogether.

Fortunately, as I just discovered, ipfw allows you to add a pipe to a range of ports, all of which you can then throttle to a certain data transfer rate. It’s a shotgun approach, and will slow down any other services that are trying to send data over those ports as well, but since Spotify seems to stick to the range 10000 to 80000, and I rarely if ever run anything of consequence on those ports, this approach works for me.

sudo ipfw add pipe 1 ip from any to any out dst-port 10000-80000
sudo ipfw pipe 1 config bw 8KBytes/s