Resume Details:

8/2000 - 4/2001: wine.com, San Francisco, CA:

Hired into WineShopper.com (WS) as server engineering manager reporting to director for all front end web software development.

The WS website was used to sell wine to private citizens (as well as educate them on wine and the wine industry), although we were getting into selling directly to certain businesses toward the end. At the time I started the site was generating revenue but still in a ramp up mode, adding new states (2-6) each month. Each new state required special Java and JDBC programming to accomodate legal restrictions regarding licquor sales in that state. We also added new features to the site and made corrections to improve usability. The site was modified each month so all projects during this period were 6 week to 2 month projects (including requirements definition, design/functional docs, coding, testing, integration, smoke test and release) with several projects running in parallel. The team size varied from 4 to 7 during this period.

WineShopper used ATG's Dynamo v4.1 Application Server and the Netscape web server for infrastructure. The website "frontend" was architected as a three tier application, Content (HTML), business Logic (JAVA/JDBC) and Data Base (Oracle 8). The server engineers that I managed did all of the Java and JDBC development. JHTML (proprietary ATG elements) was used to integrate access to the Java classes in the HTML. They documented, designed and programmed in Java and JDBC to supply dynamic content to the WineShopper web site. I reviewd all docs and designs and some code as necessary and guided the design of some of the more difficult projects.

Content (images, HTML) was changed on a weekly basis and necessary Java changes could be done if they were small with one day turnaround.

There was a "back end" that was tightly integrated into the WS "frontend" via Java/JDBC deposits of orders and other "changes" to the back end data base. This architecture has certain complications that spawned a long term "new site" project to reduce those complications. The complications of the current architecture included the fact that daytime activity on the front end can be impacted by the "availability" of the back end data base (outages and performance issues are the obvious ones). Another is that anytime we wanted to change something inthe order processing we had to either be restricted by the back end design or change the back end as well. The "new site" project was something that all of the technology department (to varying degrees) participated in and is described below.

WS/wine.com Merger:

In late October WS and wine.com merged and server engineering inherited 4 more java engineers from wine.com to continue maintaining their site as well. We operated at two sites for several months, although the work emphasis shifted to the wine.com site almost immediately. wine.com was generating over 100 times more revenue and it was several times more feature rich than the WS site with a customer base of about 400,000 names. It was also 4 years old and based on older web technology (Jserver and Apache - using JSP to integrate Java and HTML). One bright spot was that the data base was based on Oracle.

Taking over the wine.com server engineering was a project in integrating two teams of java engineers, maintaining two seperate code bases based on two different web apps and web servers. Because all but one of the inherited wine.com engineers were short term contract employees my first concern was to get the engineer base cross trained so that we had backup knowledge in the wine.com application. All wine.com projects had at least two engineers assigned (with at least one from WS) and a WS engineer was made responsible. About a dozen new features were implemented on the wine.com site during late October and November. Changes to the WS site were stopped, except for mandated legal changes and bug fixes. Development was focused on keeping the wine.com site running during the holiday season starting in December. During this period all of the former WS engineers became proficient on the new site.

Dealing with the 2000 Christmas retail season:

There was reason to believe that the hardware and software architecture available for the wine.com website would not support a reasonable response time during the peak periods of the coming Christmas retail season. So a series of projects were started to determine where we could improve the performance of the site. The main focus ended up on the data base and making sure the web server hardware was functioning properly. Server engineering was involved in some of the significant data base access changes. For instance we had to change the JDBC/SQL queries to avoid using a piece of Oracle that was broken from a performance perspective and we rewrote some of the data capture/display code so that it stopped over utilizing the data base as a source of current data. Due to the changes we didn't have to change the already existing hardware setup that was inherited from wine.com.

In general the wine.com site did very well during this season, managing to support 3 times the revenue generation of the past years season. We had to do some fixes but generally the staff took this opportunity to take vacation and come up to speed on some of the new web technology that we were investigating for the new architecture.

The "new site" project:

Based on the analysis of the wine.com web site for the Christmas season it was determined that the current wine.com website was going to be inadequate to support another 3x growth planned for the next year. So the "new site" project was reinstituted with basically the same goals as before plus performance/growth goals. A special group was spun off and put under the direction of another director to focus on the nuts and bolts of defining the architecture and technology for the new site. As this new site was defined I encouraged my engineers and the new site engineers and management to share information so that the server engineers could come up to speed on the new technology to be used and the architecture. The new site architecture substituted a JMS based messaging system with common (frontend/backend) services to serve as the interface between the front and back end. The JMS server technology would provide a queueing technology on the back of the front end and the front of the back end to insulate those sites from each other (if the back end was down the front could still work properly and vice versa).

A significant wrinkle that showed up with the wine.com merger was the inclusion of a content "management" system requirement in the "frontend" web site. wine.com management had decided on a package that would require significant customization to work for wine.com so the choice was revisited by the WS technology team. Although we had an "architecture" and knew that we would need to use XML (which half of my staff had come up to speed on) the final design/technology decision wasn't completed before wine.com lost it's venture capital funding and had to close it's doors.

My Responsibilities while at WS/wine.com:

Typical administration duties:

• Hire/fire/performance reviews/provide constructive feedback
• Encourage effort and growth of engineers
• Make project asssignments
• Review and make regular status reports
• Continue to improve technical/management skills

Deliver projects on time with quality:

• Validate requirements meet business needs and adequately define what's needed
• Provide task breakdown with resources defined and timing
• Adjust other assignments to meet project priorities
• Assess and report progress and effort being applied to project
• Make sure the necessary level of effort is applied to meet the feature, quality and time requirements
• Keep Project management, Quality Assurance and other software development management informed of progress
• Assure proper software development processes are followed

Ensure good Software development process for all projects that require Java programming;

• Enforce process steps, requirements, specs, design, code, test, maintenance
• Work with product/project managers to document requirements for projects and guestimate implementation times/dates, work up any tradeoffs and risk definitions.
• Guide Software engineers in requirements definition and good design solutions,
• Draw up planning docs (MS Project, Excel etc.), work with engineers to validate task times and resources,
• Review/contribute to engineering response and design documents (Func Specs and Java Doc),
• Work with engineers on resolving difficult implementation problems, providing liason with project mgmt if requirements need to be reset,
• Review Unit Test Plan and observe execution of unit tests with engineer(s) prior to integration
• Review integration plan and observe integration testing with engineers prior to hand off to QA

Participate in improving the health and effectiveness of the technology department

• Investigate new technologies for use in the new site
• Get engineers trained in new technologies as they become "viable" for consideration
• Participate in architecture/technology discussions with architecture group
• Work with project management to understand future application projects
• Work with Back end, release management, content management and QA engineering groups to improve working relationships and interfaces

Technologies used:

• Typical Microsoft Office suite, plus MS project
• Borlands JBuilder Pro v4
• ATG's Dynamo 4.1 basic Application Server, JHTML, Java and JDBC (Sun OS and Windos versions)
• Netscape web server
• Apache web server with Jserve (JSP, Java and JDBC)