Becoming a Better Programmer

Chapter 18. Nothing Is Set in Stone

They always say time changes things, but you actually have to change them yourself.

Andy Warhol

There is a strange fiction prevalent in programming circles: once you’ve written some code then it is sacred. It should not be changed. Ever.

That goes double for anyone else’s code. Don’t you dare touch it.

Somewhere along the development line, perhaps at the first check-in, or perhaps just after a product release, the code gets embalmed. It changes league. It is promoted. No longer riffraff, it becomes digital royalty. The once-questionable design is suddenly considered beyond reproach and becomes unchangeable. The internal code structure is no longer to be messed with. All of the interfaces to the outside world are sacred and can never be revised.

Why do programmers think like this? Fear. Fear of getting it wrong. Fear of breaking things. Fear of extra work. Fear of the cost of change.

There is a very real anxiety that comes from changing code you don’t know fully. If you don’t understand the logic from the inside out, if you’re not entirely sure what you’re doing, if you don’t understand every possible consequence of a change, then you could break the program in strange ways or alter odd corner-case behaviour and introduce very subtle bugs into the product. You don’t want to do that, do you?

Software is supposed to be soft, not hard. Yet fear leads us to freeze our code solid in an attempt to avoid breaking it. This is software rigor mortis. ...