I graduated from Rensselaer Polytechnic Institute with a Bachelors in
Computer Systems Engineer. At the time, there was no such thing as software
engineering, and computer engineer was just emerging as its own discipline.
The Computer Systems Engineering degree was intended as a bridge between
Computer Science and Electrical Engineering -- it included programming
languages, compiler design, and operating systems, as well as analog and
digital circuit design.
Edison Engineering Program
At graduation I took a position in the Edison Engineering Program at
GE Aerospace. That was a great experience! It was a three-year program
of rotating job assignments and part-time study, culminating in a
Masters of Science degree. During the EEP I worked in jobs in Syracuse
and Boston, in Radar Systems and Aircraft Electronics, in CAD and Engineering
support, simulation and modeling of ICs and boards,
hardware test development for operations, hardware design, and software
development, giving me broad exposure to various areas within engineering,
and allowing me to work with different people with varying leadership
But I think I learned the most about leadership in my first year of the
Edison Engineer Program. Each week we would have a presentation by a
person highly skilled in a specific technology (from radar design to
writing software for attack submarines). Then the EEP class would split
up into groups of 4 or 5 to solve a problem. There was no "group leader",
but no group functions without a leader, and every week someone emerged
as the leader. Interestingly, the leadership role changed from week to
week, depending on the problem to be solved, and who had the motivation
that week. After spending some 10 to 20 hours (of unpaid time) working
in a group, we would agree on a solution and each person would do their
own write-up of the solution. The write-ups were typically 20 pages of
text, and were maticulously graded on technical accuracy as well as
spelling and grammar. As a result, you learned to write a 20 page technical
document which was extremely well written, in a very short period of
Grading was done by peers from other teams, and everyone know that
every nit you could find on someone else's paper pushed their grade down
and pushed your rank up, so the grading was fierce. The graders had one
week to review the papers, and they were responsible for presenting the
results the following week. The presentations had to cover the technical
aspect of the solution as well as the statistical analysis of the grades,
and the presentations were graded by the other EEP students in the audience.
The audience would often pepper the presenter with questions, hoping to
make the presenter look bad, to drive down their grade, and drive up their
With the number of people in the class, you ended up being a grader/presenter
once a month, and since your presentations were graded for technical
accuracy and quality of presentation, you learned to prepare and execute
presentations in a highly professional, technically accurate manner and
were prepared for almost any questions that migh arise.
In a few short years, the Edison Engineer Program turned me from a wide-eyed,
naive college grad into an experienced engineer with skills in:
- Working in, and leading, small groups of engineers,
- Negotiation skills,
- Technical problem solving,
- Writing high-quality technical documents, quickly, and
- Presentation skills.
I am surprised that every company doesn't have a similar training program.
Early Project Leadership Experience
While working in Aerospace, I led a number of hardware development projects,
mostly small projects, with two to four designers. I learned about hardware
planning, design, construction, design assurance testing, hardware
qualification, and the manufacturing and release process, not to mention
learning about product costs versus pricing, union relations, and
dealing with a supplier chain and lead times.
The last project I led in aerospace was a new microprocessor-based aircraft
monitoring system. The project team consisted of four electrical engineers
two mechanical engineers, and four software engineers for a two-year
development cycle . This was a large project for a small company, and very
large for a twenty-five year old.
The hardware development went well enough; although, EMI problems caused a
redesign late in the development cycle. But the software side of things
went miserably. The software development schedule was created by the
software manager, and quickly prooved to be inaccurate. In the end, it
took eight software engineers and three and a half years to produce a
functioning product -- costing more than three times the original software
How could hardware estimates and plans be wrong by 10%, while software
estimates and plans could be off by two or three times?
Hardware vs Software
In the process of leading both hardware and software projects, I realized
that hardware was treated as an
engineering discipline, with analysis and documented rationale for costs
and estimates; software was treated as an art, with maybe a high-level
bubble diagram and some hand waving. When it came right down to it, even
the software managers coming up with schedules and estimates had no clue
what the real costs would be; they typically divided the amount of time
before the product shipped into three three phases -- design, code and
test -- then sat back and watched what happened. Even after the design
phase took twice as long as planned, the software leaders would say, "Don't
worry! We spent more time in the design phase coming up with a detailed
design so the coding and test phases should be shorter." In fact, if the
design phase was twice the original plan, the code and test phases were
usually also twice their original plans.
I decided that what software needed was to apply engineering discipline
like hardware engineering; but software isn't hardware, and a new set of
"equivalent" engineering processes needed to be developed. When I
moved into the commercial sector, I moved completely into the software
area for the rest of my career.
How I Came To Sun
After aerospace, I worked for PictureTel, leading software projects
to enhance videoconferencing products, including new support for
T.120, H.221 HSD and other protocols. Then I worked for a short time at
Fujitsu Network Communications on the microcode for an ASIC in an ATM
switch, plus the high-level software for controlling the ASIC (which is
sort of funny since now I'm working on a project with Fujitsu). When
it was time to leave Fujitsu, a former co-worker at PicturelTel asked me
to interview at her new company, Sun.
I was skeptical about Sun -- a big company with proprietary hardware and
a proprietary Unix OS. But after a couple of interviews, and a peak at the
products Sun was developing, I was convinced this was the place for me.
During the last eight years at Sun I've led a wide range of software projects:
IO drivers, Java applications, embedded real-time software, Solaris and Linux,
on a wide range of hardware: SPARC, x86, and PPC, off-the-shelf and
custom-built hardware. Working for a large company like Sun has allowed me
to tackle a range of projects that no small company could ever offer.
Software as an Engineering Discipline
Since making the switch from hardware engineering to software engineer, I've been a
champion of appling
engineering principles to software estimation, planning, execution and
testing. The use of analytical estimation tools (such as
formal processes for plan develpoment and execution, and the use
of automated test harness (e.g.,
TETware) and analytical test devleopment methodologies (such
as Equivalence Class Partitioning (ECP) and Boundary Value Analysis
(BVA)) in unit testing are all hallmarks of my projects.
Over the last couple of decades, software as an engineering discipline has
evolved quite a bit. But there is still a long way to go.