Today the final straw was added to the one ton weight of hay piled on my dromedarian back. I’m flat on the ground, dilapidated, and I refuse to go one step further as the smelly, flea-bitten work-camel that I am.
Let me explain:
Here is why your computer stopped working tonight, and your DVD player and the computer in your car and the digital display on your microwave — the majority of technology companies do not value quality. Even the little tiny companies. Even the huge companies. Even the companies with the vast marketing campaigns on quality: no dropped signals (if you are in the middle of a clear field in the center of a major metropolitan area), battery lasts 20 times longer (if it doesn’t catch on fire and burn up in the first 20 mintues of use), software that does the work of 3 paid professionals (who take 2 hour lunches and use the company credit card to entertain prostitutes during work hours).
Quality checks are often at the end of the development process. You can test as you build, but as you might imagine, you can’t completely test a product until all of its parts are integrated into a whole. In my experience, the people who design and build the project always need more time than they estimate. I’m actually very forgiving of this. There is great pressure from the executives to get a product to market fast, yet I view most cutting edge technology products as experimental. They haven’t been done before, so it is pretty hard to foresee the the bumps in the road ahead. Developers can’t foresee all the technological difficulties that will arise, and they are pressured big time to ship these things fast. The result is their time estimates are often underestimates. Because of the pressure to ship, the extra time the designers and engineers need to build a product is often taken out of the time scheduled for quality checks. This means that planned quality checks are constantly being cut in order to ship a product on a marketing driven date (back to school, Christmas, end of quarter). Some will argue that agile development, extreme programming, and iterative development are all development models that solve this problem. Wrong. In my experience executives are using these models as a reason to cut QA time and resources. They save money by laying off QA teams and shifting the quality responsiblity to the programmers or project managers. The Holy Grail of software seems to be to get rid of human QA. It used to be automated testing that would replace me, now executives are saying that they never needed me in the first place, QA can be done as the programmers while they write the code.
Something else, horrifyingly lacking in integrity, that I’ve heard bantered around is that once the consumers buy the product – they are stuck. The realization that the product has problems doesn’t hit until after the company has your money; so the company doesn’t really need to care about minor issues. Additionally, the company doesn’t want to worry about issues it doesn’t know about yet. The fewer reported issues the better, in a way, and the less testing you do the fewer problems you find. If I’m the flea-bitten work-camel, most of my bosses have been ostriches with their heads thrust deep into the sand.
Here is a benign (and fictional) example of how this affects you. A company is developing a software tool that you used for the last three years to catalog your photographs. A whole bunch of exciting new features have been added to this new version. You can’t wait to get your hands on it. Because of some technical hiccups, recent layoffs, and a moritorium on purchasing equipment, the project is behind schedule and only a few of the top brands of cameras are tested with the photo import feature. Also, the company decided to cut back on the planned quality checks in order to ship in time for Christmas. They (they = the executives and middle managers, not the QA or Programming staff who are immersed in the technical details of the software) decide that only the new features will be tested. They rationalize that all the old features have already been tested and shipped, so they don’t need to be tested again. The reality is, the new features are integrated with the old features. That means that bug fixes and new code will break old code. Features that used to work for you may not work anymore after you update to the new version. After you purchase the software and eagerly install it, you find that the old sorting functionality for your pictures doesn’t work anymore. You now have 2000 pictures in one long list, all the reference tags are lost, and it seems like you’ll have to completely resort them again. You call tech support (assuming this is a company that is nice enough to not make you pay for tech support, otherwise you spend an hour Googling the problem to see if anyone else has experienced this and fixed it.). If you are lucky someone is already aware of the problem and has a patch or workaround. You download the patch, install it, and check the photos. They are organized now, but not quite right, so you spend a little more time getting them back the way they were. All of this takes an extra 2 hours of your time. That is two hours of pay. If you make $10 an hour, that is dinner out or a movie with snacks or 83 packs of Top Ramen! 83 PACKS!!! That feeds a college student for about 27 days!!
This is a small example. However, this is happening all the time, and no matter how small the actual glitch – your time is valuable. You are the customer, you paid the cash, and you shouldn’t have to coax your supposedly time-saving technologies into actually doing what they’ve promised.
Here are some entertaining and interesting links about technology and bugs in the real world:
http://www.wired.com/news/technology/bugs/0,2924,69355,00.html
http://catless.ncl.ac.uk/Risks/24.08.html#subj4
http://www.badsoftware.com/alienwaresucks/
http://www.badsoftware.com/stats.htm
As a Software QA engineer, I’ll be the first to admit that there is no remote possibility of finding all of the bugs in any given product. I also wholeheartedly understand the reality that eventually a company needs to draw the line and ship its product, otherwise it will go out of business. You could test and tweak software (and probably any other product) forever and never get it perfect for your most typical customers let alone those ‘finge’ users who really push the software to its limits.
However, what broke me today, after years of attempting to assure some sort of quality for various software companies, is the realization that I have rarely worked for a company that even gives its QA team a reasonable shot at testing the product. The QA staff is not involved in the decisions of what should and should not be tested – executives make those decisions based on time and money, not technical information. QA is the department where the CEO’s children are placed to do their summer ‘internships,’ because in the eyes of a huge portion of the software community, QA is not a skilled job. Companies too often ship their products with known crashing bugs that are rationalized away as “our main customers don’t use that feature in depth enough to ever see that” or “only QA would see that bug” or my personal favorite “how can you know that this Spanish speaking software is horrible; you aren’t even a native Spanish speaker” (This is NOT a fictional example. 2 years of high-school Spanish taught me enough to know that “niño” is pronounced neenyo and not neeknow). By the way, that product was about to ship when this issue was seen by the CEO’s friend who pointed out the horrible Spanish. Because of that, the product never made it to market. The company developed an entire product, including marketing and print materials and never made a dime off it, because they would not take the time to double check the QA lead’s bug report early in the project. By the time the managers heard it from a respected outside source (this particular company does not respect its QA staff nearly as much as the CEO’s friends and relatives), it was too late to revamp the product without reworking a huge portion of it – it was cheaper to shelve it than to fix it and ship it.
This is my life folks. It doesn’t seem to matter who I work for, how many hours I work, how brilliant I am at test planning, the knack I have for uncovering bugs, or how much I advocate for product quality. I will not be given the opportunity to even do a percentage of the job I am capable of. I am seen as something that eats money and time, but only creates a headache in return. If I push too hard – I’m fired. I’m perceived as the child who doesn’t leave home at 18, doesn’t get a job, eats all your chips (even the ones hidden behind the Ramen in the cupboard), and then calls you to tell you to buy more chips on the way home from your double-shift at work.
The way I see it, the main thing that can improve the quality of everything you purchase: food, services, healthcare, software – is you. If you put your money where your mouth is, the quality of products will improve. I’ve seen this myself. The QA staff can fight for fixing a bug until they are bloody pulps and not make any headway. Then a customer calls with that bug – woosh – it’s fixed.
When you find a problem that costs you an hour or more of time; let the company know about the problem and suggest they reimburse you for your time. Charge them what you earn per hour at work. If you don’t work, charge them a reasonable hourly wage. If you want to make more of a point – charge them in Top Ramen. If the company does not respond within 5 business days with a non-automated, personal response; if the company does not fix your problem within a reasonable amount of time; and if they don’t at least offer you an apology, a T-shirt, a joke — something that makes you smile — ask for a refund and inform them that you will be buying the product from their competitor. And then, go do that – don’t buy their products anymore.
Really folks, the consumers are in control (well, our money is in control). If all of us bit the bullet and put our money where our mouths are, supporting only those places that provide quality products and service instead of what is cheapest or most convenient (ie: on the drive between work and home) – I think we could actually start to change things. We could get some knowledgeable (maybe even at no cost) tech support, friendly and available customer service, and maybe even software that works the first time we install it.
In the meantime – I’m going to research other careers. I want a job where I’m not set up for failure from the start. Instead of being the pesky bearer of bad news who eats up money and keeps the product from shipping, I want a job where people are glad to see me coming. I want a job where people might even have a better day because I was a part of their day – not in spite of it.
New carrer? I’m thinking of joing a convent that allows married women. Sisters of Divine Retribution.