Monthly Archives: September 2007

The Ideal Quality Control Person for an Agile Team

I’m not sure if I’m in the minority on this one, but I believe the best fit for the Quality Control role on an agile software development team is a developer hell bent on all things testing and configuration management related. These people are not easy to find. Too many see QC positions as a low rung on the ladder leading to bigger and better things like software development. I don’t see it that way. I see the ideal QC person (QCer) on an agile team as one who can help the team focus on the quality of its software.The Brain - Tonight, quality software. Tomorrow, we take over the world! QC’s focus is on quality, but it’s the entire team’s responsibility to build quality into the end product.

The ideal QCer on an agile team knows how to do all sorts of testing such as: unit, integration, functional, acceptance, performance tests, etc. This does not mean that the QCer is the one responsible for writing these tests, but he/she needs to be able to understand these types of tests well enough to know if the tests are solid. A QCer who cannot do this is at a severe disadvantage in an agile environment. He/she will constantly be at odds with developers who swear they’ve got the right amount of test coverage overall on their code. I’ve found that developers have more respect for QCers who knows how to dig into the details as well as test at the higher levels. When the QCer is not able to get down to these lower levels, they can sometimes struggle to find their place in the process. The types of testing they’ll do will often have to wait until the end of a user story and it only covers a portion of the testing at that point.

Now, on larger projects, you can probably make use of a variety of levels of QC people. The more senior QCer will have the skills I’ve described, while others will only test at higher levels. It’s also not unusual to have QC people dedicated to configuration management on larger projects. The ideal QCer on an agile team should have the ability to understand and contribute to the configuration management (CM) process; including continuous integration. CM is critical to delivering quality software.

I realize I may be asking for too much in a QC role on an agile team. Some will argue that having strong software engineers on the team will eliminate the need for a QCer that provides this depth of knowledge in testing and CM. I’m not convinced. I think strong software engineers will be able to provide a fair amount of guidance on CM and the various levels of testing, but their time will be split in a number of other areas as well which does not provide enough focus on quality like a full time QC person can.

This entry was published on September 4, 2007 under the following topics Agile

Web 2.0 is Agile…Sort of

Scott Rosenberg makes an interesting observation about Web 2.0 software. Scott wrote the book Dreaming in Code, which gives a look into the making of the open source software project Chandler. One of the key points Scott makes in his book is that software is hard. One of the most common arguments against this point is that web applications solve this problem. Web applications are agile in their nature. They can be rapidly developed, deployed and continually updated with new features and fixes.Bloglines and Yahoo equal MS Vista

Web 2.0 makes software almost easy in comparison to past software revolutions. Not quite. As Scott points out in his blog post, both Yahoo! and Bloglines have taken nearly five years to release new versions of their web (2.0) applications — Yahoo! Mail and Bloglines’ namesake app. Five years is what it took Microsoft to get Vista out the door. While it’s easy to build web applications and services in a rapid manner, it’s not necessarily easier to make them scale. I pointed out yesterday that Twitter is having issues with scaling their service as it grows ever more popular. Facebook, MySpace, and many other Web 2.0 companies have faced the same challenge.

I don’t think many people touting Web 2.0′s software development superiority often understand what is involved in making a scalable web app/service. There are so many pieces involved and just addressing some of them (say the database layer or client optimizations) is not an option. Once one piece is made more scalable you find the other pieces are hindering the performance and stability of the application/service.

Web 2.1 LogoI believe that the next revolution for Web 2.0 (I think I’ll call this Web 2.1) is allowing developers to build on top of an infrastructure that handles the core scaling gotchas from the start transparently, without large up-front capital investment. Amazon.com’s AWS offerings appear to be headed in this direction. They’re still missing some key pieces (a reliable/persistent data store & load balancing for example), but it’s promising. The ideal would be for developers to not have to worry so much about the underlying hardware, network, operating systems, etc. For example, if you’re building the next great web app/service with Ruby on Rails, you would love to be able to deploy in an environment that allows you to grow without any worries. You’d want to know that you have things like:

  • Nearly endless data storage that is reliable and responsive
  • As much bandwidth as necessary (throttle on demand)
  • A data store that grows without concerns of having to purchase additional hardware and software
  • An authentication & authorization service
  • A standards based reliable messaging service
  • The ability to seamlessly add more instances in the web and app tiers (on demand)
  • A caching service for all levels of caching (client, database, external data sources, etc.)

If you can have those types of items covered in your deployment environment up-front without the typical capital investments (a big gotcha for today’s Web 2.0 companies, by the way), then I think the five year development cycle Scott Rosenberg references with the latest Yahoo! Mail and Bloglines’ releases can be lessened drastically. The problem today is that you can build your web app/service with scaling in mind but it takes substantial amounts of time to ramp up and test for each increment in the underlying infrastructure. If Twitter (for example) started out running on an infrastructure that had the items I listed above, I think they’d be able to better handle the exponential growth they’ve been experiencing. They didn’t start out on an infrastructure like that because the capital costs are too much initially.

Bottom line, Web 2.0 software development is not a panacea. (Ditto for SOA, as Jim Stogdill (Gestalt’s CTO) pointed out previously.) There are still many challenges faced by Web 2.0 software that makes it far from ideal in terms of solving the age old problems inherent in software. The good news is that there are opportunities to help solve these problems. The question I have now is: Who will step up to the challenge?

Twitter Tools WordPress Plugin Fix

Warning Scrum Master CodingAfter getting an hour or so to focus on coding around the Twitter issue I previously posted about, I think I have a fix. For whatever reason the Twitter API is accepting requests from CURL but not from Twitter Tools use of the PHP library Snoopy. Not all PHP installs have the CURL extension installed, so my code uses it if it’s there, otherwise it defaults back to the code Alex King, the author of Twitter Tools, wrote to use the Twitter API.

I’m going to leave a comment on Alex’s site pointing him to this post. I’m putting the code here for download if anyone wants it. I’m also leaving a patch file here for Alex in case he’s interested in using it. I’m not sure it’s worth it or not – not my call. I’m just happy I can spam…errr…inform those at Gestalt using Twitter when I have a new post on this blog. Sure, they can do that even better using RSS, but that’s not as cool as saying you got it off Twitter. Heh.

This is not an issue in Alex’s code, as he points out in a recent blog post. This is an issue with Twitter’s infrastructure, which users are noticing more as the service has grown. Scaling web apps/services is hard. I’ll have a post on that in the not so distant future.

Twitter API Not Exactly Working Right Now

I installed the Twitter Tools plugin for WordPress on my blog here earlier in the week. I noticed on Thursday night that it stopped working. I did a little troubleshooting on it and found that the call to the authenticated Twitter API URLs were giving back a 301 response instead of a 200. Previously, when I wrote a new post, my Twitter status would update with the title and link to the post. It was a great way to shamelessly self-promote my blog to those following the Gestalt Twitter friends of status. Some call it spam, I prefer to think of it as “direct marketing”.

It appears Twitter made some changes to their load balancing setup and that is not playing nice with previously working consumers of the API like the Twitter Tools plugin for WordPress. I think I have a way around the problem but that means I need to add some code to Twitter Tools. If I write code then the guys back at the office might start to freak out. You see, my specialty is running GoTo meetings, a projector (questionable there), and ScrumWorks. This was first pointed out by James Lorenzen. Never ones to disappoint when it comes to boosting their Scrum Master’s self-esteem, James’ team members jumped in on the fun. I’d hate to ruin my reputation with those guys but I may have to. My spam operation…errrr…direct marketing efforts demand it.

This entry was published on September 1, 2007 under the following topics Web 2.0