{"id":964,"date":"2015-12-13T09:02:40","date_gmt":"2015-12-13T17:02:40","guid":{"rendered":"http:\/\/angryweasel.com\/blog\/?p=964"},"modified":"2015-12-13T09:03:38","modified_gmt":"2015-12-13T17:03:38","slug":"roles-and-fluidity","status":"publish","type":"post","link":"https:\/\/angryweasel.com\/blog\/roles-and-fluidity\/","title":{"rendered":"Roles and Fluidity"},"content":{"rendered":"<p>I had a twitter conversation this week about roles this week. I\u2019ll recap it \u2013 and expand on my views; but first I\u2019ll tell a story.<\/p>\n<p>Very early on in the Windows 98 project, I was performing some exploratory testing on the explorer shell and found an interesting (and slightly weird bug). At the end of my session, I entered the bug (and several others) into our bug tracking system \u2013 but the one issue continued to intrigue me. So, I took some time to look at the bug again and reflect on what could cause this bug to happen. I dug into the source code in the area where the bug occurred, but there was nothing obvious. I couldn\u2019t shake my curiosity, so I looked at the check-in history and read through the code again; this time focusing on code checked in within the last few weeks. My assumption was that this was a newly introduced bug, and that seemed like a reasonable way to narrow my focus.<\/p>\n<p>Less than an hour later, I discovered that a particular windows API was called several times throughout the code base, but on one occasion, was called <em>with the parameters reversed<\/em>. At this point, I could have hooked up a debugger (or&nbsp; some could say that I should have <em>already<\/em> hooked up a debugger), but after visual examination of the code, the code of the API, and the documentation, I was positive I found cause of the error. I added the information to the bug report and started to pack my things to go home.<\/p>\n<p>But I didn\u2019t. I couldn\u2019t.<\/p>\n<p>I was bothered by how easy it was to make this particular error and wondered if others had made the same error too. I sat down and wrote a small script which would attempt to discover this error in source code. Another hour or so later, and I had a not-perfect, but pretty-good analyzer for this particular error. I ran it across the code base, and found 19 more errors. I spot checked each one manually, and after verifying they were all errors, added each of them to the bug tracking system.<\/p>\n<p>Finally I was about to go home. But as I was leaving, one of the developers on the team stopped by to ask how I found the bugs I just entered. I told him the story above, and he suggested I add the tool to the check-in suite (along with several other static analysis tools) so that developers could&nbsp; catch this error before checking in. I sat back down, we reviewed the code, made a few tweaks, and I added the tool to the check-in system.<\/p>\n<p>Over the course of several hours, my role changed from testing and investigation of the product, to analysis and debugger, to tool developer, and finally to early detection&nbsp; \/ prevention. The changes were fluid. <\/p>\n<p>On twitter, a conversation started on detection vs. prevention. Some testers have a stance that those two activities are distinct, and that doing both makes you average (at best) at both. The conversation (although plagued by circular discussion, metaphors and 140 character limits) centered around the point that you can\u2019t do multiple roles simultaneously. While I agree completely that you cannot do multiple roles simultaneously, I believe (and have proven over 20+ years) that it is certainly possible to move fluidly through different roles. Furthermore, I can say anecdotally that people who can move fluidly through different roles tend to have the most impact on their teams.<\/p>\n<p>To this day, I figure out what needs to be done, and I take on the role necessary to solve my team\u2019s most important problems. Even though I have self-identified as a tester for most of my career, I don\u2019t see a hard line between testing and developing (or detecting and preventing). In fact, that may be one of the roots of conversations like this. For years, I\u2019ve considered the line between development and testing to be a very thin grey line. This reflects in my story above, and in many of my writings. <\/p>\n<p>Today, however, I don\u2019t see a line at all. Or \u2013 if it\u2019s there, it\u2019s nearly invisible. It\u2019s been a freeing experience for me to consider software <em>creation<\/em> as an activity where I can make a significant contribution while contributing in whatever areas make sense \u2013 at any given moment. <\/p>\n<p>Sure \u2013 there are places where develop and then test still exist, and this sort of role fluidity is difficult there (but not impossible). But for those of us shipping frequently and making high quality software for thousands (or millions) of customers, I think locking into roles is a bottleneck.<\/p>\n<p>The key to building a great product is building a great team first. To me, great teams aren\u2019t bound by roles, but they\u2019re driven by moving forward. Roles can help define how people contribute to the team, but people can \u2013 and should flow between roles as needed. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>I had a twitter conversation this week about roles this week. I\u2019ll recap it \u2013 and expand on my views; but first I\u2019ll tell a story. Very early on in the Windows 98 project, I was performing some exploratory testing on the explorer shell and found an interesting (and slightly weird bug). At the end&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-964","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/964","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=964"}],"version-history":[{"count":0,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/964\/revisions"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=964"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=964"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=964"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}