Why the lucky stiff

You'll have heard of _why?

I first heard of him in 2007 when I encountered Why's (poignant) Guide to Ruby, which I thought was highly original, funny and even helped me to learn Ruby! (It didn't hurt that Ruby itself is a charming language.)

I also tried his Hackety Hack - an environment for learning Ruby - with my son. But sadly we didn't get much past the first lesson because it kept crashing.

_why appears to be a highly creative guy and I found his work inspirational, if not a little sobering when I think of my own minuscule contribution to the world. He puts me in mind of this paragraph from Seth Godin's Linchpin:

The gift of art instantly creates a bond between the artist and the recipient. A priceless gift has been given, one that can never be valued monetarily or paid for or reciprocated. The benefit to the artist is the knowledge that you changed in some way, not that you will repay him. And so your only possible response is to make the tribe stronger.

I've only just realised that _why has apparently "disappeared," which puts me in mind of this paragraph from the same book:

Art is scarce; scarcity creates value. Gifts make tribes stronger. Organisations will always strive to replace replaceable elements with cheaper substitutes. But generous artists aren't easily replaceable.

I'll be checking out more of _why's work, including potion.

Update: ...and maybe I'll try to do something fun on Whyday. (One line in particular on that page catches my eye: "You can work to maintain some of the software Why left us (although Why is more about creating beautiful new things than polishing old things)." I find the idea of being more of a Starter than a Finisher simultaneously attractive and annoying, speaking as more of a Finisher than a Starter.)

index of blog posts

Why?

One of the questions I'm never asked is "why did you call your blog How to Write a Program?" The answer I would give is the slightly flippant "they say you teach what you need to learn."

Actually, I'm not sure I like the name any more. I think at the time I wanted something simple and straight-forward. It isn't meant to be ironic!

(EDIT: I should also have said that the idea came from the title of an article written by Ian Fleming: How to Write a Thriller.)

I've been programming since I was 16 years old. I enjoy writing code. I write code for nothing, like I did when I was 16, as well as writing code for a living. I hope to be writing code on the day I die.

index of blog posts

Reformat or leave it alone?

Say you are asked to make a little change to some code Abby used to work on. So you get the code out of the Version Control System and you start working on it.

Now this code has a fairly simple purpose, but it turns out to be really quite complex. For one thing, part of its functionality is implemented as a Windows device driver, which is something you've not worked on before.

For another thing, before Abby looked after it it was worked on by at least three other programmers and it looks like they all thought it was ugly, so it didn't matter if they made it a little bit more ugly. (Like Alan J. Perlis said, "In the long run every program becomes rococco - then rubble.")

So anyway, you start trying to figure out how to make the little change and it gets curiouser and curiouser, and some of the code is like "WHY did she do THAT?" and some of the comments are unhelpful, if not mocking. And the thing you thought would be bound to be little turns out to be spread through the code in Windows Resource files, ATL template parameters, hard coded string literals, on-the-fly generated names, ...

Anyway, it turns out to be harder than you thought. In fact you don't really understand the code. It works right now. But you have to change it in a way that was not anticipated when it was designed, so it's not easy, so you really need to understand the code before you change it. Plus, being a device driver, if you break it it has the potential to blue-screen thousands of your customer's computers.

Sadly, Abby doesn't work for the company any more, so you can't even talk to her about it. (Actually, if she did still work there it would be her responsibility to make the change, which would be even better.)

Here is a small dilemma I sometimes face at a time like this: the style of the code is bizarre and you can't tell what it's doing and the comments don't help; if you work through the code tidying it up - changing the indenting, brace-placement, removing the seemingly random blank lines, adding comments that make sense, removing comments that don't, simplifying unnecessarily complex code - you start to own the code, to understand the code. But if you do all this and you break the code, the diff against the previous version is just going to show massive changes. The material changes to the logic and functionality will be drowned in all the cosmetic changes. Finding what you broke will be hard.

Remember, this is a Windows device driver; it's not a small function that has 200 unit tests already written. (I'm sure there could be some kind of automated tests, but in the long history of this code no one has made any.)

My gut feel is to leave it alone this time. I'm only making a little change after all. The more I come back here, the more I'm going to "own" the code, and the more confident I'll feel about making big changes.

I read an interview with Bernie Cosell ("one of the fathers of the internet"), in Peter Seibel's great book Coders at Work, who habitually takes the more courageous path:

As I mentioned before, there were many bugs that I never had any clue where they were. I just get to a point where I say, "This piece of code is supposed to be doing this. This does not look like it's doing that. I mean, how could anybody have written this complicated bit of code to do this simple thing?" So I'd rip it out and replace it with a routine that does the simple thing I thought that piece of code was supposed to do. And the program magically works. In retrospect, what had happened is that the program had evolved and this little routine kept getting changed. Rather than being replaced when the program evolved, somebody was patching it to do different things and missed once.

I think this is all fine and dandy, so long as the guy that does the rewrite is still around to deal with the consequences, should there be any. I think I'd find it pretty irritating if someone rewrote my code, even though they didn't fully understand it, and broke it, and I had to work out what went wrong, and the diffs were massive.

Not that that happens to me, because I don't write complex code. And if anything looks a bit odd I write a comment explaining why it needs to be that way. So there.

index of blog posts