I started writing software professionally late in 1997, if you consider the first real web site for which I was paid.  There really wasn’t a lot of architecture or process that went into that first site.  I had been reading on Perl and Javascript and wrote some very simple email forms, picture slide-shows, and did some Photoshop work.

I got going in earnest in the spring of 1998 when I was hired on as a web developer at a local Internet Service Provider.  At first what I did was more hacking that software engineering.  Maintaining Perl scripts written before my time (that had not been that well thought through to start with) and writing Classic ASP (we just called it ASP back then) that was more about getting it to work than getting it to work well.  But I had a background in computer science, and I soon started buying books to gain the Microsoft Certified Solution Developer credential.  This is where I was introduced to software engineering as a profession.  I distinctly remember reading about the roles Microsoft used for software development, and a matrix about who could wear multiple hats.  For example, a manager might also be a lead programmer, a designer might also be a developer.  But a developer could not also wear the hat of tester.  Microsoft was very, very clear on this point.

Of course we did not have a Quality Assurance department at our little ISP.  Hell, the web development department wasn’t even profitable the first year I was there so we weren’t about to spend money on someone just to test our stuff.  And we really didn’t need it at the scale we were at.  I had, at most, two or three other developers on my team during my tenure.  These were mostly part time; we simply weren’t building huge web applications.  Software engineering for me at this point didn’t include a lot of process; what I was doing really should not be called software engineering and I certainly wasn’t calling it that then.

After getting my MCSD and realizing that the entire software industry was booming I took a job with the State of Wyoming making the big cash.  The first big project I worked on had about 40 developers; there was no QA.  We tested our own stuff and occasionally each others stuff.  In hindsight this is surprising because Anderson Consulting (now Accenture) was running the project.  There were several individuals, including the manager, that had over 10 years of experience.  They should have known better.  I know I didn’t at the time.

Over the next couple of years I did a lot of contracting.  There was never any QA.  During this time I was really beefing up on .Net and my programming skills in general.  I noticed my skills increasing sometimes week by week, and definitely month by month.  I was optimistic, but I was still inexperienced.  I thought that quality programming was all that was needed to create quality software.  This myth had started for me in my early programming days, and had solidified at Wyoming, and was reinforced by the fact that I seemed to be writing better and better software and didn’t seem to need QA to do it.  However, I was also digesting a lot of books at this time that said the exact opposite of what I was thinking.

In 2003 we moved to Austin, and I started a full-time job with a local medical software company.  I had come a long way in the 6 years I had been in the field.  I was now convinced of the need for QA, for unit testing, and for other, industry proven methodologies.  I was fortunate to find a job quickly in a down economy.  I was unfortunate to go to work for a friendly, but completely incompetent manager.  She basically ran a cowboy coding shop.  There were no formal requirements to look at, there were no processes in place.  Even though we had a relatively small team information was poorly distributed.  We had no QA, and unit testing was downright discouraged.  I was beginning to think that QA was a myth; no one seemed to actually do it.  Was I wrong?  Had I been right earlier in my career?

During this time I continued reading about process; in the I realized that what we were doing was very wrong.  For the first time in my career the software was complex enough that the lack of QA was obvious in the final quality.  Here I had the proof in front of me. Although it could have been all the other things we were doing wrong – I am sure  When I had a chance to leave the company when even worse management took over I did.  And I found some QA.

I went to work at a second medical software company in Austin about 3 years ago.  There was an entire, dedicated Quality Assurance Department with Quality Assurance Engineers.  I was excited.  I thought I had finally found someplace with individuals that understood software development methodology and applied it to testing of software.  Boy was I wrong.  As the weeks and months rolled by I was moved from my initial R&D role doing framework development (no real QA interaction) to one doing production software (lots of QA interaction).  I soon learned that the vast majority of our QA “Engineers” really didn’t have any clue about software development.  In fact, they really didn’t know a lot about computers.  There were a few bright spots, and a few bright people.  There were definitely some hard working people.  But no real methodology was employed, and leadership in the QA department was horrible from the top down.

My first real experience with dedicated QA showed me a QA effort that only hindered the development of quality software.  Now I really reconsidered my stance.  Was I really, really right early in my career?  Is this why so many shops lacked QA, because QA just got in the way?  I had a hard time believing that.  There were a couple of stand-out QA people that did catch a lot of bugs and did help produce better software.  Most of these stand-outs lacked a background in software, and they all lacked any real empowerment from their management.  What would it be like to have a QA department with smart people that used good process and good management?  What would quality, Quality Assurance be like?

I got the answer last spring when I was laid off and quickly found a job with my current employer.  I ran into my second, real QA department in my career.  And this time I ran into the real deal.   We have engineers that all have a significant background in software development or IT.  I can think of at least three QA engineers at my job that know much more about networking and servers than I do.  I think they all know more about the product that I do.

Over the last year and a half I have come to the startling conclusion that not only is good QA important, but it might be the most important thing in software development of any significant complexity.  It is Quality Assurance Engineers, not Software Engineers, that have the most significant impact on Quality Software.  When this dawned on me a few weeks ago, I felt a bit lost.  The control had been taken out of my hands.  As a software engineer I realized I was not necessarily the most important portion of the product development.  It is the QA engineer that keeps me honest.  It is the QA engineer that tests my software in ways I would never have thought to test it.  It is the QA engineer, writing automation tests that pushes my software far past anything I could simulate.  At my current employer, our QA engineers vastly improve the quality of our software.

I continue to strive to learn new skills and to become a better software engineer.  But something I know is that I will never be a good QA engineer for myself, and am thankful for the people we have.  I think back on all those previous experiences.  I think of those managers at previous jobs that were hopelessly lost.  This is just one more lesson for me.  Trust the experts.  Trust your instincts.  And quality, Quality Assurance is really important.

• Previous Entry: Diamonds and Snow
• Next Entry: What if Marvel influences Disney, and not the other way around?