coincidence

Don't be a Tweek Tweak Programmer

David Zych

• 3 min read

My previous post, Please learn to ask questions, asks developers to start asking more questions and try to understand the code behind many framework tools they use. A sibling of this topic is programming by coincidence. PbC (as it will henceforth be referenced as in this post)* is programming by luck, tweaks and accidental success until perceived correctness is achieved. The Pragmatic Programmer has 2 great examples:

Do you ever watch old black-and-white war movies? The weary soldier advances cautiously out of the brush. There’s a clearing ahead: are there any land mines, or is it safe to cross? There aren’t any indications that it’s a minefield—no signs, barbed wire, or craters. The soldier pokes the ground ahead of him with his bayonet and winces, expecting an explosion. There isn’t one. So he proceeds painstakingly through the field for a while, prodding and poking as he goes. Eventually, convinced that the field is safe, he straightens up and marches proudly forward, only to be blown to pieces.

And an example directly related to software development (emphasis mine):

Suppose Fred is given a programming assignment. Fred types in some code, tries it, and it seems to work. Fred types in some more code, tries it, and it still seems to work. After several weeks of coding this way, the program suddenly stops working, and after hours of trying to fix it, he still doesn’t know why. Fred may well spend a significant amount of time chasing this piece of code around without ever being able to fix it. No matter what he does, it just doesn’t ever seem to work right.

Fred doesn’t know why the code is failing because he didn’t know why it worked in the first place. It seemed to work, given the limited “testing” that Fred did, but that was just a coincidence. Buoyed by false confidence, Fred charged ahead into oblivion. Now, most intelligent people may know someone like Fred, but we know better. We don’t rely on coincidences—do we?

We don’t. Or, at least, we shouldn’t. The worst way to program is to program by tweaking values until something appears to work. I’m calling it **Tweek Tweak programming****:

var name = "DaveZych"
var firstName = name.Split(0, 4);
var lastName = name.Split(4, name.Length);

Nope, didn’t work.

var name = "DaveZych"
var firstName = name.Split(0, 4);
var lastName = name.Split(4, name.Length - 4);

Eh, still no.

var name = "DaveZych"
var firstName = name.Split(0, 4);
var lastName = name.Split(3, name.Length - 4);

Yeaaaahhhhh, it worked once. Nailed it.

How many times have you seen a developer fumble their way through code like this? Too many? Yeah, me too. Chances are the code happened to work for that one test run but will fail the other 95% of the time and especially when the test data changes. This is a direct path to a very unmaintainable codebase.

The Pragmatic Programmer has tips on how to not program by coincidence and instead program deliberately:

  • Always be aware of what you are doing

  • Know the requirements. Know the tools. Know the goal. Know when to take a step back and think about what you’re doing

  • Don’t code blindfolded

  • Don’t be a Tweek Tweak programmer. Make sure you understand your requirements and the technology you’re using

  • Proceed from a plan, whether that plan is in your head, on the back of a cocktail napkin, or on a wall-sized printout from a CASE tool

  • Before starting, think about what you’re doing. Write it down if it helps (it almost always does)

  • Rely only on reliable things

  • Make sure that code doesn’t work just because the circumstances were correct

  • Document your assumptions

  • If you assume that all dates coming back from an API are in EST, document that so anyone having to maintain the software knows why it’s expecting that. Just watch out how many comments you use

  • Don’t just test your code, but test your assumptions as well

  • Run a ton of queries against the above mentioned API and confirm the dates comes back as you expect all the time, every time

  • Prioritize your effort

  • Focus on the important parts because those are generally the hardest and will take the most time

  • Don’t be a slave to history

  • Just because something was done a certain way before does not mean you should also do that, nor does it mean it was correct in the first place

Keep these in mind as you make your way through the programming minefield. Don’t be a Tweek Tweak Programmer! And, as always, THINK!

* Apparently that was the last time it was referenced.
** Both because of the act of tweaking values as well as the paranoia the developer feels regarding the stability of the code afterwards