Funny Thing Happened on the Way to the Blog.

So I started this thing about a week ago.  I wanted to get a few entries under my belt before I let anyone know about it.

Today at lunch I put up my 4^th and 5^th entries and thought that was a reasonable time to make it a little more public.

So I posted a note on my Linked-In suggesting to people there that they could check it out.  It seemed pretty innocuous since so few people actually read the feed on L-In.

Apparently, however, at some point something I did or didn’t do, unbeknownst to myself, (or potentially unremembered) my Linked-In account got attached to my personal twitter account.   

So it picked up my post and put it to my twitter feed.  It decided, however, that my post was too long and trimmed a bit of it.  Now it is true that my personal twitter account is attached to my facebook feed such that anything I tweet goes straight to my facebook.  So the post was picked up and transferred there.   Any guesses what was trimmed off?  Right, the tail end of my URL for the new blog that I was inviting people to check out.  Within 3 minutes I had three comments to that FB post.  All three commenting about the validity of the URL.  One making comment about the quality of the QA associated with this quality blog.

Now, I posted the blog entry on my lunch at work and sent out the note to linked-in from my phone at the same time.  I couldn’t see things happening on FB because it’s locked down here and I don’t go to see what’s up there.

It’s really a lesson about never making assumptions about the end product of your work product because you aren’t really in control of all interactions.  But from the QA standpoint it also highlights the lesson that you have to be careful, you can’t guarantee what might happen to things.   You can’t always know all the factors and the higher the level of complexity the larger the possibility of problems.   You can’t plan for every contingency, but you have to have a system fault tolerant enough to handle it.  In this case, my FB readers will likely forgive my bad URL and go to the new one that I’ve put up in a comment under the first one.

As a humour aside, I went and removed the connection from Twitter to my Linked-In for that account and will add it for the QAisdoes twitter feed (@qaisdoes).  At the same time I grabbed the post and having deleted the original twitter post, I cut and pasted the same post into a new tweet.  The entire text of the post fits with 2 characters to spare!  Which means that if twitter hadn’t had weird rules about trimming entries from Linked-In, there would have been no problem at all.

Ah well, live and learn. 

Earlier this year I wrote the following article for a newsletter at Annex Consulting.
(the original published version is here: http://www.annexgroup.com/2012/03/thinking-about-usability/)

Thinking About Usability

By Mike Hrycyk
I’ve been in the IT industry for some 14 years now.  My experience has spanned quite a few different roles, from QA to BA to assorted manager/lead types.  Throughout my time I’ve noticed that there’s one term that everyone likes to talk about but few people can define in any consistently meaningful way.  Usability.  What’s the big deal you might ask, it’s not like we don’t all have an idea about what usability is.  When you’re put on the spot, it can be pretty easy to break it down into some simple terms.   Just looking at the word gives you the out of saying that it means things are easy to use.   But have you ever seen tacked onto the end of a set of requirements for a developer to make it usable?  I’ve seen that more than once.   How useful are those words to a developer?  What does it really mean?  Who could say?

There are people out there who purport to study usability.  Some of them even claim to be usability experts.  I’ve worked with a few of those so-called usability experts.  As far as I can tell, if their success rate is significantly beyond that of anyone else that seems to have a knack for usability, then I am not the type of person who can really detect the difference.  There are methods that can be set up to measure it, such as needs analysis, efficiency measurements and focus groups but in the end it’s an entirely subjective term that you can try to nail down.  I am however, significantly dubious that there is really anything even remotely scientific about the knowledge to be attained.   You’d almost think that this would depress me in some way, coming out of QA and BA where we like to have everything quantified or qualified in some manner, but I’ve come to a conclusion.  It’s not important so much that you’re good at measuring usability.  It’s sufficient that you consider usability on an ongoing basis and that it’s one of your core goals.  Thinking about usability, considering it important enough to stop your development plan to fix things when they aren’t usable, that’s the simple path to success.

In the past few years I’ve picked up a lot of responsibility towards recruitment and interviewing people to join our organization.  To the extent that I’ve put together some question lists that I use for different roles that I’ve been looking after.   I rarely actually record the answers to these questions, just jot down notes about the responses that I’ve been given if they are interesting in any way.  Unless the question is particularly technical I generally am not targeting a particular response but rather want to see how they think about things and how they put together an answer for me.  Gauging how people think and approach thought problems is really important to my assessment of them.   I came up with one question for my QA hires that I quickly extended to my other interviews because I found that it gave me some critical and useful insight into the applicant.

The question is a two-parter, that in and of itself is difficult enough to give the applicant some difficulty just trying to get past the standard interview hurdle of figuring out the right path between the answer you’d like to give, the answer you think the interviewer would like to hear and what you believe the correct answer to be.   The question:  “in your experience who do believe has been the owner of usability and in your opinion who should be the owner of usability?”   I generally explain as I ask the question that there is no correct answer that I am looking for and that’s true.  For I’m not sure that there can be one correct answer to this question, nor am I expecting one.  The way to succeed in answering this question in a way that is going to impress me is to prove to me that usability is something that you’ve considered in the past and that can think cogently about.

For sure I’ve had some bad answers but even those could be well mitigated if they are backed up by some consideration and obvious thought process.  I’ve had people why had no idea what usability is, never heard the term.  Most of these get it when I explain it in other words.  Invariably people for whom the concept is too difficult to explain are dropped for consideration for the role.  All of the software that I’ve been involved in producing has user front ends.  If you’re producing front ends without an eye to usability you just don’t care about things like productivity, efficiency, return customers, word of mouth and etc and you’re simply not worth my time.  I had one person insist that the owner of usability should be the end-user and without a doubt, if you don’t pay attention then they de facto become the owner of usability. They will speak with their mouse and stop using your software.  By insisting that the end-user should be the owner, this candidate demonstrated to me a vast misconception of the system and the business.

Only once has an interviewee given me the answer of developer as the one who should be the owner.   I believe I was slightly incredulous when I asked for more details for this one.  I grant you that there may be developers out there that have a talent for design and can produce quite beautiful user interfaces all on their own but honestly they have the deck stacked against them when they go up against this hurdle.  Their day starts and they are already under the influence of a number of disadvantages.   They are generally reading twice converted requirements, if not more, and if they’re not being given designs then they have to themselves convert this into something both functional and usable.  Then there’s the perhaps debatable notion that developers just don’t think like the rest of us.  Developers are just too darned logical.  When you give them a flow to produce they go ahead and produce it, and they might even test it.  And it will work for them.  It will be logical and make sense…to them.  But users are incredibly complex (this is my nice article-way of saying what they are) and their sense of logic has a life-time of reasons to think differently.   No matter what else you might think, your average developer does not have your average brain, experience, notions, upbringing, etc.  Asking their logic to conform to the norm when their very business is assembling logic for a machine makes absolutely no sense.

With the person who answered developer, it would have been very difficult to make the decision to hire them.  Not so much because they had come up with the answer that they did but rather in discussing their answer and what I consider the answer to be they didn’t really come around to thinking about it from the larger picture.  That usability is largely about perspective.  About trying to find simplest most common perspective that will be understood the fastest by the most people and figuring out a way to translate that into a user flow.  It doesn’t have to be the fastest way through a dialogue, it doesn’t have to be the least clicks or the prettiest, it simply has to be the one that is most successful for the most users with the completely immeasurable side-effect of creating the least headaches.

For the record, the answer that I would give to the two part question is as follows.  For the most part I have seen the owner of usability become QA, but QA is the wrong place to hold usability.  If QA is not catching something as being unusable until their testing starts, then the mere fact that you are nearing to a launch date (schedules being the way they are) and usability often being so core to the development that the things that you find to change will not have the time to be altered without delaying the launch.  I think the way that my current organization has bestowed usability jointly between the BA’s and the creative design group is the most successful.  They are doing their work at the beginning of the project and therefore have all the time in the world to screw things up and then make them better.  The BA brings to the table the voice of the customer, the person funding the software, so that whatever you build has a good chance of maintaining the requirements.  The creative design group brings to the table the concept of what is good for the end user.   But you might not have a BA, or a creative design group, or even QA…but you can still think about it.  Thinking about it will always make it better…you know unless you over think it.

QA vs QC

(we'll try to intersperse my personal/professional history with some more real posts to keep things interesting)


I've been in quality for years, depending upon how you define it.  But that entire time has been in Software QA.  It wasn't until i came to work at my current company that directly manufactures product that i really learned what the difference between QA and QC really was.  


The answer used to be pretty easy.  QA is what software quality insurance folks did, finding bugs in software, reporting them and being a productive part of the process.  QC is what that inspector on the line who got to put his/her sticker on each pair of underwear promising that there are no defects in that particular piece of product.  Sounds similar but different.  QA looks for bugs in the system, QC looks for bugs in one specific iteration produced from the system. 


Turns out that the way that software development has co-opted the term isn't really correct. 
As i've learned to understand it, QC or quality control is indeed the searching for individual defects in a product.  It doesn't limit itself to a specific product iteration.  In looking for bugs in software, you're likely doing QC. 


QA or Quality Assurance, on the other hand, when you look at the use of the term across industry at large is looking at the process that produces a specific, or many product iterations and figuring out how to guarantee that there will be a generally acceptable level of defects at the end of the process.  Ie that may mean putting checks and balances along the process, that may mean doing some measurement at different stages so you don't have as many defects making it to the end.  it might mean revamping all of your lead-in stages so that things work better.  


If you look at software testing, QA would include ensuring that requirements are funneled correctly, get maintained through the life-cycle properly and get tested at the end correctly.  That development process produces reproducible high quality results.  


To people outside of software QA these definitions seem pretty rigidly understood and utilized.  To people in QA they might as well have not existed.  QC is what other people do, QA is what we do. 


As i consider the experience that i've grown over time though i realize that in actuality what has happened is that when i was a Jr QA i mostly did QC but as i grew more senior i tried harder and harder to determine what was causing the problems to occur much more than just finding the problems.  Root Cause investigation became one of the important parts of my days.  Finding ways to get people not to make the same mistake twice became part of my windmills. 


I say windmill because in software QA isn't listened to very strongly for the most part.  QA trying to suggest that project or development methodology should be updated is generally not well received.   Of course i'm generally, loud, obnoxious, argue well and can even be persuasive so my points probably get heard more than most. 


I'm not certain that most QA people are ready to actually do QA work in the external definition but it is without doubt for me that it's needed in software every bit as much as it is in manufacturing.  


That said, i will continue to respect the terminology differences and try to quietly educate people as to what they really mean.  Not the words as much as the concepts. 

Quality...the early years

The term quality itself has certainly gone through some changes within my professional lifetime. 

 If you’d asked me 6 months ago, I might have told you that I understood what it meant.  And experientially I probably wouldn’t have been particularly wrong but what I’ve learned in the past few months is that while I understood quality on a number of intellectual levels, I had never really tied them together in a sort of lattice work of interconnected ideas.   In essence I’d never really grokked it.

This all began to change about 3 months ago.   But before we get there, maybe we’ll add in a bit of professional history so we can see my evolution.   15 years ago, in 1997 I was working as a supervisor in Operations at BC Rail, a Class 1 railroad spanning the province of BC.  I had left university a year and a half before and had taken this ops job back to pay back some of my school debt.  My unfinished Materials and Metallurgical engineering degree wasn’t getting my anything, nor was the philosophy degree I moved into from there.   But playing with trains was a very interesting job mentally and it made each day a new and challenging hurdle.  I didn’t mind so much that it was hyper stressful either.   Having trains heading at your terminal from 3 different directions at the same time and a local yard crew to factor into the mix just made things that much more interesting.   What I didn’t like as much was living in small town northern BC (in spite of the fact that I grew up in such towns) and working with so many guys that were determined to do as little work as possible and whine, wheedle or negotiate their way out of even a 6 hour day (paid for 8) let alone those striving for a 4 hour quit.

I decided at the end of 1997 to head for Vancouver, look at going back to school and just be out of small towns.   Somehow between leaving the north and arriving in Vancouver I ended up with two new jobs at BC Rail down here.  One was quite similar to what I did up north and the other was in special projects.  In special projects I did a number of things.  I took on owning the business requirements for a rail car usage metric system, I became a trainer in the field of the same system and travelled around BC teaching all the yard people how to use our systems.  I also became a user tester for BC Rail IS department for the same project.  After a few months of that, the IS dept, so amazed by the difference that someone who was analytical, could repeat their steps and could understand the software could make in tracking down your issues decided to take me on.  
Taking a bit of a pay cut i was hired from operations into IS.  Actually hired into the computer operations department because they were happy to maybe have someone that knew the outside operations but i never actually worked for them.  I was their headcount but i instead started up BC Rails first QA dept.  
I learned on the job, set up some documentation and test standards, made testing much more rigourous and made people get it.   Over time I became the test lead but wasn't reduced to just that.  after a few years the dept did some salary and skills reviews and my title was changed to Systems Analyst.  This was because i was spending about 40% of my time doing QA lead, 40% BA work because i understood rail operations and how to talk to railroaders and could translate back to geekese and 20% 2nd tier support.  I could figure out where problems were coming from to target the best dev support resource faster than most. 


During my time at BC Rail i started to get some pretty strong ideas about quality.  I knew bugs sucked, i could find them like i could find a mosquito on my nose but that wasn't enough.  Figuring out ways to let fewer bugs through to me became important to me.  Getting the guys to write code to stop having so many bugs was a giant hurdle that i never really accomplished.  Still haven't really accomplished.  But it didn't stop me from pursuing theories about mocking developers heavily enough to make them really take stock of their work before they pushed it out the gate.  Early nibbles at controlling quality through process.  i knew that i was the final gate before we could ship something without quality.  It was met with limited success. 


That wasn't the only start i had though...i also got my first real taste of the power of process. We had a great PM come in and run a project for us.  She taught us what a trained and useful PM could really accomplish.  What true cross team standardization of process and documentation could be used for.  That started me down the path of becoming a bit of a process junkie.  More on that later. 


it was pretty sweet but by the time CN took over and closed down BC Rail i was ready to move on. 
next time we'll talk about the summer of no pants and my foray into the world of licensed music distribution. 

Quality Is as Quality Does

Quality Is as Quality Does!

My name is Mike Hrycyk and this is my quality blog.  I wanted a space to start talking about the evolution that quality is taking in my life.  Mostly in my business life, but who knows, it could thread through my entire life.  I’m reasonably sure that if I start injecting a high level of importance of my own opinion of quality into my personal life that I’m going to start having some pretty large issues with my family and friends. (There’s a topic for a future entry right there, ‘what is quality – objective or subjective,’)

I looked around for a blog title, theme, vision, mission statement, etc for a while that would properly encapsulate the way that this evolution has been progressing within my own personal sphere and in the end it kept coming back to, ‘quality is as quality does.’  It didn’t really fit the cutting edge coolness quotient that I’m sure everyone goes for when naming their blog and my wife seems to think it’s a little bit quaint (which is I believe her way of saying it sounds like an old person’s blog).  However, what it kept coming back to was that it really is on point for me. 

I wanted a title that highlighted a few things that the blog is going to tackle as time goes on.

1.        Quality – really I want the concept of quality to be at the core of everything that I’m going to talk about.   Well right there, the word quality is in the title twice, I have that requirement met in spades.
2.        Process – in the past few years I've discovered that I’m a bit of a process junkie. I don’t like process for process sake even a little bit but I like digging into processes to find out how they work or don’t work.  What can be improved?  What would work better if it was just written down?  Simple processes followed regularly can solve almost every quality issue but without understanding the processes contributing to the issues you can’t find those solutions.  I think that the title as a whole contributes to this feature.
3.        Management – I’m really a student of the environment that I live in and one thing I've found as I’ve moved around through management at different companies is that it really isn't something that people learn in a standard manner.  Managers are grown in so many ways and the quality of the way they interact with their jobs, their people and their companies suffer for this fact.  I think the least reliability to be found in job skills out there is in management skills.  I’ll be exploring this a bit as we go as well.

So that explains the title.  It doesn’t necessarily explain the url.  QAisdoes.

I, being myself, is probably the truest explanation for explaining but I’ll try to make it clearer anyway.  Most of my career has involved QA in some way or another and that’s where I identify the strongest.  And to me QA is does, pronounced ‘q. a. is does’ quickly, sounds cool to me.  And really, what can trump that. 

Well, it was also available when I went looking for that ID out there on the web.   I was able to get the url and the twitter name of qaisdoes without any issues.  Now the fact that my wife, when she reads the word, auto-tranlsates it in her brain to ‘QA-isodes’ as in a blog about QA episodes, didn’t help so very much, but still…it sounded cool.

So, in the next entry I’m going to explain a bit more of where I come from and where I’m going but for today, I’m signing off.