[Edu-sig] Software Engineering for everyone?

[anders schneiderman]

On 23 March 2000, Greg Ward wrote:

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

In fact, given the success of the open source movement, it's not clear that
anyone should be forced to learn SEI.  Last year, Software magazine had
several wonderful exchanges between several Open Source practitioners and
followers of more formal methodologies.  The OS folks said, we do follow a
methodology--a very particular, stylized way of doing things--we just don't
talk about it much and we don't focus on the same things you do (e.g., we
do less spec writing and more iterations or "microspirals", as one person
put it).  I'm sure SEI is useful in some circumstances--there are very
smart programmers who swear by it--but there are just as many very smart
programmers who use a very different approach.  

So, rather than saying to poor high school kids, here's _the_ methodology
that all righteous computer people follow (i.e., lying to them), I'd go for
the following approach.  

First, let's step back and ask, what are we trying to accomplish with CP4E?
 IMHO, the list looks something like this:

1) Give everyone enough skill so they can write the equivalent of an Excel
macro so they automate a bit of their work and make their computer work for
them rather than against them.  Odds are most people won't end up using
this skill very much (unless, of course, the world of computers becomes a
lot more user-friendly than it is now), but at least school can lay the
groundwork so it isn't so intimidating or mystifying.

2) Since at some point in their lives many people will end up being
involved with a computer project (usually as hapless users), it's useful
for them to know how the sausage gets ground.

3) Create enough basic computer literacy so people can act as informed
citizens when computer-related issues are discussed.


Given these goals, I'd say your average Jane needs to learn the following
about Software Engineering in high school:

* If you're writing a program for someone else, how do you figure out what
the program needs to do?  How do you help users decide which tradeoffs
they're willing to live with? How do you deal with the fact that it's hard
for most users to know in advance what they really want?  

* How do you handle changes in the requirements for a program?  How do you
allow for the reality that people will change their minds & unforseen
events will force you to change the direction of a program without having
the process spiral out of control?

* How do you work in groups without killing each other?  How do you resolve
conflicts between different users, developers, etc.?  How do you run
meetings that are short, focused, and that get things done (of all the
skills we could teach, this one could have the biggest impact on society,
the GDP, etc.)?

* How do you figure out roughly how much progress you've made & how close
you are to finishing?  In other words, how do you do very rough estimates &
revise them as you go,  how do you use testing to make sure your program
doesn't become "90% done" forever, and how in general do you manage risks?

* As your problems get more complicated, how do you scale up without either
losing control or getting swamped by a process that's too bureaucratic?

Most of these skills are important for Goal #1, and all of them are
important for Goals #2 and #3.  In teaching these skills, the focus
wouldn't be to say here's the one right way to do this but rather teach
kids how to figure out what seems to them the best way to answer these
questions.

You might think this is way too complicated for kids, but given a slightly
different approach to teaching, I think it's doable (based on my experience
teaching computer-illiterate adults how to write macros, scripts, programs,
etc.). For instance, most computer classes teach people how to write short,
individual scripts from scratch.  You can't learn software engineering this
way; at this size, you won't get bit on the ass when you make software
engineering mistakes and so you won't really learn.  Here are some examples
of how to get around that problem:

1) For the first few projects, kids would build small, simple databases
from scratch.  Once they got their feet wet, they'd break into groups to
modify a larger database that already existed, using other students in the
classroom as their users/clients.  The databases could be something that
was really used or they could just be fun, such as a  database for cat
lovers, car lovers, the fashion police, etc. (my first database written 20
years ago, for hiring assassins to kill teachers, would probably be a no-no
in the post-Columbine world).  

Say one group was extending the Fashion Police database so that in addition
to having Fashion Crimes it would also have punishments for each crime.
They would have to negotiate with their "client" to figure how much they
thought they could realistically do in 3-4 weeks, prioritize what features
mattered most, then report back twice a week on their progress, getting
feedback and talking as a class about the problems people had encountered
and how to move forward.  For ex, in the first week you'd expect that the
kids would have gotten a bit too ambitious in their goals and got bogged
down as soon as they started forward.  By the end of the week, with enough
help from the teacher and the rest of the class, they'd have scaled back
what their goals were and set a target of the end of the next week to see
how they were doing.

2) If you were using something like the 3D graphics world of Alice,
students would start by writing a bunch of little scripts over several
weeks.  Working in groups, each kid would be responsible for animating a
different set of characters (e.g, one kid might animate the cow and the dog
for the Farm group).  After several weeks of work, they'd have a decent
number of scripts.  Now the challenge would be to start combining them to
build more and more complex scenarios.  At some point, the amount of
scripting would get clumsy enough that the kids would have to "scale" their
approach or they'd get overwhelmed.  With the right curriculum and a few
practice runs, a teacher could probably get her students right to that "oh
my God what the hell do we do next" point where the students would need the
tools of software engineering, redesign, etc. to keep afloat (quite similar
to what happens to lay programmers when they've got one too many Excel macro).

3) Every few assignments, instead of having students write a new script,
have them test and debug a simple existing script.  After a few weeks, give
each group of students a program that's really cool (however they define
"cool") but really buggy and poorly documented.  Have them tear it apart
and figure out how to make it work _and_ what all of its parts are supposed
to do.  As they go, have them keep a journal of all the things they wish
the stupid programmer who wrote the program had done differently.

Most of my experience is with teaching adults, so I don't know how well
this would work with, say, teenagers.  But I think an approach similar to
this one could probably fit the bill:  start out going easy on software
engineering and then gradually add more as students learn the hard way why
they need it.  In the end, students would not only learn a lot more about
programming, but they'd also learn valuable lessons about how computer
projects do & don't work, lessons which would really save their butts in
the real world when they confront computers as users.

Anders Schneiderman
National Journal Daily Briefings Group