Pick The Right Solution mapobject.com Articles/Products Contact About Us

Personnel Strategy for producing Enterprise Web Applications

Introduction

The success of any enterprise application development effort is highly dependant on the quality of the members of the development team and the structure in which operations take place. Failure occurs in these types of efforts when leadership fails or unqualified individuals given more responsibility then they are entitled.

There are volumes on management structures that cannot be mimicked with any shred of credibility. This document does make a recommendation for a structure that works well and adheres to many management styles that are documented in some academic texts.

There does appear to be some ambiguity of understanding on quantifying a qualified developer. Quite often, an individual's ability to represent themselves as having a particular level of expertise has a greater impact on the hiring process then the actual qualifications of the individual.

This document attempts to address the issues of developers and management efforts by offering a framework in which to build a team of developers for producing an enterprise web application. This framework is based on the experience gained from many efforts to build complex web sites (while working at SoftAd) using a team of developers.

Individual Developer

A developer's strength can be measured by the maximum number they can achieve on SEWDS (rhymes with 'toads' - pronounced 'so - ds' as in 'sew' and 'ds' concatenated) - Strength and Expertise Web Developer Scale. SEWDS ignores some strengths and trivializes the description of one's ability to a certain extent by it's simplicity. It is meant to be an accumulative scale however and a means of comparison for garnering a qualitative scale of measure among developers.

The scale assumes that a developer can do anything on the list at or below the grade level with a high degree of competency. In other words, a level 8 could very likely provide a scripted solution with a high degree of competency based on their expertise in writing compiled code even if they have not written many scripted solutions.

SEWDS - Strength and Expertise Web Developer Scale

1 Experience and understanding producing markup tag data such as HTML
2 Experience and understanding producing markup tag data that may be used by an automated solution
3 Experience and understanding producing macros to facilitate an automated solution (MS Word, MS Excel)
4 Experience writing client oriented solutions using a scripting language (JavaScript in web browser)
5 Experience writing server oriented solutions using a scripting language (PHP, ASP, JSP)
6 Experience writing solutions using scripting languages (Anything from ASP to DOS batch files to Shell Scripts)
7 Experience writing a compiled solution in an IDE(integrated development environment) without any architectural considerations (Quick and dirty VB Executable)
8 Experience writing a compiled solution in an IDE with architectural considerations such as a COM component, DLL, Applet, or Control.
9 Experience writing compiled solutions that perform activities that are considered beyond the reasonable capability of the language or outside of an IDE.
10 Experience writing a compiled solution in a second language in an IDE without any architectural considerations (Quick and dirty)
11 Experience writing a compiled solution in 2 languages in an IDE with architectural considerations such as a COM component, DLL, Applet, or Control.
12 Experience writing compiled solutions in 2 languages that perform activities that are considered beyond the reasonable capability of each respective language or outside of an IDE.

8 + ( 1 for each language version duplication of 9, 10, 11, or 12)

For example:
A developer 2 years out of college with ASP and Javascript web development expertise would be a 5-6.
A developer with 12 years C, 5 years C++, 1 year JAVA would be ~8 + 2 + 2 = 14 (maybe more).

Development Teams

During the course of the efforts that were being utilized to deploy ChannelNet, a team structure was adopted. This team structure was created for the purpose of enabling a mechanism whereby senior level developers would oversee development of discrete programmatic efforts. Discrete programmatic efforts might entail building a ChannelNet BO, writing a static DLL, setting up a server correctly, or any tasks that requires a significant amount of effort as it relates to offering some amount of programmatic automation effort.

A team would be made up of at least 3 developers with the following roles:

  1. User Interface (UI) developer,
  2. Object developer, and
  3. Team Leader.

Only one team leader exists per team. There may be multiple Object developers or UI developers. Generally, there should always be more UI developers then Object developers. The UI developers can usually finish their tasks faster then the Object developers but they can learn to develop object code modules and perform other ancillary tasks when they are not producing UI scripts.

UI Developer

The UI developer is generally someone who should be used to developing scripted solutions using VBScript, JavaScript, XSL, or PHP. A UI developer will generally be a Level 5 on SEWDS.

Object developer

The Object developer must be someone who is experienced writing code components in VB, JAVA or C++ and they must understand how a ChannelNet BO is constructed. An Object developer will generally be someone who is at a level of 8 on SEWDS.

Team Leader

The team leader must be an individual who is motivated and a self-starter. They should not require a great deal of direction or instruction for completing any given task. They should also be someone who is respected and recognized by fellow coworkers as a leader and strong contributor. A Team Leader will generally be a Level 10 on SEWDS.

Team Leaders will have the following responsibilities to the managing entity of a given effort:

  1. act as central point of contact for determining status,
  2. mentor developers on team,
  3. assign individuals on team specific tasks,
  4. enforce programming policies set forth by DM,
  5. enforce system architecture constraints set forth by System Architect or DM.
  6. Estimate time required for producing discrete programmatic efforts.

Enforcement as cited in 4 and 5 entails learning the policies and teaching/explaining policies to team members. Issues that might arise as it relates to insubordination of lack of adherence to policies will be addressed by the DM. The Team Leaders will always have the support of the development manager (except in cases of the Team Leader being wrong) but the development manager will address all personnel issues. The level of oversight in this issue between Team Leaders and development managers is not well defined because it can vary based on the desired role a Team Leaders may pursue and the amount of individual latitude the development manager may offer them in which to operate.

Each respective team leader generally writes code. They are also charged with performing other types of efforts that facilitate the end goal of completing modules of functionality.

Career Path

The typical career path for developers is to move from UI developer to an architect or management.

Team Leaders are charged with challenging the UI developers to become Object developers by teaching and assigning duties that stress the limits of the developers on their teams. This effort serves to build a stronger development team for SoftAd and it challenges the UI developers to become Object programmers.

The career path for a developer is the following:

  1. UI developer
  2. Object developer
  3. Team Leader
  4. Senior System Architect or Management
mapobject.com Articles/Products Contact About Us Pick The Right Solution

Send mail to scott@mapobject.com with questions or comments about anything.
Last modified: 26 September 2000

Copyright 2000 Scott Hofmann. All Rights Reserved. Distribution of this document unedited in it's entirety is encouraged.