Brian Bailey Preface to the Revised Edition

From the Inbox

I've received a number of emails this week filled with great questions. I thought I'd answer two here that may be of interest to others.

1. How is a web team at a large church like Fellowship structured? Do you have a content production pipeline or do you have a more distributed approach (i.e. Open Source methodology) with people from each area contributing?

This is by far the most common question we receive because so many churches, including Fellowship, struggle with it. At Fellowship, we have a communications/graphics department that is responsible for all print materials (bulletins, signage, brochures, direct mail, and more). This team is completely separate from the web team. I would estimate that half of the graphics you see on FellowshipChurch.com are based on images and logos created by the graphics department. The content side is more a story of thirds; one-third from communications, one-third from ministries, and one-third from the web team.

Currently, all requests for website changes or additions come to me and I distribute them to the team. We have reached the point, however, where that system is no longer sustainable. With four sites and four campuses, there is simply too much content for my group to manage. More importantly, I can't have my primary graphics person spending a majority of his time on text.

So, as part of our new site and platform, we are building a content management system to turn over much of the site content to our staff. The content will have an approval process, but the primary responsibility will be in the hands of the people on the front lines of ministry.

2. Can you clarify what aspects of ASP.NET you found more complex than PHP and which tended to bog down development?

ASP.NET takes the desktop, event-driven model of development to the web, which in my opinion brings a lot of unneeded complexity. The best example of this is DLL-centered deployment. Any code behind that is added or changed (all code apart from presentation, including data access and business logic) requires an entirely new DLL to be deployed, even if only one file was changed. The DLL contains the code behind for the entire site, so it's a challenge to develop individual modules without running the risk of impacting the rest of the site.

With the caveat that the best developers on any platform can accomplish great things, our team has already been blown away with the simple, elegant approach of our new direction.