This past weekend (7/29-7/31) I participated in my first Cleveland Give Camp event! This was the second year of Cleveland’s Give Camp, and I had heard about it too late to participate in it last year. Once again, it conflicted with the PyOhio conference, which I went to in 2010, and hope to be able to again, so hopefully event planners will try to do better to avoid conflicts in the future. Not that it’s always possible

I was slightly apprehensive about how it would all work out, being my first time doing it. It didn’t seem like it would be possible. In just 72 hours, I was supposed to join a team of developers whom I’d likely never met before, and collaborate on a small IT project on behalf of an Ohio nonprofit organization who had a worthy project. The projects were evaluated ahead of time so that the Give Camp organizers could select candidates who could be helped within the constraints of the event’s format. This was a well planned weekend, and we were able to be productive. In fact, all 22 projects were successfully completed this year, up from 14 last year. In total, over $500,000 in professional services were donated. Burke Lakefront Airport and LeanDog generously hosted the event, which was funded by a raft of corporate sponsors. Volunteers camped out and worked all weekend, and in exchange we got fed and thanked and made to feel appreciated. This seemed to be pretty fair.

Most of the projects were to create web sites. There were a few that were mobile applications or databases. Of the web sites, most if not all seemed to use WordPress. I’ve been using WordPress for my own site for more than a year now, and have liked it. I like it even more now! WordPress is so powerful, flexible, and easy to use. I may gush about that later.

Team 14

In our opening meeting, we were assigned to teams. In my team, we had a project leader, and a couple developers, and I served as the team’s designer. When we sat down to go over the project, it took me a few minutes to realize that eyes were on me to tell the developers what to do; I had expected there would be a little more direction from the project leader, but after we had dinner on Friday and sat down together to meet with our customer contact, Lisa, we just went around and briefly introduced ourselves, and were let go.

Lisa told us about her organization, Adaptive Sports Programming of Ohio, and we took a quick tour of their old website. I spent about five minutes clicking links and skimming, and quicker than I knew how, I came up with a bullet list of the top 5 or 6 categories of information, and proposed that we try to re-organize the site’s content in that fashion. I noticed that much of the site’s content was geared toward linking to other resources. This is an older approach to web strategy, and seemed to me a bit outdated, a bit reminiscent of the early Geocities-era world wide web, when the manually maintained index of Yahoo! ruled. Maintaining all that content was a lot of work — checking for dead links and whatnot, and, I reasoned, was not effective in the current era, since most people find content on topics they’re interested in through google or through social networks. I proposed dropping as much of this “resource” content as the customer felt comfortable, and putting the priority into emphasizing the other categories, most importantly: donations, how to get involved, and events that their organization was directly involved with.

To my surprise, and to everyone’s credit, there wasn’t any resistance to this idea. I was a bit worried that Lisa might feel like I was about to destroy “her baby”, or simply disagree about the importance or purpose of various parts of the old site, but she was ready to put her trust in us with us right away, and the rest of the group seemed to like my proposal as well.

Throughout the weekend, we (and I emphasize “we”) quickly made decisions together in a most expedient manner, without egos butting heads or any of the typical bad human behaviors that I’ve seen over the years which have wrecked teams and projects. Someone would have an idea or see a problem, get someone else’s opinion on it, and propose a course of action, and it would either be adopted readily or if someone else had some additional thought on it, this was added to the original proposal, and we went with it. I never felt like I was pushing on anyone else on the team or stepping on anyone’s toes. It was great. The couple or three wrong turns we made along the way didn’t cause us any real harm as a result, and when we changed course both abandoning the old idea and adopting its successor went very smoothly.

One of the concessions we did have to make was that we weren’t able to migrate all of the content from the old site over to the new site. By the end of the weekend we realized we would not be able to get 100% of the new content for the site up by the time we were finished. Too many decisions needed to be made about the content, which were best left in the hands of the site owner, which is what we did. We ended up building a good, but mostly empty, new “house” for her to move into.

In retrospect, our project might have gotten more accomplished if we’d had someone do a content inventory and figure out what to do with it all. My initial idea that we could simply re-organized and adjust emphasis according to the priority of the site’s missions was a good thought, but as we got deeper into the content on the old site, it became apparent that simply copying and pasting it was not going to be effective. The old site had a lot of content on it, not all of which was going to come over. The volunteers on the team couldn’t make decisions about significant amounts of it without the site owner.

I had the thought late Friday that once we got the new site up and running on WordPress, we might be able to get Lisa trained on managing content in WordPress, and have her get familiar with it by bringing over the content herself after we got her started. This didn’t end up happening, either. There was too much else to do, Lisa needed to be involved in other decisions, and her availability for the weekend wasn’t as total as the rest of the team. Much of the content needed to be re-thought, not just re-organized. We didn’t have a dedicated copy writer on the team, and even if we did we might not have known what content to re-work and what to ignore without direct involvement from the site owner.

I think we can consider what we ended up with a successful IT project. We produced a redesigned web site, built on open source, which promises to be easier to manage in the future, and handed it off in “move-in ready” condition. It’s certainly an improvement over the infrastructure that they had in place previously.

The Takeaway

Keep it simple, less is more

There was a good bit less coding on this project than I would have guessed, going in to the weekend. In fact, I gauge our success in no small part by how much we did not need to code to get the project done. Code we wrote was code that someone would have to maintain, and the way Givecamp projects work, there is no provision for support once the weekend is over. We didn’t want to leave Lisa stuck with a project that would need ongoing code maintenance, and no one to do it for her. Accordingly, a lot of the things we could have considered doing for the project, we dismissed in favor of finding an off the shelf solution that we could mash up to create what we needed.

This was definitely the right way to go. The amount of customization we needed to do in order to get the site working and looking the way we needed was not zero, but we did keep it minimal. What customizations we did make were documented and handed off to the site owner. It was all, as far as I know, css, php, or javascript — all of which are interpreted, and thus can be modified without need for recompiling. We spent the bulk of our time looking for plug-ins and figuring out how to configure them, testing things out, and fixing this or that with the least amount of customization that was needed. This was a good application of the “what’s the simplest thing that could possibly work” principle.

Whence TDD?

We did not elect to take a TDD approach, but it is really not apparent how we could have had we wanted to. With so much existing code provided for us in the form of the WordPress application, the themes, and plugins, embedded youtube videos, and so on, there really wasn’t much of anything to write a test case against. I’d be interested to hear from someone more experienced in WordPress and TDD to provide some ideas on how to take a TDD approach to building a WordPress site. If you want to use TDD, do you need to start from the ground up, or at least find a stack that will lend itself to the TDD approach? When you’re dealing with platform built out of interpreted code, and with the final interpretation of html, css, and javascript are all up to the client, what value do your test cases have?

WordPress still doesn’t guarantee success or quality

I love WordPress for how easy it is to use. It has sufficiently abstracted the web stack that you can do a tremendous amount with it, without having to write one line of code. It is well maintained, and yields web sites that are easy to maintain. That said, it still does not guarantee optimum results. It takes skill and knowledge to deliver that.

At the end of the weekend, the 22 projects that the Givecamp volunteers built were presented for all to see. While all 22 projects were completed, and about 18 of them were web sites, most if not all of which were built on a WordPress platform, I did observe limitations of what can be accomplished in a single weekend. Without singling any project out, I could see some design issues in the final products that were completed by Sunday afternoon. I could only observe the most obvious design problems — bad typography, disproportionate layout and whitespacing. And granted, typography on the web is still in a pretty horrible state which CSS3 will hopefully address. I don’t mean to come off as negative or nitpicky. Still, there were a few sites which I saw that had obvious problems that probably could have been fixed with a few minutes (at most, hours) of CSS tweaking. Even our own site was not 100% perfect, and I’m confident there is no such thing as a weekend web site that can’t be improved with a little more labor.

Not every team might have had the eye or the skill or the time, and I’m certain that every group delivered a product that was better than what it was replacing (which in some cases might have been nothing at all) and was appreciated by the recipients of our giving. But I hope that future givecamps will have more designer resources to go around. And copy writers! In fact, I’m tempted to say that the WordPress ecosystem is so successful at solving the developer side of the problem that future givecamps might well be better off with more copy writers and editors than developers.

Success on Monday, Sadness Tuesday?

Given how happy and successful everyone seemed to be at the end of the weekend, and how… well, Dilbertesque the real world seems to be, I had to wonder if somehow all the success story I was seeing around me all weekend wasn’t somehow an illusion. Like, why do real companies have such a hard time with IT projects? I’ve never had such an easy, happy time working on a real-world project as I did this weekend. And I can’t really chalk it up to having the right people. No complaints about our team, but we were just put together and had never worked before. We weren’t an established, well-oiled machine.

My biggest worry about the effectiveness of an event like Givecamp is that, no matter how much you can accomplish in one weekend, ultimately the long-term success of these projects is in the hands of the organizations we gave them to. We can give them a great start, but without proper maintenance and attention, any website will quickly languish and become irrelevant And without a web-savvy content maintainer, that ain’t gonna happen. No matter how easy and intuitive a developer thinks they have made something, there’s always non-technical people whose purpose in life seems to be to prove the cynical adage about nature building a bigger “idiot” whenever an engineer thinks they’ve idiotproofed something.

I’ve seen proud development teams hand products off to users, who manage to break things in some novel and heretofore unforseen manner within seconds too many times to expect that this should somehow not happen here without good reason. I think one such good reason is that WordPress is good, mature, and healthy. But not every project was done in WordPress. At least two were done in C# with MS Access backends and one was done in iOS. I’m really curious as to the viability of the Access apps.

I was talking with event organizer extraordinaire, Mark W. Schumann, about this, and he’d had some thoughts along these lines as well. We’re both really curious to measure the long-term success of these projects. Because, let’s face it, as good as it makes us feel to donate a weekend and do good deeds, we want our efforts to be as effective at solving the problems they were designed to solve six months or a year from now as our efforts were appreciated when we handed it off. It’ll be interesting to see what we can see a year from now. I’d really like to see some quantified measurements next year.