Nat here– with your latest issue of Simpler Machines.

Last week's post was actually a last-minute rescue of a much longer, weirder piece about how software engineers (and people in general?) have a tendency to evaluate the goodness of the work they do by the stock price of a company. This leads to bad, weird decisions, because there's so much other information embedded in stock prices.

I've touched on this idea before – that software practices just don't matter very much to business outcomes. This is basically why I think more companies don't "do XP" – it's technically, operationally, and emotionally hard, but it's not so much more effective that companies that do it outcompete ones that don't.

What I'm very much not saying, though, is that programming practices don't matter.

They matter a lot! I value pairing and test-driven development for themselves. I value good code and good software for itself.

It took me a long time to figure that out. For a while I thought that I valued those things because they led to good outcomes. I think they do make good outcomes more likely– but the relationship between technique and craft and outcomes is– complex.

More importantly– "business outcomes" aren't why I write tests.

More on this soon, I think– but right now I have to get on the road to Petaluma.

Making things well is inherently valuable