Programming in tight corners
Wednesday, January 6, 2016 by Dave Winer

This week my development work has been entirely made up of what I call tight corners. Places where very small amounts of code and data are changing, but every change could easily bring the whole house of cards down, crashing all around you. You have to try to put it back together with pieces scattered all over creation.

But if it goes just right, at every step, when you're done, everything still works as it did before, and you got something new out of it. The new version of the software can do something important that the old version couldn't.

This happens often when you're trying not to break users. You want the new version to work for them, without forcing any kind of conversion. This time I did that especially carefully because I was the main user of the old version. If I broke it, my website would break. So avoiding breakage was mandatory.

This explains the primary rule at UserLand, it was called Rule 1. Don't break users. And Rule 1a, which was even more primal: Don't break Dave. We had to have this rule because I spent the first few years of UserLand being broken by devs. Finally I decided it wasn't acceptable. I wanted a different culture. And devs will always try to talk their way out of tight corners, if they can get away with it. 

PS: When I posted the first version of this post, the software failed dramatically. Heh. Serves me right for being too confident. Quickly fixed, knock wood. Even so there are lots of loose-ends to clean up, as there always are after working your way out of a tight corner.