Late last year, the first ever FullCodePress International Site In A Day Competition was held in Sydney, Australia. The two teams (Australia and New Zealand) worked solidly for 24 hours, and at the end of the competition two not-for-profit clients walked away from the competition with brand new sites.
An interesting discussion arose on the SitePoint blogs in the aftermath of the competition, posing the question: when you’re building a new site for a client, should you use an existing CMS, or should you build the CMS from scratch? Team Australia used Drupal, while the CodeBlacks (the New Zealand team) built their CMS from scratch on the day. The two back-end developers involved in the competition both had plenty to say on the matter, so I decided to talk to them some more about it. Here’s what they said:
Rex Chung (Team Australia)
SitePoint: As the team’s programmer, what preparation did you do leading up to the event?
We met up as a team, and decided in advance that we would use a pre-existing, open source CMS. Drupal and WordPress were the top two choices, as they’re most popular options and some of us had experience in implementing them. We also looked at the list of plugins available for Drupal, and decided that they might be useful for us on the day.
SP: What benefits resulted from the decision to use Drupal as the content management system that powered your client’s site? How do you think it limited you?
Drupal brings various benefits as well as challenges. The main advantage was the time it saved us over developing from scratch. However, there’s definitely a learning curve, and none of us were experts in customizing Drupal.
There are more benefits from the client’s point of view, though — Drupal has a built-in permission and security model, the ability to store multiple versions of content, the calendar/events plugin, and so on. Drupal is also a very popular open source CMS, so it will be easy for the client to find developers to support the system if we’re not able to do so in the future. And finally, there’s a lot of room for enhancing the site in future via various plugins and upgrades.
SP: Where did you fit in the process — did you feel like a bottleneck at all? Ever worry that you would only have a couple of hours at the end to implement everyone else’s ideas?
We didn’t follow a waterfall process. We spent the first 1-2 hours gathering requirements from the client and deciding on a wireframe for the web site. On the front-end side, all I had to do was communicate with David on the HTML structure, and take care of the CSS.
There were a lot of things that I could do and contribute to in order to achieve 80% of the required functionality, so that towards the end I was just implementing the details.
SP: What tools did you use in your development environment, given that you only had 24 hours? Source control? IDE? Were you able to utilize any kind of testing suite? Database migrations? Did you use any other tools to catch any bugs that might slip in when you’re sleep deprived and the lines of code start blurring into one?
I was using TextMate on a Mac. We didn’t use a source control system — I think the risk in a competition like this was more about hard disk failure or accidental deletion of files. To mitigate this risk, we set up a personal environment on our own PCs as well as a shared environment on a shared drive. The shared drive was like our UAT (User Acceptance Testing) environment, and we took backups of that drive and uploaded them to the live system from time to time.
Some other tools we used were Firebug and the Firefox Web Developer Toolbar. We also used the W3C’s HTML validator and some web accessibility testing sites.
SP: What might you have done differently if you were in the competition again?
One thing I would have done differently would be to learn a lot more about Drupal beforehand. I had only used it 3-4 years ago, and only on a small project. So I had a lot to learn on the day!
Mark Rickerby (CodeBlacks)
SitePoint: As the team’s programmer, what preparation did you do leading up to the event?
I had a few weeks of advance warning, and naturally assumed I would immerse myself in practice and preparation — but I suddenly realized, a few days out from the contest, that I’d done next to nothing!
The most important thing to do was to speak to the others in the team, to get a feel for how they worked and how we could collaborate. My individual preparation consisted of putting together a framework of PHP code that I’d pulled from previous projects. I went through all the classes, added unit tests, cleaned up some of the naming conventions, and filled in gaps. It was nowhere near as complete as I would have liked, but since I wrote it myself, it was easier for me to read and comprehend than other random open source code would have been.
SP: You guys opted for a bespoke system, while the Aussies used Drupal. What benefits resulted from your decision? How do you think it limited you? And at what point did you think “Uh oh, I’ve bitten off more than I can chew?”
I think it’s probably fair to contrast the benefits to me personally, with the resulting benefits for the team and client. I think that the main benefit for the overall site was in terms of being able to develop a simple and clean architecture — we never had to re-interpret the design or data model of the site in terms of trying to fit it into a mis-matched structure, so we had a huge degree of freedom. As a result, most of our process ended up being focussed on the design, which was our original intention.
The main benefit for me personally was really just that I ended up fighting myself and nobody else. Not having to wrestle with unfamiliar or annoying third-party code is something I definitely value personally, but that’s not to say that it’s the best way to do things.
I think the bespoke platform limited us in the sense that it required a less agile process — I spent a lot of time working on the overall architecture and the back end of the site rather than enabling individual features one by one, so we didn’t have content streaming in to the pages or testable URLs ready until very late in the piece. But that was partly my fault for making some silly coding mistakes along the way, and not necessarily due to our decision to use a custom CMS (which, in fact, took me less than an hour to design). Either way, we would have had to wait until the content was written and the CSS/HTML was built before we could implement anything, and that was a fairly large chunk of time that I could use. (I just had to use it wisely — I’m still not convinced that I did!)
I don’t think I had the sense of biting off more than I could chew until about 6am when I realized that I only had an hour to go and there were so many things that still weren’t working. Maybe I was deluded up until then? All those little things are deceptively complicated. You know it will only take 10-20 minutes to code an extra feature, but once you factor in conversations with the team, testing, accidents along the way, more than an hour may have gone by.
However, I have seen fewer results come out of 80-hour projects with much larger budgets, so I’m reasonably happy with the final product. I do feel like I’ve only just scratched the surface of what is possible in 24 hours though.
SP: Where did you fit in the process — did you feel like a bottleneck at all? Ever worry that you would only have a couple of hours at the end to implement everyone else’s ideas?
I had to be aware of everything that everyone was working on, so I could put it all together in the right order.
As far as planning goes, I worked from a rough idea of where I wanted to be by 11pm or midnight, and unfortunately didn’t get that far, so the last few hours became a mad scramble. I knew that I could build most of the front end in 1 to 3 hours if it came down to it, so it was just a matter of whether I could realize the more complicated aspects of the design (such as user subscriptions and a content managed shared tagging model). By about 3am, I had to ditch some of these features, and focus on the basics.
It would have been nice to have two of me — one to fix bugs and respond to feedback from the team, and the other to be charging ahead implementing new stuff. I was secretly jealous of Rex, Dave, and Jeff, because they seemed to be swapping and sharing a lot of the responsibilities and solving technical problems as a group. With our team, the separation was a lot more defined. Although Thomas is an old-school Perl hacker and tech savvy, he had his hands full the whole time, and we didn’t really have the overall ability to delegate technical tasks or bug fixing. It really did fall on my shoulders.
For most of the time, I couldn’t afford to worry about anything except concrete things relating to the design. It really did feel like a sports contest in terms of this attitude — we were all just working as hard as we could. The good thing about our team was that, despite the relatively strict separation of roles, we all had a really strong design and usability focus, so we were all able to contribute constructively to the conceptual side of things. Sometimes, to take a break from my coding, I would walk around the room and give the design guys feedback on what they were doing, ask questions, and keep the conversation flowing. I was lucky to have an opportunity to work with such talented and fun people, and relieved that they totally trusted my technical judgment. Unfortunately because of the nature of having to make it all work in code, I did have more power over the overall outcome than I would have liked. I’d hate to think I was a bottleneck though — I’d much rather think that the others had ideas that were just far too ambitious to work in 24 hours!
SP: What tools did you use in your development environment, given that you only had 24 hours? Source control? IDE? Were you able to utilize any kind of testing suite? Database migrations? Did you use any other tools to catch any bugs that might slip in when you’re sleep deprived and the lines of code start blurring into one?
I wanted to use SVN, but it was unclear how to manage this with the rest of the team who were using a variety of different operating systems and IDEs. We had some hair-raising moments near the end when file timestamps started to swim before my eyes and were seemingly moving in the opposite direction to the usual flow of past and future! And a couple of accidental file overwrites of HTML templates meant fixing the same bugs twice. That was scary.
I originally had a devious plan to use ActiveRecord outside Rails and take advantage of the Ruby migrations capability, but ended up doing it all in PHP — effectively it was the same functionality, but without the explicit “up/down” versioning. This was immensely productive and meant
that I could make various evolutionary changes to the database schema over the course of the day as Zef refined the information model. Ripping off Damian Conway and David Heinemeier Hansson’s ideas about string pluralization in my framework code was of great benefit, too.
I did set up a unit testing structure at the beginning of the day — but only ended up writing a handful of assertions to test the Apache/PHP environment. Unfortunately, some of the problems I was running into were probably not going to be helped by unit testing: things like typos that weren’t parse errors, calling the wrong method by accident — Programming 101, idiot stuff. Hard things to track down, though. You think that if you’ve done something in just two or three lines of code, nothing could go wrong, but in reality, nothing could be further from the truth. I wasted much more time on these issues than actual technical and design problems, which really disappointed me. I fixed up some of this code in the weeks following the competition, and was amazed at how trivial these bugs were — and how quick to fix — but how impossible it was to see them at the time!
I wish there were tools that could protect us against sleep-deprived blunders. Unit testing involves a cognitive load that might be a little too high for these kinds of situations. I can’t think of anything that would have helped more, besides not writing the code in the first place (the only sure way to avoid bugs).
SP: What might you have done differently if you were in the competition again?
That’s a tough question, because I think that so much of the way I approached the project was determined by the client goals and needs. The whole experience could be completely different depending on which charity we were working for, so who knows what would be best for future situations?
The main thing would probably be to try writing code in a slower and calmer state, hopefully avoiding the accidental typos. And definitely use version control. I would also try and get a working prototype up and running in 6 hours or less, rather than waiting till the middle of the night to drop the complete site infrastructure. Also, most importantly, I would try and focus more on the cameras and audience, and put on a much better show for them! Unfortunately I was head-down most of the time, and couldn’t really delve into the antics as much as I wanted to.
If you’re interested in hearing from others involved in the FullCodePress competition, read my interview with the FullCodePress designers and the project managers.
Matthew MagainMatthew Magain is a UX designer with over 15 years of experience creating exceptional digital experiences for companies such as IBM, Australia Post, and sitepoint.com. He is currently the Chief Doodler at Sketch Group, Co-founder of UX Mastery, and recently co-authored Everyday UX, an inspiring collection of interviews with some of the best UX Designers in the world. Matthew is also the creator of Charlie Weatherburn and the Flying Machine.
