Development
The technology and development weren't often an issue or challenge. It almost always was more about time and priorities; out of the 75 things product development wanted done, what could be done and/or bundled in the next production release? Production releases are now twice a month (though it used to be every week, which was tedious and unnecessary).
The application is a portal type of technology. PTG runs almost 30 web sites off of one piece of application code. Each site has its own images, CSS, and one XSLT file to define how it works, looks, and acts. Outside of those specific needs, all the sites share the same code base from front end to back end. No other site-specific files or logic are used, thus keeping the code size and complexity to a bare minimum. For Exam Cram and several other sites, only a couple of hours on the part of up to three developers were needed to get the site live.
The sites use a multi-tiered approach to the software infrastructure:
The SQL Server database back end uses stored procedures in abundance to perform all data retrieval, updates, inserts, and deletes.
A couple of Microsoft C# middle layers make calls to SQL Server for data interaction in one layer; the other layer is used for transforming of data (XML) and most of the business logic.
The interface layers consist of very brief Active Server Pages (ASP) used to identify objects, along with XSLTand nothing more. The XSLT is used for formatting XML data that's pulled out, and some interface-level business logic (such as whether to show a "buy" button for a product, depending on the status of the product). CSS is used for site formatting to handle color schemes, fonts, and so forth.
The developers use Microsoft Visual Interdev .NET for writing C# code and debugging the application. They also use SQL Query Analyzer and various text editors for stored procedures and XSLT.
One of the biggest challenges, says the development team's Andy Hall, was "'Scope creep' during prototyping and sometimes during development. Sometimes new functionality or changed functionality that is voiced early on results in long prototyping cycleshave to watch it or it becomes analysis paralysis.
"Another area where problems sometimes occur after the VSD is written and passed along to each team is when product development requests changes during prototyping and communicates them to human factors and development, but not to QA — who writes up a lot of bugs that...aren't."
Managing the team and project is a big challenge with any large redesign effort. Hall comments, "Management for my team (development/operations) was mostly working out roles and responsibilities of certain major areas of functionality such as search, navigation, product pages, promotional pages, basic XML data transformation infrastructure, core/common object development, etc. We had regular meetings (once or twice a week) to work out some larger problems and/or make architecture-level decisions."