From the Editor
IEEE Software, Vol. 15, No. 5, September/October 1998
Building the Community
In 1984, I began my first full-time
programming job as an analyst for a consulting firm with 5 employees. The
job paid well. We got free diet Pepsi. And I got to work on IBM PC projects,
which were a lot more interesting than the mainframe projects I’d been
working on in school.
The projects were much larger than my school projects,
lasting anywhere from a day to a month. I learned a set of skills that I
hadn’t learned in school. I learned to coordinate my work with others. I
learned to contend with a boss who constantly changed his mind about each
project’s requirements. And I learned to work with customers who depended on
the software and complained loudly if it didn’t work the way they needed it
to.
My second job was on a large mainframe aerospace project—a
stereotypical document-laden government project. The inefficiency was
astounding. I was convinced that 3 or 4 of the programmers from my old
company could have written in 3 months what this 30 person project team took
3 or 4 years to create. (I still think that’s probably true.) I didn’t like
this job very much, and by the time I left work each day, I happily stopped
thinking about computer programming.
Assignment: Fun, But Lonely
After the aerospace project, I went back to working in a
small company environment as the only programmer in the office. I began work
on an exciting year-long DOS shrink-wrap project in C that pushed the PC to
its limits. This project didn’t provide free diet Pepsi, but I was happy to
be working with microcomputers again. The only hitch was that the new
project had renewed my excitement for computer programming, and I couldn’t
find anyone who was as excited about computer programming as I was.
By this time I had been working full time in the industry
about 3 years and, aside from programming language and machine manuals, I
hadn’t yet read any programming books or subscribed to any programming.
The small company I was working for presented itself to the
public as the computer programming "A Team." I was told during my job
interview that the company had a lot of trade secrets that enabled it to be
"The A Team." After I started, I said I wanted to learn the "trade secrets,"
and my boss handed me a copy of Philip Metzger’s Managing Programming
Projects. I read the book immediately, and was amazed to find that
Metzger seemed to have had many of the same experiences I had been having. I
had struggled with the planning for my new year-long DOS project. Metzger’s
book cleared up many of my problems, and I used it as a basis for all the
planning I did the rest of that project.
Shortly after reading Managing Programming Projects,
I found a copy of Ed Yourdon and Larry Constantine’s Structured Design.
In skimming it I saw an explanation of why I was having such a hard time
with the design for my DOS program. I inverted my module calling hierarchy,
as Yourdon and Constantine suggested, and the whole design fell into place.
Then I found Barry Boehm’s paper, "Improving Software Productivity" (IEEE
Computer, September 1987), which explained in a quantitative way what
Metzger’s book had explained subjectively. I started to realize that there
was more information available to help me do my job than I had previously
realized.
Clearing the Fog
About this time I foggily recalled some letters my
professors had mentioned a few years earlier: A-C-M and I-E-E-E. I didn’t
have a computer programming degree and didn’t feel like a professional
programmer, but I decided to apply for membership anyway. I began receiving
Communications of the ACM, IEEE Computer, and IEEE Software,
and IEEE Software quickly became my favorite. I discovered articles
that helped me do my job effectively: how to help customers make up their
minds about requirements; how to control complexity on large projects; how
to create maintainable code; how to performance tune code; and so on.
Because it was published by the world’s largest society of software
professionals, IEEE Software managed to avoid catering to programming fads
and hype. The articles weren’t as fluffy as the articles in some of the
popular magazines I was reading, and I felt they would help me for many
years to come.
This was a watershed event in my growth as a software
developer. Prior to joining the community of IEEE Software readers, I
had viewed programming as just a job. I went to work. I got paid. I went
home. I stopped thinking about software. After joining the IEEE Software
community, I began to see that, even if I worked in an office by myself, I
wasn’t just a lone programmer. I was part of a community of software
developers who cared about software development and took the time to share
their experiences for the benefit of other software developers.
Other professions such as law, medicine, accounting, and
engineering have well-defined career paths. You get a specialized degree.
You take a qualifying exam, undergo an apprenticeship, or both. If you’re
good enough, you reach the level of partner, doctor, professional engineer,
or other well-defined professional standing within a pre-planned amount of
time. The career path for software developers isn’t nearly as well defined.
According to a U.S. government report, only about one quarter of the people
working as software developers in the U.S. have computer science or related
degrees. Compare this to doctors, lawyers, and engineers in which virtually
every person practicing in those fields has a related degree. It turns out
that my working as a programmer without a formal programming background
wasn’t unusual.
It Takes a Village to Train a
Software Practitioner
Considering the extreme variation in education and skill
levels in the software world, you might argue that there currently isn’t any
meaningful software development community, but I think the incredible
variation makes it all the more important to build one. Last year in Boston
the IEEE Software editorial board adopted a new mission for magazine:
Building the Community of Leading Software Practitioners. IEEE
Software’s goal is to publish articles, columns, and features that put you
in touch with other software practitioners. Beyond that, our goal is to
provide the articles that you need to maintain and enhance your skills as a
member of the community of competent software practitioners.
Every community is made up of both younger and older
members, some who are more skilled and some less. One implication of our
mission statement is that we must address the needs of leading practitioners
both young and old. We must address the needs of practitioners with strong
educational backgrounds in computer science, software engineering, and
related topics, but also of self-taught programmers— engineers, scientists,
accountants, teachers, doctors, attorneys, and others who find that they are
now writing programs for a living, even though they never consciously set
out to become computer programmers.
Welcome to the A Team
We do not intend to publish run-of-the-mill articles, but
articles about cutting edge, thought-provoking ideas, practices, and
technologies that you need to be a leading software practitioner.
Part of IEEE Software’s charter is to help transfer leading-edge research
results into practice. No other magazine that I know if gives you the chance
to see the latest developments presented in a practical way. These really
are the trade secrets you need to be on the A Team.
I have long believed that IEEE Software has an important
role to play in the software development community, bridging the gap between
research and practice, leveraging its association with the world’s largest
society of computing professionals, and providing a place where the software
development community can share its best experiences and ideas. With this
issue, I am honored and pleased to accept the role of Editor in Chief of
this magazine.
Most of the jobs at IEEE Software are filled by volunteers
(including my job), and we can use all the help we can get. I look forward
to hearing from you about how the magazine and I are doing. I hope
that you will volunteer to be an article reviewer or submit an article or
guest column. You needn’t worry about whether you qualify as a professional
programmer. If you’re reading this magazine, and care about improving
software development practices, you'll be a welcome addition to the IEEE
Software community of leading practitioners.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way #E200, Bellevue, WA 98005.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
