V1.1 – Revised: 08/12/2014
I just updated NotesOn: Project Management – IT Testing 101 … for the third time, as there were, continued to be, a number of un-clarities and out-right errors in both the text and several of the diagrams. To be generous we could call them “mental typos”.
For instance, on one diagram I initially spelled “Classes” as “Clasess” and missed seeing it three times.
I was thinking about this on the way home (in the vein of continuous improvement) fairly close on the heels of a discussion or two about some developers (not at work) who obviously hadn’t fully tested their product before pushing it out the door.
What I found interesting, once the light bulb went on, was that there were indeed parallels between their goofs, and mine.
You have to understand that, before moving into IT management, I spent years and years (a couple of decades actually) designing and developing programs and objects and so forth in a wide variety of languages, starting with COBOL, passing through DataFlex, PowerBuilder, C, Java, HTML … not to forget to mention designing and developing dozens and dozens of databases and crafting hundreds and hundreds of pages of SQL stored procedures, and triggers. So, I know whereof I speak.
What I finally recognized is that the root causes behind goofs in both program and system development and writing are pretty much the same, and go something like this:
- It isn’t wrong – otherwise it wouldn’t have been written that way. Sometimes, in the crush of the creative moment, or the under the sweat of a drop-dead date, the basic concept hits the page but some of the details don’t quite get translated from mental concept to ideal deliverable. It makes sense to us. Because as we read it back, to ourselves, we automatically fill in the nooks and crannies we, unwittingly left behind. I know that when I am “in the zone” and typing up a storm … at times my head gets ahead of my fingers. A review does catch some of those gaps, and gaffs, but also sometimes #2 and #3 come into play and we see what we meant to put down. (Of course, pride-of-authorship can also come into play but that’s a different issue and discussion point.)
- Being in a hurry – more often than not there are production demands that have to be met, whether self-assigned or otherwise. The pressure is on. To meet, or beat, targets. This fact of life is a catalyst that helps other causes come into play.
- Seeing what we expect to see – after looking at “it”, whatever “it” is, for long enough our focus has a tendency to come off of what is right in front of our noses and more on what is “inside our head”. This, of course, is not good. When your head filters what your eyes are seeing, thereby not recognizing what is, the “too obvious for words” errors are missed.
- Distractions – are a killer. Whether writing code, or technical documents, or short stories, or … distractions are more often than not small explosions that rip you right out of your entire train of thought. This is particularly annoying when you are juggling dozens of logic threads in your head for which you need to account, everyone one of them, while writing pseudo-code or actual code. Most of the time, one can pick up those threads. But if it becomes “pick them up again” and then “pick them up again” again …
When all four “issues” are in evidence, Code Reviews, as discussed in IT Testing 101, particularly shine bright. That is when they demonstrate their ROI, their return on the investment of time, most spectacularly. And, for the same reason, this is why good Editors are extremely valuable. They too provide a fresh set of eyes to view the work as it actually is, not as we are (pretty) sure it is.
This is my excuse for the third revision of … IT Testing 101 … and I’m sticking to it.
The next revision will be for clarification purposes based on incoming questions.
Hope this helps,