From Manager to Developer – A Necessary Diversion

About three years ago, I became re-enamored with software test automation. Oh, I had been using various packaged tool sets through the years with moderate success and barely acceptable support. But with the gradual adoption of Agile development, the open source community responded with superior tools and, better yet, superior community support.

We needed automation in order to take our QA team from good to great. We were wasting so much time and energy on regression testing, that in some cases, management was choosing to forgo regression in favor of a deadline.  Any software development professional knows that regression is where the really bad bugs are. Modifying a top-level class and then skipping regression testing is tantamount to assuming that your parachute will deploy properly without checking the pack…since it worked last time. Anyway…I digress.

I dove in as deep as I could, but soon found out that engaging in what is no less than a full-time development effort, building an automated test framework could not be done while attending three to five meetings per day, maintaining personnel and filling out performance reviews. There was but one thing to do. I asked our CIO to  allow me to work on the test automation framework full-time. This was a risky decision that required me to give up a fairly cushy management job. But I have never been one to back down from what I think needs to be done and what is best for the organization.

Without much hesitation, I selected Ruby, Watir and Rasta to build our our infrastructure. Details about that architecture can be found here in my blog. So on down the road I went, coding and enjoying life outside of the conference room. Within months, the first part of the framework was complete. We could run thousands of regression tests on our Web applications with the touch of a button (and not even that once I configured it to run inside of Hudson).

Then something strange happened at work. A large group of our Java developers, including the manager, left in a matter of a few months. It was nothing that we were doing or were not doing as a company. Each of them had a great opportunity and had to go. A few months before this happened, I had indicated that maybe I could move over to the development group to finish building out my test automation framework, act as the “build guy” since I was now the resident Hudson expert, and work my way into a Java development role. After the exodus, I was officially asked to join the development team as a Java developer. I would not be working on my test framework or anything else I was familiar with. No, I would be working on our main-line products. I would need to learn not only much more Java than I currently knew (specifically enterprise-specific features), but also JSP / Struts, JSF, C#, Hibernate and other packages that our multiple systems require. Was I getting lucky or was I getting set up to crash and burn? My confidence was suspect, but I took the role because that is where my company needed me and they had faith in my skills and ability to learn.

But the whole time I am thinking, “…but I am supposed to be a “manager” right? I mean, that is where I have the most experience and training. Is this the right thing for me to do right now? How will this affect my “leadership” prospects?”. After thinking through this decision, I realized I would be a fool to pass up such an opportunity.

First off, I’ve got the management deal down. Between my experience, degrees and certifications, and moreover the fact that I have successfully managed bands of insane, flaky and usually addicted  musicians and software testers for years, I am more than confident in the ability to lead all sorts of teams. But there was always this…”what do you REALLY know about process of building and writing the code you or your team is  testing?”. While I have written many lines of Perl, Ruby, SQL, batch files and other utilities to make life easier for me as a tester, I had never been a part of the “creative” side of software development. I had never had a bug written on me! That’s like being an art critic without ever picking up a brush or a music critic who can’t play a D chord on a six-string  (and since most of them don’t, I don’t trust them as far as I can throw them).

So here I am three months after I made the jump. It has it been a very enlightening experience, to say the least. Besides knocking my ego down about ten notches, I go home with a sore brain. But it feels good…like I actually created or fixed something instead of just whining about it. Besides doing my music thing and hanging with the fam on the weekends, I love to work on my car and on projects to fix up the house. I crave that feeling of getting something tangible completed whether it is a shelf in the laundry room or tiling a floor. I get that same satisfaction after fixing a bug or adding a new feature to one of the many products we support.  The learning curve has been steep, but I can now hammer nails. Soon, I will be able to set four-by-fours in concrete, tape and float dry-wall and put in new bathtub fixtures. Growth is good.

So to wrap up, I would recommend to all of those who are in software quality assurance: give yourself a chance to be a developer. I don’t mean writing code on the side or even test automation. I mean an honest-to-goodness developer with a development manager, deadlines, and code reviews. You will become  a better tester. And when you make the move you will already have a leg up on development because you will probably be the only developer on your team to actually test your fixes thoroughly before checking them into the trunk! Actually, I take that back. Now that I am a developer, I can see that the problem is that devs are typically focused on a very narrow scope of functionality. This fact re-enforces my belief that developers shouldn’t also be responsible for testing, if money and time allow.

I don’t know how long I will wallow around over here on the “dark side”. Given my natural ability to become bored after a only a single repetition of anything, I would imagine that the first time I get chewed out for not documenting my code or stuck interpreting requirements into technical specifications, I might start thinking that…maybe those all-day meetings really weren’t that bad-especially when they ordered in those  egg-salad sandwiches from Jason’s Deli. I could eat a hundred of those.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>