Blog: Fighting the Superstitions of Software Development: Questioning the Assumptions

Blog: Fighting the Superstitions of Software Development: Questioning the Assumptions

We fix the problems we know to look for. It's the assumptions left unexamined that are apt to bite you. Which superstitions are you carrying around that need to be re-examined?

One of the wisest, most brilliant programmers I ever met had a team lead habit I loved. If you made a technical assertion, Mike would ask, "Is that true?" Mike didn't ask the question to imply you were wrong; he asked, "Is that true?" to challenge your assumptions and to determine upon what data you drew your conclusions. If you said, "Yes, that's right. Here's why..." and made it clear your statement came from somewhere, he'd be satisfied, and you'd earn his respect.

If the programmer stuttered, "Um, I guess it's true," instead, more often than not the programmer headed back to his office to find out the real story. Or Mike would help the developer re-examine the assumptions being built into the software. If the assumptions made sense, fine. If not, it was an opportunity to write better code.

That wasn't just a technically interesting exercise. At the time I knew him, Mike and his team were building a compiler to generate the fastest executables possible. Nanoseconds counted. And with Mike at the helm, one particular math routine went from average performance to outstanding to... zero cycles. Because the "Is that right? Is that true?" question process eventually made the team realize that they didn't need the routine at all. Now that's code optimization.

At the other extreme, let's say you want to "uniqueify" an array in JavaScript (that is, find all the unique values in an array). You'll find a bunch of code samples with a quick online search. Most of them look very similar to one another, and they take a dumb, brute-force approach of walking the array multiple times. Bad performance, no biscuit. But hey, that's how everyone does it, right?

If you handed that code to an expert programmer like Mike, he'd ask, "Is that the best solution?" Well, no, maybe not. There's a way to do it that walks the array just once, if you take the time to think about it.

At the Schindler bitranch, we call these "superstitions:" information accepted on faith, without personal knowledge or examination. People pass along "everyone knows" data without questioning it, and others repeat the superstition as though it's undeniably true. Confidence isn't knowledge; in fact, confidence can prevent knowledge and innovation from happening, because an unquestioned belief means you never measure, never test, never look at alternatives.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.
Show Comments