Posted on 07/19/2008 3:01:10 PM PDT by CarrotAndStick
It’s funny, let’s say my user asks for a new feature and I say OK we’ll do that...then if they want a status update, I’m asked “when is that going to be fixed?” I’m like it’s not broken! :P
What kind of games do you like? I’m playing Age of Conan and Battlefield 2142 as my main games these days (when I can find the time anyway).
BTW, I code in Delphi (Object Pascal) and Firebird (open source client/server database based on Interbase). I write practice management software for optometrists and opthamologists.
This is a long awaited development that won’t happen any time soon. I’ve been hearing about this idea since the 70’s.
The idea is to make software development more like building a house, where off the shelf components are simply assembled into a solution.
The problem with this is rapidly changing technology. The platforms we run on change so fast that if you develop a pluggable component, it will be obsolete within a very few years because it won’t run on the latest platforms.
This is slowly changing. Writing code to an intermediate layer, such as .Net or Java, which remains relatively stable is improving the situation, but even those intermediate layers are still changing rapidly.
I don’t expect to see this happen during my working life, and probably now in my lifetime.
I just try to be helpful. I don’t think there’s friends list here, you just have to remember.
I think it’s good to have some of QA know how to code. I think it helps them talk to devs about bugs, and obviously if they’re going to participate in code reviews it helps if they actually can understand what they’re reading. But you don’t have to make a QA department that’s entirely coders. There’s subdisciplines within QA like usability who don’t really need any coding knowledge, and automation who have to code in their job.
A lot of companies don’t do QA. A lot say they have a QA department but really they’re QC (quality control, pure testing and reporting), I once said the company I worked for really was just a QE department (quality enumeration, we had an extremely solid deadline, the product was shipping on that date no matter what so our job was to just have a bunch of bugs written up that would be ignored... and yes that release blew up hard in the field and is still hurting the company’s reputation). Real QA departments that do full fledged QA are a rarity in the industry, and that’s probably a part of our problem.
Quality Assurance seems expensive up front, in an ideal world you’ve got one QA person for every developer, they do things that make your schedule go to the right, they make you kill a lot of trees discussing documents, they ask a lot of annoying questions, they complain that your trade show fliers make unsupportable claims. The invisible side of that though is that the earlier a problem is found (from faulty requirements up through mass distributing emergency patches) the cheaper it is to fix. A good QA department can save you millions, but they do it in a way you never notice, one question asked during one meeting with the customer can totally change the product for the better but you’ll never really know what would have happened without that question.
Corporate world guy. I’ve done small startups, a lot of fun except for the stress of wondering if there’s going to be another paycheck. I’m in a fairly large company now, boring but dependable. I’ve contemplating consulting but it’s too random for me, maybe you’ll do stuff this month and make a lot of money, maybe not.
In a small environment where it’s just a couple of people like that, especially when you’re basically in the same department, it could work OK. Though I might deformalize it further, make it so the person who has the most bugs found by the other buys lunch, keep it friendly.
When you have a full dev department and a full QA department bug counting for formal reward or punishment erects a wall between the departments. Devs have a tendency to get annoyed at QA anyway, as one of my bosses put it QA’s job is to tell dev that their baby is ugly so we already have a kind of strained relationship. When one side or the other is getting rewarded or punished for how ugly the baby is the whole company can turn into a war zone. One of the rewards of bringing QA in during the requirements phase is it helps make them partners with dev, when both departments are working together before code gets written it makes the tested product more everybody’s baby. QA no longer has the job of criticizing dev, it’s just the final part of a process, we all designed it, then you wrote it and now we test it.
One of my happier days on the job was about a month into a job where QA and dev had that partnership having left a job where they didn’t. One of the devs walked into my office said he wanted to discuss a bug, I braced myself for The Argument (”it works on my machine, no customer would do that, why are we wasting on such a small issue”), then he said “I think this bug is a lot worse than what you list” I don’t actually know what he said after that I was too shocked.
I resemble these remarks. I are a software engineer. First reaction, blame the software. We’re always guilty until proved innocent. You are all jealous because we have pocket protectors and you don’t!
I think even if we went to that model it wouldn’t lead to bug free software. Sure it would end a lot of coding errors, but many bugs come from bad design, whether it’s poor understanding of the requirements or just somebody with a really bad idea. Of course those “bugs” exist in houses too, we’ve all walked into places and thought “what idiot decided to stick a door there”.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.