Its a big ask for developers but that additionally is a sign of commitment.

I’ve had several experiences, the most memorable was discovering that the database server hadn’t been configured correctly and having to spend the lion’s share of time sorting their machine out.

That really should have been an indication to walk out, but you live and learn.

1) Allow enough time. You can’t do a reasonable pairing interview in an hour
2) Pair the candidate developer with more than one person. In particular, if the first pair sets up the problem and the pair write some tests, you can learn a lot from the way the candidate explains where they’d got to when he pairs with a second partner
3) Understand the difference petween a pairing interview and a coding audition. They’re not the same.

I agree with your point about software quality being cumulative. It reinforces my view that tech debt is an unhedged put option, because the downside is not unlimited. Consider a hypothetical clean codebase where we take on some tech debt; it is very unlikely that this single choice will cost us a complete rewrite in the future, hence it is a put option. Now, when we then take on a more tech debt, we change the market we are trading in, and this may cause the assets underlying the options to become correlated. This means that future market moves are more likely to cause both options to be exercised. The cumulative effect is to turn the whole codebase into an unhedged call option.

What is the software property that causes the correlation? I’ve been half-heartedly been trying to model this process, and the best I can come up with is that it is dependencies between components, but I can’t find a way to measure the effect (an abstract dependency is better than a concrete one, but it is still a dependency that can cause correlated changes when the interface has to change).

I don’t know if this has any practical significance, as few codebases are in the clean state necessary to make new tech debt an unhedged put option…but your article makes me want to think about it again!

“We were doing incremental development as early as 1957, in Los Angeles, under the direction of
Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP”, Gerry Weinberg

This touches on the delicate definition of what is logging? What is auditing? What is the activity described here?

Thanks for the post.

Sam