Mike King
Newark, CA 94560 HireMikeNow@hotmail.com
Objective: Software Development and/or QA management position.
Extended Resume Information
Hired into WineShopper.com as server engineering manager reporting to director for all front-end web software development.
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 database (outages and performance issues are the obvious ones). Another is that anytime we wanted to change something in the 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.
Wineshopper.com / 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 database was based on Oracle.
Taking over the wine.com server engineering was a project in integrating two teams of java engineers, maintaining two separate 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 database 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 re-instituted 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 its venture capital funding and had to close it's doors.
My Responsibilities while at Wineshopper.com / Wine.com:
Typical administration duties:
- hire/fire/performance reviews/provide constructive feedback
- Encourage effort and growth of engineers
- Make project assignments
- review and make regular status reports
- continue to improve technical/management skills
Make sure project can be and is delivered 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 “guesstimate” 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 liaison 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
Hired into Legato as Serverless Backup/Restore Software engineering manager reporting to director for all "serverless" backup and restore software development.
The basic data transfer technology depended on an initial analysis of the "location" of transferable data block by Legato analysis software in the application server that understood the data base and the application that "owned" the data. This information along with the backup choices was supplied to the backup device which then proceeded to move the data to the tape device. There were two basic configurations that make this possible, in the non-SAN, original configuration the backup server is attached
through a second port to the data devices that the application server is using. The backup server can access the data devices at the same time as the app server and moves data to an attached tape device. The SAN
configuration has all disk and tape devices attached to the fiberoptic/copper SAN via smart switches that can be told to move data between the disk and tape devices. These smart switches generally use a standard communications protocol for commands necessary to retrieve and store date on the attached data devices. The switches were controlled from Legato supplied software on the App server.
My group was responsible for implementing the basic data transfer software technology for these "serverless" solutions. The team grew over the few months from 4 to 7 engineers. They worked on Sun Workstation using a generic (GNU) C compiler using a very vanilla set of C instructions that generally compiled across a wide range of hardware and software platforms. OS"s supported included Windows variants and UNIX variants (across many hardware platforms). The projects we worked on took generally 4 to 6 months and went through a very rigorous software development process including a significant QA regression test.
Legato's "integration" process included a nightly build of the complete product line, including any new code committed to the code base during the day. They had a significant build watch process in place to "correct" mistakes in the code base in a timely fashion. They also had a source control architecture to allow more than 100 engineers to work on the same code base in a variety of different areas (new features, OS support, App support, bug fixes...) from a variety of labs in 3 countries. The coordination effort was significant and very important. Members of the team had visibility to some of the original Legato founders (both for doing things right and wrong) due to the level of coordination necessary.
The team's job (and my responsibility) at Legato was to deliver the SAN project on time and to address any feature changes or bug fixes in the currently released product. There were 3 senior engineers and several
junior engineers on the staff.
My Responsibilities while at Legato:
Typical administration duties:
- hire/fire/performance reviews/provide constructive feedback
- Encourage effort and growth of engineers
- Make project assignments
- review and make regular status reports
- continue to improve technical/management skills
- work with India based technology team to coordinate maintenance and handoff
- Acquire assets (software and hardware) needed for software development
Make sure project can be and is delivered 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 guesstimate 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,
- Work with engineers on resolving difficult implementation problems, providing liaison 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
- Get engineers trained in new technologies as they become "viable" for consideration
- Participate in design/technology discussions with design teams
- Work with project management to understand future application projects
- Work with other Dev Labs, release management, Project management and QA engineering groups to improve working relationships and interfaces
1996 - 1999: Compaq - Tandem Division
Assigned to manage Software development teams to do a strategic Windows NT Operations Management (OM) application port + enhancements and implement a Clustered systems Operations Management Web Application. The port evolved over 2 years and was terminated due to a takeover of Tandem by Compaq in
1997. In 1998 the team was requested to implement an NT Cluster management feature using Java applets and servlets on top of Compaq's in flight implementation of WBEM (Web Based Enterprise Management, more about this later). This was successfully completed before I left Compaq in 1999.
NEC ESMPRO Port Project:
The Port project was based on an "English" version of NEC's ESMPRO operations management tool for Windows NT management. NEC had converted much of the Japanese language to English and worked with Tandem to finish the project and resell the product to Tandem's NT customers. We also added real-time support management and bullet proofed the code and language translation. It required that we come up to speed on the ESMPRO architecture, design and code details in much of the code base and
construct a build process that we could trust and hand over to release control and QA.
This project started with "negotiations" with the NEC software development management in charge of ESMPRO. I did the technical negotiations to establish what we would do, what team communications interfaces we would use, what support we would get at the development level and at the customer level, and how we would transfer software back and forth. As soon as it became clear that we were going to do this project I put together a development team and we started figuring out how we were going to do it.
We had 3 major Project objectives: 1) add some features, 2) construct a supportable process for maintaining this product (this was the Tandem divisions first significant NT based product), 3) successfully train and hand over external support of this product to Tandem's support organization. The development environment was based on Microsoft's Visual C++ package. Tandem's standard software development process was used (typical documentation, reviews, development and test) with the added wrinkle of NEC supplying source updates every once in a while that were to be used as base to any new features we were adding. We reciprocated, sending back our enhancements, fixes and language corrections. The project took a year and we developed a good relationship with the NEC software designers - a team from NEC came out periodically to Cupertino to work with us and build a support relationship.
Interesting technology; We created a message monitoring feature for ESMPRO that would dial out to the Tandem support organization immediately and transfer a block of information based on the Windows message intercepted. The support org could then use a standard Windows NT "dialin" path to get
access to the NT system that was having a problem. The details of this implementation include an updateable Urgent message table that could be installed periodically from a central location via dialup or from a central location in the NT network being monitored. We took some of the lessons we had learned from building a very robust message management environment in the Tandem Proprietary OS and applied them to this implementation such as queueing of the messages locally for forwarding to a central monitoring location and compression of information to be logged at the central site.
WBEM based NT Cluster Management App:
Compaq requested the Tandem division to implement a web based NT cluster management application based on Compaq's WBEM platform. The WBEM standard had been developed through an agreement between Compaq, Intel, Cisco and Microsoft to make it easier for small device vendors to provide robust
management tools for their devices attached to a network. WBEM provided services (such as a general data base, SNMP access and a display console) that allowed the device vendors to focus on their device specific management functionality. The NT Cluster management app was going to be one of the first device management apps made available to Compaq customers. This application was initially to monitor, signal and clarify unhealthy conditions for Compaq PCs clustered together using Microsoft’s Cluster
Server software. We added recommendation functionality as well (if this is the problem then try this to fix it). The application was built in two components, a browser based Java Applet and a Server based Java applet integrated into the WBEM infrastructure. The application was built simultaneously with the development of the WBEM software and depended strongly on the WBEM development timings and documentation. There were several WBEM/Cluster OM app team meetings and close cooperation between the Houston based WBEM designers and the Cupertino based Java application designers. We received several copies of the WBEM software before our application was completed.
During this period we also designed and implemented a software driver for Tandem proprietary MSCS cluster systems that cross-monitored power, availability and temperature tolerance variables inside the clustered systems cabinet. This driver provided data to the web application that was displayed (if this was one of Tandem's special systems) in the application as additional information.
Technology:
We used Jbuilder Pro 3.5 (and library), Sun's Java Swing package and proprietary Java technology from Compaq (via WBEM)to implement this innovative application. We used SNMP to communicate with the cluster health monitors. We used the WBEM based database to save off OM data and share it with other applications (should they need it) and the WBEM based initialization/termination facility to initialize and terminate the application. Documentation on the app can be found on the web at: http://www.compaq.com/solutions/enterprise/highavailability-clustermgmt.html. Documentation on WBEM as implemented at Compaq (Compaq Insight Manager XE) can be found at http://www.compaq.com/products/servers/management/cim-xe.html. Documentation on the WBEM Standard can be found at http://www.dmtf.org/standards/standard_wbem.php
My Responsibilities while at Compaq/Tandem:
Typical administration duties:
- hire/fire/performance reviews/provide constructive feedback
- Encourage effort and growth of engineers
- Make project assignments
- review and make regular status reports
- continue to improve technical/management skills
- Acquire assets (software and hardware) needed for software development
- provide periodic program reviews to upper management
Make sure project can be and is delivered 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 guesstimate 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,
- Work with engineers on resolving difficult implementation problems, providing liaison 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
- Get engineers trained in new technologies as they become "viable" for consideration
- Participate in design/technology discussions with design teams
- work with project management to understand future application projects
- Work with other Dev Labs, release management, Project management and QA engineering groups to improve working relationships and interfaces
1971 - 1978: Software Development for assorted companies:
CSC (Computer Sciences Corporation), at NASA - Greenbelt Maryland and Jet
Propulsion Laboratory - Cal Tech in Pasadena CA.
In college I took a computer class in my freshman year where I learned Algol. First job out of college I was assigned to work on telemetry data analysis for a particle tracking satellite at NASA in Greenbelt Maryland. CSC had a systems support contract with NASA and one of the projects was writing programs that analyzed the path and energy of particles based on spark chamber results in an orbiting satellite. I did minor batch algorithm development using Fortran and BAL (Basic Assembler Language) on an IBM 1140
and 360. I don't remember a whole lot of details but the job did entail design as well as coding, testing, debugging. I do remember, I taught myself how to code in BAL and Fortran.
In 1972 I was given the opportunity to do similar work in Pasadena CA at JPL (California Institute of Technology) again for CSC. This telemetry data was more secret and I was given algorithms to implement, which I did in BAl (Basic Assembler language) on another 360. This was a little more structured in process and the data was being analyzed in real time (so my code ran in real time).
In 1974 I went to work for TRW Data systems, Credit Division.
The department developed credit authorization software programs for retailers that ran on Data General Nova Minicomputers. The credit authorizations were real time transactions. I taught myself the language and the OS/file system which was NOVA assembler language and this system had a 32K memory store. My focus was implementing performance enhancements to allow more and faster transactions to go through the computer. For instance I implemented an indexing and buffering technique for the data base access that improved the data base throughput by 400%. The buffers were 256 bytes in size.
After a couple of years at TRW I found a position in San Francisco - 1978 - with Microform Data Systems. AT that time they were in the process of designing a strategic Directory assistance system with a disk based database on Tandem computers. Their cash cow up till then was microfiche based computer driven keystroke responsive directory assistance systems. They had a need residual business in organizing and photographing new batches of microfiche for their customers. I was brought in to write the batch utilities that generated reports from activity on the disk based system. I learned TAL (Tandem Application Language) at Tandem's corporate headquarters and wrote the utilities in TAL. To access the Microform
specific display terminals (Tandem didn't supply the right form factor) I also worked with another senior engineer to write a driver on the Tandem that could talk to (and display on) the Microform terminal. I wrote some additional utilities to upload microcode to this terminal to change character sets and other details as needed. This project was having problems meeting the response time being requested by the one and only customer and eventually was put on the shelf and I was laid off.
1979 - 1988 Tandem Computers Inc.:
I then went to work for Tandem Computers in October '79 as a trainer in performance analysis and tuning for Tandem customers. I had spent some significant time up to then rummaging around the Tandem OS code and improving the performance of non-Tandem systems. I took it upon myself to research performance analysis theory and understand the performance instrumentation embedded in the Tandem Operating System code. The Tandem code had been instrumented by an engineer named Russ Blake, who has subsequently gone on to Microsoft to instrument Windows NT. After perusing the OS code I was able to understand how the data was collected and what it meant with regards to resource consumption and queueing as transactions were processed in the Tandem system. Using the data collection/reporting
tool data as input I coded, in Tandem's proprietary scripting language (EXEC), several useful reports that massaged the data and presented it in more customer consume-able fashion. I used this set of reports to teach and later, with enhancements, to help customers analyze their own Tandem system performance issues.
In 1983 I moved out of education and into field support as a performance analysis expert. Over time I continued to massage this set of reports and as Tandem's OS instrumentation changed I would have to review the OS code and adjust the reports accordingly. Eventually other analysts took the code and created reports that could be "sold" to customers and used to sell services to improve the customer's system performance.
In 1988 I became a product manager for operations management products and worked closely with the key performance instrumentation and data collection designers inside Tandem to improve the product line.
In 1992 I joined the Development division as a program/project manager for a special OM project to integrate CA Unicenter into Tandem's OM product line.