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.
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.
|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)|
|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)
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:
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.
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.
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:
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.
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:
© Copyright 2000 Scott Hofmann. All Rights Reserved. Distribution of this document unedited in it's entirety is encouraged.