Reduce noise

delete-recycle-bin

I am a big fan of deleting things. Sometimes I go too far. In the past, I’ve deleted things that I’ve needed and not been able to recover them. But I still think it’s the right thing to do.

There’s an article by Ned Batchelder from over 10 years ago, that I still think is relevant today:

If you have a chunk of code you don’t need any more, there’s one big reason to delete it for real rather than leaving it in a disabled state: to reduce noise and uncertainty. Some of the worst enemies a developer has are noise or uncertainty in his code, because they prevent him from working with it effectively in the future.

  • A chunk of code in a disabled state just causes uncertainty. It puts questions in other developers’ minds:
  • Why did the code used to be this way?
  • Why is this new way better?
  • Are we going to switch back to the old way?
  • How will we decide?

You’ll always have a battle on your hands when you try to delete things. People don’t like doing it. It’s similar to trying to throw out physical things (something I also try to do). People just have a natural hoarding instinct. Maybe it dates back to our hunter-gatherer days. After we’ve spent days or months hunting wild bits of code and bringing them back to our cave, it can be difficult to bring ourselves to delete them.

It’s because we remember the effort we put into writing the code the first time. But deleting code is part of writing code. It’s the same with writing prose. As EB White said, “writing is rewriting”. And coding is very similar. In particular I think of William Shrunk’s advice in The Elements of Style:

Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

Coding is hard

Coding is easy

“Coding”, to misquote Douglas Adams, “is hard. Really hard. You just won’t believe how vastly, hugely, mindbogglingly hard it is. I mean, you may think it’s difficult to walk  down the road to the chemist’s, but that’s just peanuts to code, listen…”

Except it’s not. Not really. And that bit about the chemist’s makes no sense. Thanks for nothing, Simon.

Writing a little bit of code is easy. So easy, that I’ll do some now. Here:

<b>Make this bold</b>

See, that wasn’t so hard, was it? That’s one line of HTML. HTML is what’s called “markup”, code for styling text on a website. The angled brackets indicate that what is within them is a command. This command is sent to the “code interpreter”, which reads the code and turns it  into:

Make this bold

At the end, there is another set of angular brackets, with a forward slash to indicate that you can stop making it bold now, thank you very much. So to the compiler, it reads:

Start making the next bit bold until I tell you to stop

This is the specific text that I want you to print out, so just print it out

Stop making it bold now

That’s quite straightforward, but using essentially that principle (and a few others), you can start building most websites in the world. And end up with code that looks like this:

Html Code

A little bit of code is easy. A lot of code is hard.

The way computers “think” is just very different to humans. Densely written text like that is almost impossible for a human to read. But for computers, this isn’t a problem. They just start at the beginning, and work their way through. Very quickly. In milliseconds. It would take us humans with our monkey brains much, much longer to go through it all.

The upshot of this is that once you go beyond writing a couple of simple lines of code, managing the code becomes a bigger job that actually writing the damn stuff. And when you throw some other coders into the mix, with their own way of coding, and their own idea of how code should be indented (it’s tabs, for Christ’s sake, not spaces!), you start to see why coding is so hard, and why so many software projects fail.

In this blog, I’m going to take a walk through coding, development and software. Looking at what goes right (and wrong), why coding is the way it is, and talk about some of the concepts involved in coding and development. You won’t learn anything useful from this site (it’s not Coding for Dummies or anything like that). But you will learn lots of useless things. And, if I’m honest, I’ve always preferred useless information anyway.