Who am I

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 styles.

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 time.

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 own rank.

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 estimates.

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 CoCoMo), 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.


Post a Comment:
Comments are closed for this entry.

Bob Hueston


« July 2016