2.0 Management of Software Engineers
This chapter highlights people management issues in software organizations, along with
individual productivity. Together, these factors can account for wide divergences from
one organization to the next, and explain why some software firms become superstars
while some others languish on the wayside, or fail to make the grade.
Software code has to be logical, and thus software engineers can be perceived to be left
brained persons. However, a typical software engineer has to be somewhat creative in
addition to being very logical. In my experience, for an average software engineer, these
right (or creative side of the brain) and left-brain (or logical side of the brain) activities
consume 25% and 75% of the time, respectively, With GUI interfaces coming up in the
last 2 decades vis-à-vis the mainframe green screens of the past, UI design is more
creative than before, and software engineers play a role in defining UIs. Further, they also
use the right-brain activities while devising creative ways to use software design patterns,
for example. So, even though coding is predominantly writing if --- else statements, and
completing do --- while loops for which logical thinking is a necessity, software
engineering has its creative elements.
The above aspects of software engineering, coupled with the fact that logical thinking
depends primarily on experience as well as raw brainpower, makes the productivity differ
widely from one software engineer to next. Consequently, software engineers are widely
differing and diverse in their level of productivity. As far back as 1968, Sackman et al.
documented this productivity difference amongst software programmers. Sackman
reported productivity ratios of up to 28:1 for programming / coding / debugging.
This old empirical study aside, I have seen, based on my experience on multiple software
development projects, that output ratios of 1:3 exist in a typical software project, where
all the team members are supposed to be equally competent. If you couple this with the
factor of 2 for taking into account well trained / educated and highly experience engineers
vs. new-bees trying to get their toes wet in the formidable art and science of software
development, assumption of software engineering productivity ratio of 1:6 is a good
starting point.
The second factor in software engineering management, which is as more important than
individual productivity, is the group, or department productivity. This is a factor of
morale, motivation, and incentives given to the rank and file engineers and their
immediate team leads / project leads. In my experience, I have seen brilliant engineers
working only four hours a day (a decrease in productivity by a factor of 2), and wasting
the other four hours, because the upper management was incapable of instilling morale
and motivating the engineers. Further, compared to an environment where even the
junior most engineers are treated with courtesy and respect, an environment where the VP
œ Engineering does not understand the difference between iterative development vis-à-vis
