Bikes and Code

Uh, yeah.

So it is, but actually stating that, or anything along those lines? Way to kill the team, boss! (See Peopleware)

That said, quality assurance, quality control, QA, call it what you want, but it’s one of the more misunderstood aspects to software development. Oh sure, everyone knows that they need to do more QA or better QA, but lip service is about all that is ever paid towards it. I am notably not including in my ‘everyone’ those who feel that QA can be completely automated. You guys are wrong and I’m going to leave it at that. You also may think you don’t need to do it, see this article for some classic arguments against that fallacy.

I’m not going to go into depth about QA, how to do it, best practices or anything along those lines as I’m fairly unqualified. That said, I’m not really qualified to talk about anything, but that doesn’t really stop me.

QA is a processes, not a task

This particular fail case is something I’ve seen in multiple organizations now. The most obvious symptom of this is when management has decreed that there is a block of a few hours set aside to ‘do QA’ on an application with a few hundred known use cases. Another obvious indicator is when other employees are volunteered to do a few hours of QA on top of their normal job. Think you’re going to get good results from that?

The root cause of this failure is simply not understanding how QA works, so let’s walk through it a bit. In a very broad sense, the general list of tasks for QA is something like this:

1. Go through the basic cases

2. Go through the corner cases

3. Go through obscure, known failure cases

4. Exploratory testing

5. Automating 1, 2 and 3.

So, how does this fit into a day of work? Let’s find out:

First off, we’re going to go through the basic use cases for the application. Then, there is a pile of corner cases that are pretty valid that need to be checked out. Then it’s time to check all the really obscure, but horribly embarrassing failures that have been seen before. From there we can finally…What? You changed the code? Okay, first off, we’re going to go through the basic use cases for the application…

Interruption here! “Silly tester,” says the savvy developer, “You only need to re-test the parts of the system that were changed.” Nice theory, but wrong in many, many ways. Simply put, if this was the case, testing outside of developers would never be needed. That generally goes well.

Back to the task at hand, do the basic cases, do the corner caWHAT? Changed again? Basic cases…

The real job of QA starts at step 4, which we haven’t even seen yet. Exploratory testing is finding the embarrassing defects before they get out into the wild. A good tester at this phase is going to break your application in ways you haven’t even dreamed of. In ways that only 0.1% of your users would ever try to do. Of course, if 0.1% of your users do it, and you get 10k uniques per day? That’s 10 people per day that are going to hit this embarrassing bug that how could you possible let into the wild and I’m taking my business elsewhere right now as I obviously cannot trust you with my data. And if one of those has a blog? Heh. Have fun with that.

So the epic fail with having 16 hours scheduled in to test your quarter million lines of code application? If you’ve got bug fixing going on at the same time, any of your competent testers will never get past step 1. Any testers that listen to the savvy developer, or worse, are the savvy developer will miss basic cases and you deploy with fundamental breaks.

The purpose of QA is not to have someone say, “Wonderful developer, your application is perfect!” If I hear that from a tester, I assume the person isn’t doing their job very well. QA should hurt your feelings. Assumptions you made should be laid bare and justified or thrown out if incorrect. This is often the last line of defense before your customers see your application, take it seriously.

Once upon a time, the world wide web was invented. I’m not really going to talk about that. Later, something called the Hypertext Markup Language (HTML) was developed. It let you share nicely laid out documents over the web. And it was Awesome.

HTML had some limitations though, it was kind of verbose and you had to mix up your content, paragraphs and such, with code that was used to show how the thing should be laid out and look. At more or less the same time, there were two new pushes to make HTML better. Javascript (1995) was developed to allow a web site designer to make things change on a page. No longer would a web page be a simple static document like a magazine or newspaper article. Cascading Style Sheets (CSS – 1995-1996ish) was created to help a web designer keep the content, the article, online store, etc. distinct and in a different place from the stuff that was responsible for how that content actually looked on the page.

And this was Awesome, except, it wasn’t. At the time that these developments were happening, the First Browser War was underway. Netscape put some Javascript and CSS stuff into their browser. Microsoft put different things into theirs. Bit players in the browser wars did other things. The end result was that if you wanted to make a sufficiently sophisticated web page, you had to create two or three versions of the thing so that it actually worked in multiple browsers. Now, for a long while, this did not actually matter as Internet Explorer 6 held so much market share that you could target IE6 only and get away with it.

That is no longer the case. Arguably, it was never the case, but there were lots of so called ‘web developers’ who happily wrote sites that worked in IE6 and IE6 alone. There are several major browsers now. More importantly, there are several major devices now. Blackberries, cell phones and game consoles all have limited support for browsing the web in various forms. It’s probably a good idea to try to write your web code in such a way it works in as many platforms as possible. More specifically, at least the major platforms that your clients are using.

Approaches

Inevitably, however, some of the fancy dynamic content, crazy layouts or Javascript dancing puppies will not work on some platform that at least some of your customers are using. There are a couple of different strategies for dealing with this scenario: Progressive Enhancement and Graceful Degradation. Effectively, the end result of either of these strategies is the same thing. A website that functions properly under just about every browser platform. There is overlap between the two strategies, in that you can safely say a website built via a progressive enhancement strategy will degrade gracefully. That said, there is definitely a difference in the development process when building a web application in either of these manners.

Having worked on projects that focused on graceful degradation, I can offer my opinion that it is a route fraught with problems. My gut feeling is that if you are going this route, you’re almost better off writing off customers who don’t have your minimum supported browser.

Progressive Enhancement and HIJAX

I’m mostly going to talk about progressive enhancement now as my current project has gone that route. I mainly went that way as I was concerned with the smell of the code that I had written or worked on in the past that went the other way around. Taking a full featured, beautiful Web 2.0 application and trying to hack in static HTML support was difficult and led to some fragile functionality in places. Progressive enhancement seemed to solve that problem in that you started with a functional, solid HTML version and then began to add the flashy enhancements.

Google for HIJAX and read some of the blog posts you find, all are pretty short and give you an overview of the approach I am making with this particular application. There isn’t really a definitive definition of HIJAX, suffice it to say, the point of the thing is what I outlined above. Normal, old fashioned site first, then start writing the flash. The basic philosophy is “Plan for AJAX from the start. Implement AJAX at the end.”

Of course, there is no silver bullet.

While I truly do like the development process that follows with HIJAX, I cannot help but feel I have traded one type of code smell with another. Well, in this case, it isn’t really code smell, it’s more of a project management smell. The single biggest problem I have with the simple HIJAX philosophy is how simply it discounts the nature of web applications.

Implement AJAX at the end.

This is where it all falls apart. Anyone who has built web application that goes beyond the trivial knows that there is no end. Paul Graham talks about the advantages to web development in The Other Road Ahead. He has an entire section dedicated to releases and notes that in a web application, you really don’t have releases. You have features that you deploy one or two at a time.

So if there is no end, implementing AJAX at the end isn’t really possible. So the HIJAX philosophy migrates more into a “Plan for AJAX from the start. Implement AJAX in chunks as you go along.” This is notably still different from “Implement AJAX from the start”, but must be pointed out. The majority of articles and essays on this topic that I have read thus far do not take a high level perspective. They deal with specific implementation issues and provide an outline that works at the feature level. The naive philosophy will not work when applied to an entire project.

This is not to say that it is a lost cause and we should get back to writing rich applications that only work in specific versions of Firefox. Progressive enhancement is the way to go for a general purpose application on the Internet where you do not want to drive away any customers. HIJAX, on the other hand, is a nice buzzword for a simplified philosophy that I think will die out quickly as it becomes apparant that it is just a bit too simple.