Fewer Moving Parts Means Fewer Broken Pieces

Fewer moving parts means fewer broken pieces
When every other start requires a brand new thesis
–David Bazan, Fewer Broken Pieces

Why does this David Bazan song keep running through my head as I work with software development teams on a daily basis? Smaller teams normally translate to fewer problems. And when you have a new mix of team members, you pretty much start over from scratch in terms of chemistry, trust and all that other touchy feely stuff. A new team charter forms, not unlike a new thesis.

Maybe Paul Graham’s essay on Holding a Program in One’s Head plays into this line of thinking. Graham points out that the lone coder can accomplish some amazing results, especially when compared to a large team of software developers. Then again, what about the “wisdom of crowds” that is all the rage these days? You can find it in open source software, Web 2.0 social networks, wikis, and many other modern day businesses.

Clearly, I’m confused and tired right now. Anyway, I’m going to catch David Bazan in concert tomorrow night. I haven’t been to a concert in probably two years. I’m hoping this concert restores my faith in the concert going crowds these days. I stopped going to concerts mainly because far too many people seemed to be more interested in chatting (screaming, really) with their friends than taking in the music. It makes for a wonderful experience – not.

[youtube]http://youtube.com/watch?v=CXrdOHgPYOQ[/youtube]

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.

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.

Attack of The Resume

Is your resume really long? Is it chock full of never ending prose? Does it cover every job you’ve held since about the age of ten? Does your resume lose YOUR attention three sentences in? Take heart, you’re not alone.

I’ve noticed a trend in tech resumes over the years. They tend to be extremely long, boring and short on anything I would consider informative. Earlier this year I swear I had a twenty pager in front of me. I wouldn’t mind it so much if people wrote overly long resumes that read like a decent novel, but most of them are bordering on nonsensical due to poor grammar and horrendous formatting. My designer friends would cry if they saw the abuse of typography committed by some of the resumes I’ve had to review over the years.

Enough criticism, now onto what I’d like to see in a resume. I really want to know what you’ve accomplished in the past. Accomplished, that’s the key word there. I don’t care about what you did day-to-day at your job. It’s nice to know that you did everything from re-engineer the next Pet Store app to water the company’s plants, but we can talk about that later. I care about answers to questions like: What have you done that has made a positive difference? What were you able to make happen that delivered value to your customers? If you can communicate that on your resume, then you have just put yourself in the top 20% – easy.