The team that developed the Web site you’re enjoying today faced some stiff challenges along the way. An aggressive timeline was just the most obvious hurdle: Builder.com was developed, tested, and deployed in a little less than three months' time, all on the heels of another large project (Version 5 of our sister site, TechRepublic.com). Differences in cultures between the two teams that worked together provided a subtler but no less significant challenge as the development team worked on Builder.com, their first project for CNET Networks. I recently spoke with Doug Lane, the manager of CNET Louisville’s engineering team, to find out how they pulled it all off.
Builder: Can you briefly describe Builder.com's architecture?
Doug: Builder.com was developed from the code base used by TechRepublic. Both sites are built using server-side Java and Art Technology Group's proprietary dynamic JHTML pages, run on ATG's Dynamo application server, plus a major vendor's enterprise RDBMS that I won't give specifics on. Both sites are served by Apache running on Solaris servers.
B: How much work did you have to do to TechRepublic's code base to get it up to speed for use on Builder.com?
D: We had to tweak it a lot to handle the two different products and share pages between them. The UI was a very big deal: Our article page had to be heavily reengineered to handle the differences between TechRepublic and Builder.com.
B: What was the general timeline for Builder.com?
D: The functional specification was developed in the latter half of December, with development beginning in the first part of January and completing sometime in mid-February. QA started immediately after. Our beta launched February 23, and we officially launched the new site March 1. We worked a lot of nights and weekends.
B: Did you do anything special to keep morale up during this time?
D: Early on, the challenge was daunting, until people started building some momentum. I mostly just tried to stay calm and listen, although I'm sure my team thought I wasn't listening at times. You have to listen when someone tells you they can't get something done and has facts to back it up. If they're just venting or mouthing off, you still listen, but you keep moving forward. You can't go tell the business people we won't meet a deadline because someone just doesn't feel right about it.
Managing expectations and philosophy differences
B: That's not a lot of time. How did you manage expectations to make sure they were reasonable given your timeframe?
D: We didn't have much trouble there, since the business people were date-driven and understood from the beginning that features might have to be cut. We were fortunate that a key business driver had a background in engineering and knew the constraints of working in a compressed timeframe. That helped. Also, the developers had direct access to the business people, so that saved a lot of time that would normally be taken up by meetings or going through me.
B: TechRepublic is a fairly recent addition to CNET Networks, and this was your team's first big project working directly with CNET. There had to have been some differences of opinion about what works and what doesn't work for a Web site like Builder.com. How did you deal with that?
D: There certainly were philosophical differences. CNET traditionally publishes a lot of pages with relatively fewer opportunities for community interaction. TechRepublic, on the other hand, is the opposite—sharing and coupling components on its pages to provide more community interaction. Of course, the TechRepublic platform does not handle the same scale of traffic as CNET's. So there were times that they simply didn't understand why we did things the way we did. I found that explaining TechRepublic's evolution helped them to understand the "why."
B: Were there other differences?
D: Other than philosophical, QA was one of the bigger differences. TechRepublic's QA focuses on user acceptance testing more so than CNET's, which I believe looks at the code more. Of course, code that performs correctly should give a good user experience too. TechRepublic and CNET approach it from different angles with the same goal in mind.
With CNET's method of publishing static HTML, they can change the UI near the launch date without affecting QA. TechRepublic dynamically generates its pages as users navigate the site, since user feedback changes the appearance of the site. What may appear to be minor tweaks to the TechRepublic UI can easily cascade and cause more engineering and QA work than anticipated. Until someone explains it to you or you see it for yourself, it is difficult to envision another way of producing a Web site other than what you have known.
Keeping the stakeholders involved
B: When stakeholders aren't involved in a project, it usually fails. How did you get and keep the stakeholders involved in Builder.com?
D: If the stakeholders don't get involved from the beginning, expect trouble, because expectations between technology and business will not be congruent. In this case, they motivated themselves to get involved, so I really didn't have to.
That answer doesn't help you any, though, so here's what I'd suggest to avoid trouble:
- A formal kickoff meeting for a project helps define roles and responsibilities for everyone. Every project should have one of these.
- Communicate the project's status frequently (at least weekly) with the stakeholders. Don't make decisions for them. Prepare facts and ask them to make the decisions. Also, make clear the urgency of the decisions and how their vacillation may impact the schedule. After all, it's their project, so they should care.
- If you do feel the stakeholders are not engaged, then you need to tell your manager, so he or she can escalate it up the chain and have it come back down the chain to the stakeholders.