$#*! My Dev Manager Says

Prologue

I read somewhere that one maxim of a successful blog was that you should never apologize for not having posted in a while…

….that’s all I have to say on that.

Premise

“$#*! My Dad Says” is a popular internet meme where comedian Justin Halpern shares the salty and (inadvertently) funny comments said by his father on a wide range of subjects. As a Software QA Manager (and in the past as an individual contributor SDET and SDE) I have worked closely with many Dev Managers and have sometimes stood in wonder of their perceptions of how quality software is built. So here is a listing of those things.

The important thing to keep in mind is that these are the comments of no one specific Dev Manager, but instead a composite of 15 years of Dev Managers I have worked with. And also since I just started a new gig in the last 2 weeks, be assured that none of these comments reflect anything said by the fine folks in my new org.

$#*! My Dev Manager Says

“I have never seen it done that way, therefore it’s a bad idea.”

Usually preceded by “In my umpteen years of experience building software….”, however I don’t think they usually say “quality software”. I personally wish to learn from the experience of others. I respect someone’s track record of delivery and want to gain even just a fraction of their knowledge so as to better complete my own understanding of software. But we have to look forward as well as backward. There is a lot of innovation in software process today, and even with years of experience (especially if they were many years with the same company or org), their view of the software industry may be narrower than they think. This quote is a non-starter with me, especially since when I encounter it I usually gut-check the suggestion in question with other software professionals who concur, “oh yeah, sounds reasonable to me”. 

“Closing bugs is not important” / “Closing bugs is fine when we have time, but what’s really important is resolving them”

OK, quick refresher. A bug is found and set to the Active state; Someone (often Dev) fixes the bug and it is then Resolved; Someone (often QA/Test) verifies that the bug is indeed fixed and that it has not caused any regressions, it is then Closed.

The bug is Resolved, what could go wrong? Why spend the time testing the fix? I am sure the Dev tested it…right? For starters if the Dev did test it he likely tested his local build on his own machine; If we are lucky he wrote a unit test or two that will execute on the build machine (hmmm..unit tests as a condition for bug closure..good idea). That testing can be very different than what happens in a real environment. And it is myopically focused on the bug, how about collateral damage. Now as the Testing in Production guy I am fine if not every bug requires a full test bed setup… go ahead and evaluate it with a limited production deployment, just make sure someone is watching and documents that the bug is truly closed.

“If QA does not have enough resources this sprint to cover features, then we just need to cut the time you spend on evaluating and responding to the results of the test automation”

Here I mean the test automation already in place and running… the regression checks. Why would the QA team need to evaluate and respond to the results of the test automation? Because they will fail. Two main reasons here: Broken Product or Broken Test. Broken Product means a bug should be filed. Broken Test can mean many things. Perhaps poor communication between dev and test resulted in product design changes that unexpectedly broke tests. Or maybe the test automation is not robust enough and requires redesign. Either way the test needs to be fixed or it serves no useful purpose. When sprint after sprint tests failures accumulate without investigation this is known as technical debt. It’s a drag on current productivity, it fogs your ability to understand the quality of the current system, and the dues will still need to be paid someday (with interest).

 

“UI Bugs aren’t important. Stop filing them”

Maybe they’re not important, but how will we know unless we track them and review them? To simply turn a blind eye is inviting trouble. Even if we make the business decision that areas of the UI are low priority, then how many of these low Pri bugs does it take before it has user impact? Sure one or two low Pri bugs can be ignored, but there comes a time when a critical mass of these should be bundled up and resolved as a higher priority item.

“My Developers do not want to write tests”

My 2 year old “doesn’t wanna” do many things she should be doing for her own good. The proper response to the above quote is the question, “Then what do they want to do?” If they want to produce business value, then they should consider writing quality software…no tester is going to “bake in” the quality for them. However if they just want to write code then at least they are honest. They can write lines of code, but this does not mean a valuable, usable product is the end result. Considering it is the year 2010 I am surprised when I encounter the Neanderthal attitude of “me code. you test”, and would only hope to find it in the greenest of recruits. When coming from a seasoned manager or engineer it is disheartening, but thankfully rare.

“We need to find a way to do both”

Software quality assurance is all about risk assessment and communication. If we determine that we can either complete feature A and slip the release date, or keep the release date and bump feature A to the next release, and we substantiate this and communicate it to management and product owners, then we are doing or job. A sane organization will then choose one of those options. If you are asked to nonetheless to do both, then I would call this a Forlorn Hope, and I hope you get appropriate accolades if you somehow manage to pull it off. Unfortunately it will more likely end as most suicide missions do.

Bonus

None other than Bill Shatner stars in the TV adaption of “$#*! My Dad Says”. 

Yes I said TV….it’s a new series… clip here.

So when faced with a recalcitrant Dev manager, my advice would be WWJTKD?

Technorati Tags: Software,software development. Management