[Edu-sig] Software Engineering for everyone? -- In a way

[Dennis E. Hamilton]

I support what you have to say here.  I do think there is something
important to provide in a high-school curriculum about what engineering
involves, but it doesn't have to be very heavyweight.  I am thinking of
three things: accountability, collegiality, and predictability.

1.	ACCOUNTABILITY
	I worked as an engineering aide right out of high school.  (Well, I had two
quarters of college, and the calculus plus high-school drafting classes got
me the job.)  The engineer I was working for wrote everything down.  I spent
all of my time, until I got to write some programs (we were self-teaching
ourselves FORTRAN), creating graphs and charts for the data we were
producing off of an IBM 701 computer system.  Everything was signed and
bound and filed.  I never forgot that.  I hated the tediousness of the work,
and I never forgot it.  And I was never afraid to ride a Boeing 720 when
they were later produced.

	In "Introduction to the Personal Software Process," the Watts Humphrey
book, the first thing that students are asked to do is record their time and
keep a log book.  As many years on-and-off that I have seen and used
engineering log books, I started all over again when I picked up the
Introduction to PSP about two years ago as a way to sharpen my individual
practices.  I am in log book #19 right now.  It takes me one-to-two months
per notebook.  Just in recording adjustments to my own computer
configuration and wanting to be able to recover or recreate an installation
on another machine, the log books have been a lifesaver.  I also find that
it doesn't work to keep notebooks on-line.  It is something I use on the
side even when my computer system is hosed and there are other things taking
up my screen real-estate.

	My point is that there is something around accountability, keeping track of
what was done and what happened, and also getting present to how ones
energies are invested in activities, that are valuable and that can be
introduced when young people are interested in what the activities of
software development and software engineering are.

	I would look for a way to provide this in the context of young people
learning their own ability to accomplish something by exploration and doing.
Providing accounts for what was done and what was involved is an important
aspect of getting a sense of the responsibility with which software
engineering is undertaken.  I would not tie it particularly to software.  It
applies in science and engineering generally, and I would want young people
left with a sense of that, even if they never pursue a technical career
themselves.

	I also notice that an important aspect of open-source projects is that
there is an opportunity to provide a high level of accountability simply in
keeping it all together and having a structure by which what is available
and what is being worked on can be inspected.  This may be the right level.

	For me this was an unnatural act, and I resisted it mightily.  I recognized
it as an important aspect of producing useful results, so I kept practicing.
Now it is second-nature for me.

2.	COLLEGIALITY
	I have been looking for a better word than this.  I am giving up that
search.

	I say that most human activities of any scale are cooperative activities.
I notice as a software developer that I easily maintain the illusion that it
is all about me and my own innate creativity, and if those other jerks would
get out of my face it would all be perfect.  I know that is hogwash, yet I
constantly see how I organize my life as if it were true that I exist
independently from everyone else, a pack of intruders.  (Even typing this
note has as much or more self-gratification in it than any sense of being
part of something bigger than myself and participating in a community.)

	In my first serious programming job (as a "Clerk Typist A" student
programmer -- they hadn't invented programming positions yet) after the
engineering aide experience, the faculty member I worked for was creating a
handbook of software by collecting what was available and republishing it
with documentation.  We were also cleaning up the disparate sources so that
the programs and routines could be used together as part of a coherent body
of work.  I loved it and hated it all at the same time.

	In my first "hacking" project we actually forked, as had many others, a
piece of open-source software.  It was the SOAP II Assembler for the IBM
Model 650 Computer System.  Hudson, High, and Hamilton produced the SOAP H
version by taking advantage of the fact that the source code and
documentation for the assembler were printed in the back of the manual.  We
did the usual thing: inspected the code and figured out ways to tighten it
up enough so that we had some free memory in our ~10k machine to add the
goodies we wanted.  My contribution was to build a linking loader for the
assembled programs, based on what I had seen of the FORTRAN II BSS Loader.
I recall not being very good about teamwork in this project, and I was
always holding up the parade by being off doing stuff on my own, and slowly.

	One of the things I noticed is that programming skill is often learned by
working from existing code.  It becomes important to have good examples.  At
some point, one has developed a practice of refinement and adaptation that
begins to show up as craftsmanship.  This is not a solitary activity, no
matter how much we go through it individually.  And for it to work, we must
be willing to submit our work to the adaptation and refinement of others.
Sooner rather than later.  When I first met Donald Knuth, he talked about
some of the most beautifully-crafted programs he had ever read. One program
was one that I had used, the Bell Labs Interpreter for computational work on
the IBM 650.

	Ever since "The Psychology of Computer Programming" and the introduction of
inspection, I have been more and more inclined to submit my work to the
inspection of others, as early as possible.  I have always been gratified
when a colleague came to me and requested doing a code walkthrough of
something being worked on.  This where code walkthroughs were not (yet) a
formal part of the team's work process.  I also notice that when I go dark
(I love that expression), I have completely closed up and gone inward where
there is no community support at all.  These days I can catch myself by
noticing that the date on the last completed page of my notebook is not
recent.  Today (03-27) the last entry is 03-25, and the previous was 03-23
and that was the last one of any substance.

	I haven't gotten rid of the fear of rejection, of being humiliated by doing
something stupid in public, or any of that.  What I have learned is that I
don't have to stop because of that, and I persist more all of the time.
Every time I write one of these long notes, I am apprehensive about how it
will be received.  It's as if the newbie hesitations (which I don't recall
having that strongly as a newbie) and the desire to look good never leave.
I am just playing a bigger game where that stuff all comes up, and I play
anyhow.

	So I want to point out a key aspect of collegiality.  It is not just that
we are always always always building on the work that comes before us, and
that such work was made available for us to work on.  That's no small thing.
I want to emphasize that software development is actually more of an
empirical and, yes, social process than those of us with as much
introverted, intellectualized viewpoint as myself can easily or willingly
recognize.  I notice, for example, that as much as I follow principles of
the PSP and bring myself to be accountable, my work is not nearly as
effective as when I have collaborators who hold me to account.  When I go
dark, I am in the dark.  Someone else can interrupt me (and I will resist),
and that can happen more quickly and usefully than waiting for myself to
snap out of it.  I also notice that I always get something out of
discussions of ideas and projects, if I am willing to be vulnerable enough
to talk about my half-baked ideas and be authentic about what concerns me.
It helps immeasurably to have a community in which to do that.  I also know
a wonderful secret: there is nothing better for mastery of a subject than
teaching it to others -- because they will teach it to you.  I think the
great athletic coaches know this, along with their profound commitment to
and respect for their players.

	In the context of CP4E, I think the simple practice of sharing ones work,
learning to inspect the work of others, and having our own work checked is a
big deal.  The open-source philosophy is also applicable here, as well as a
source of great worked examples (though not all open source code is that
great.)  And having that be all right and a desirable, let alone
permissible, way to produce an effective result is an important thing to be
exposed to when young.  And be accountable for what is original and what
isn't and acknowledge the support that occurs in teamwork.  These are
practices that I think are very important to demonstrate in a practical,
simple way.  There are many exercises for demonstrating the diversity and
insights that are available with cooperative approaches.  I don't know what
would instill an appreciation for how interdependent we actually are.  I
would look at that, though.

	I grew up on a steady diet of science fiction.  I like to say that Robert
Heinlein taught me to read.  In all of that reading, I thought of being on
the moon or going to Mars as something that would be a personal, individual
act.  The reality of space flight and the magnitude of the enterprise that
it took to have human beings walk on the moon and return just wasn't the way
I dreamt it would be.  Today I can be moved to tears about the magnificence
of that undertaking and the contributions that so many people made in so
many ways that brought space flight to reality.  I say there is not anyone
who participated in that effort whose contribution did not matter.  That's
new thinking for me.  (And not original, either.)  I want to see some sense
of the possibility of collegiality in the way CP4E is introduced in schools.

3.	PREDICTABILITY
	It is something to get to the point where one can actually specify
something and design it without having ever built it first.  It takes
practice and experimentation and some sort of conceptual shift where one can
do that reliably.  It's a big leap from not knowing what line of code to
write first in ones early teething.  Then building it first becomes a
seductive habit that is very hard to shake.  It's very interesting to get to
the point where one can specify something and trust that it can be built
without having any idea how!

	For me, predictability in software development is more than this.  It has
to do with a lot of quantitative methods and metrics.  It has to do with
refinement of requirements through design and construction.  It is certainly
tied to accountability and collegiality.  And being able to predict effort
and the time it will take to have a completed result.

	I don't want to emphasize predictability too much, but I think it is also
something valuable to instill an early appreciation for.

	It may be that the simplest first principle here is divide-and-conquer.
Creating interface agreements and sharing modules in a larger project of a
team might be enough.  That does lead to critical predictability of a kind.
And it can be useful to see what happens over time and in the face of
change.

	I found a very cool book on project management once (I think it is the
50-minute book on Project Management from Crisp Publications).  It is very
simple and very straightforward.  There is a video that goes with it that
demonstrates project thinking using a small company's move to new quarters
as an example.  It is really great.  It is also easy to forget and revert to
other ways of doing things.  It is also, in my experience, very difficult to
project manage a one-man-band.  It helps to have more players.

	I don't know if I would promote estimation very heavily, but maybe it would
be valuable for kids to try predicting the size of programs and learn how to
refine that as the work proceeds.

	I would look for examples in "real life," like getting homework or papers
done on time, though, and working from outlines first, something that I
remember as a challenge when I was a high-school student.  Or managing ones
training for a sporting event or team activity.  Or producing a
community-service or performing arts activity.

	The outline for this note is the first paragraph.  I wrote that.  Then I
let the note "write itself."  Not very predictable.  It helped though, in
that I did occasionally use that three-point list to ask myself what was the
point of each part and when was I going to make it.   Satisfying, but low in
predictability.  Unless I notice and use that data in further work.  I've
just put it in my notebook.

Love,

- Dennis

------------------
Dennis E. Hamilton
InfoNuovo
mailto:infonuovo@email.com
tel. +1-206-779-9430 (gsm)
fax. +1-425-793-0283
http://www.infonuovo.com


-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Greg Ward
Sent: Monday, March 27, 2000 06:12
To: edu-sig@python.org; edu-sig@python.org; edu-sig@python.org
Subject: Re: [Edu-sig] Software Engineering for everyone?

[ ... ]

I'm *not* speaking out
against testing software (or debugging, or thinking about what you're
going to do before doing it, or other good practices); I think that
should be taught from the beginning.

And I'm not speaking out against "anal-retentive software-engineering"
practices, like rigorous, full-coverage testing, formal design and code
reviews, etc. etc.  IMHO "extreme programming" falls into this camp,
although it seems to me rather less anal retentive than most other
software methodologies.  It's still a methodology, though, and Kent Beck
(I'm in the middle of his book on XP now) says so.

I *am* speaking out against trying to teach full-blown software
engineering techniques to high-school students who are just getting
their first taste of writing code.  Yes, teach them to understand the
code before (and while) they write it, and teach them not to trust it
until they've tested it, and teach them how to fix it when it doesn't
work.  But don't go pulling in all the industrial-strength machinery
that the SEI espouses, because it just isn't necessary for writing Excel
macros or throwaway Python scripts -- which is what an awful lot of
people who come out of CP4E will probably end up doing.

[ ... ]

True.  The further you get from a throwaway script to do your homework
to implementing a phone-billing system, the more SEI-style bureaucracy
you need.  However, that sort of software engineering bureaucracy
probably belongs in the undergraduate CS curriculum, not at the high
school level.

        Greg

_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://www.python.org/mailman/listinfo/edu-sig