link[rel='developer']

Over at the Start Up Manager Brian wrote:

So how can such a noble endeavor go wrong? There are lots of reasons, but the most challenging to control is the effect that occurs when the QA department sits in the shadow of Development.

There is sometime a perception that the QA engineers are inferior technically to the developers. If this is the understanding in your organization, then QA will occupy a lesser position in the social structure. This mindset sets up an environment where development has a greater influence over the solitary QA engineer than is advisable.

There’s another variation on this trap that I’ve seen and that is when QA is over developmen — whether in actual reporting structure or pure political power within the organization. When this happens, QA is effectively driving the development process. Their schedule is imposed on the developers.

QA needs a build first thing Monday morning! Well, what if dev isn’t ready to give QA a build? Without equality between the departments or a capable arbiter, dev will be forced to overextend their resources (ie, work late hours or the weekends, resulting in lower morale and quality) or pass along an incomplete or buggy build to QA, thus wasting valuable time and possibly jeopardizing the schedule.

Another risk of having QA-over-Dev is that the development schedule may bloat to accommodate QA’s demands. When the schedule needs to be pulled in, management will be forced to cut features or testing time, neither of which results in a good, quality product.

The takeaway:

QA/QE and Development must be equals within the organization, preferably with a slight adversarial relationship.

1 Comment »
Filed under: Editorial

Joel Spolsky, of Joel On Software fame, recently wrote about web standards. Now, I’m a regular reader of Joel’s blog and usually find some nuggets of wisdom there, especially when it comes to running a business. However, on the subject of doctype and standardistas, he’s dead wrong.

DOCTYPE is a myth.

A mortal web designer who attaches a DOCTYPE tag to their web page saying, “this is standard HTML,” is committing an act of hubris. There is no way they know that. All they are really saying is that the page was meant to be standard HTML. All they really know is that they tested it with IE, Firefox, maybe Opera and Safari, and it seems to work. Or, they copied the DOCTYPE tag out of a book and don’t know what it means.

I think he’s got it wrong here. A designer or page author does, in fact, know that the html is standards compliant. We’re talking markup here, people. Any number of validators exist to check that it is so. This is not hubris, it is a fact.. or at least as factual as your validator is accurate! What a designer is not in control over though is the output of his markup. The doctype does not state that the output, i.e., the rendered page, is standards compliant but rather the input is.

Writing to a standard allows portability, whether your writing C++ or html. It wasn’t that long ago that Visual C++ couldn’t hand the C++ scoping rules for variables declared within a for-loop and when they fixed that bug it was a breaking change. Microsoft handled that in much they same way they’ll eventually handle the IE8 standards-mode issue: you have to tell the compiler (or browser) that you want the new behaviour.

It’s a reasonable decision.

No Comments »
Filed under: Editorial, webdev