The ‘Code’
Late last year a local hockey player died due to injuries sustained during a hockey fight. This has been dominating the local sports conversation, typically in relation to whether the Code of hockey needs to change. The Code also exists elsewhere to some extent. Lacrosse for instance has a variation of it and I suspect other physical sports do as well to some degree.
For those who are not in traditional hockey markets the Code is the unwritten laws that dictate the level of physicality and conduct on the ice. For instance, if you mess with the team star, the next shift you are in trouble or if you are in a fight you take off your helmet to protect the opponents hands (apparently the head is softer than the helmet). There are lots of other examples that are internalized by players and staff in these environments.
I got thinking about the Code the other night while watching an episode of the Fifth Estate on it and came away thinking there feels like there is a variation of it in the testing world. So I tweeted the not-yet-close-to-half-baked thought. After a bit of back-and-forth, James came back with what does this have to do with testing?. This is my slightly-more-half-baked attempt at a answer to that. What I’m not going to do is weigh in the Code itself. I’m a lacrosse player, fan and coach and so am biased on it and could distract the point I’m trying to make.
- The issue is near religion. Swap fighting with ‘Agile’ or ‘IEEE 829’ and you will have people very passionate about either side of the argument. But both want the same outcome; high quality software.
- The Code is passed from generation to generation. Software testing has very little presence in post-secondary education and most information is passed down from senior tester to new tester.
- I’ve seen a lot of teams which have someone who is rather outspoken and has warped (if not downright broken) filters when talking about the quality of work being produced. (I tend to fall into that role.) Consider this person the Enforcer who is protecting the product from the assaults of the opponent (developers). I’ll admit that this is taking the healthy rivalry between bug finders and creators to an extreme but it works better in the metaphor that way.
- There are big, vocal names arguing for either side. In the hockey world it is Don Cherry for and Bob McCowan against. Again, pick your testing hot topic and you can likely identify the for and against personalities.
- But even the strongest attackers of the Code admit there is a time and a place for some aspects of what they are against.
- Understanding the Code is essential to not only succeed but thrive in the system
- The Code works; to some definition of works
- The Code is also destructive — someone died
- To understand the debate around it, you have to understand the conflicts of interest by the people involved. Look no further than the Great Certificate Debate in testing for this.
- Every clique in the testing world has someone (or even a full line of someones) who could be considered Enforcers. Unlike in hockey, it is my experience that the Enforcers of testing actually have skills.
- If you know the Code, you can predict with pretty good accuracy the outcome of certain situations in the game. I can spot when a discussion is about to get railroaded by a mini-version of the Great Certification Debate (or similar) by seeing who has come into the room at conferences.
- Any effort from higher powers (the league) to change the Code would fail and have repercussions we cannot even begin to guess at. If it was decreed that ‘everyone must be CMMi level 4 by next year or you cannot build software’ I’m sure there would be some sort of ramification
- The Code succeeds as it is implicit
I’m not sure if this clarifies this any or just solidifies the half-bakedness of the idea. I’ve only been chewing on this a couple days, but it seems that there is a correlation somewhere; not sure if I have quite found it yet though.
Oh, and the video is of the Fifth Estate episode is available online if anyone is interested.