Dennis E. Hamilton, System Architect
This is draft 0.03 of 2000-05-03
Who Needs SE4E?
Accountability: What Happened?
Collegiality: Community Learning
Predictability: Make it So
Practice, Practice, Practice: Never Stop
References and Resources
Contributors
Change History
[Took a lot to add this in and I don't like it. Wrong tone. Know how to redo it, beginning with what excites me about CP4E and what has me be attracted to it. Will come back after the other sections tighter.]
The Computer Programming for Everyone (CP4E) project is out to have computer programming be accessible to anyone, including as an element of modern educational experience and literacy. Discussions on CP4E include proposals for reforming school mathematics (or not) and for encouraging computer-application programming as an exploratory experience made available to all young people [Edu-SIG]. The Python language is featured in discussion of programming environments appropriate for CP4E initiatives.
It's also asked whether software engineering has any role in a CP4E syllabus: Is there such a thing as Software Engineering for Everyone, and what does it have to do with CP4E?
I share the view that it is essential for CP4E to foster playful discovery and experimentation, especially in opening up neophyte experiences of self-directed exploration [Hacker]. Let's emphasize programming as an avenue for creative expression and improvisation without any artificial constraints on early practice.
It's commonly agreed that premature emphasis on software-engineering approaches gets in the way of early learning and practice. It takes some mastery of basic programming techniques before most of us are able to recognize the contribution of software-engineering practices for increasingly-complex, demanding software projects.
But it is also the case that engineering skill is also best developed gradually in accompaniment with expanding project size. We want to show how engineers win at their game, and starting out in the short end of the pool is always a good practice.
CP4E provides a wonderful opportunity for the curious to appreciate the discipline involved in engineering. There is, in CP4E, an unparalleled opportunity for people to experience the kinds of discipline that support the successful delivery of complex systems into an imperfect world, whether for commercial air travel, distributing electrical power, operating the postal service, or giving depositors reliable access to their own accounts via automated teller machines anywhere in the world.
There is something valuable to provide in any CP4E "curriculum" about engineering involves, but it doesn't have to be very heavyweight. I am thinking of three things: accountability, collegiality, and predictability.
My first computer-related job was in 1958 as an engineering aide. I had dropped out of college after two quarters, and the calculus plus high-school drafting classes got me the work. My engineers wrote everything down. Everything. I spent all of my time creating graphs and charts from the models we were exercising using programs for an IBM 701 computer system. Everything was checked, signed, bound, and filed. I never forgot that.
I resented the tediousness of the work, yet I've never forgotten the care that was taken in having complete, accurate, and reproducible records. I never feared riding in a Boeing 720 when they were later produced.
In the course of this job, the lead engineer and I began teaching ourselves FORTRAN. This was my first contact with a power user, and it is clear to me now what motivated him to learn to develop his own programs. He wanted a way to have the program outputs be in the exact form that he demanded for the analyses and engineering reports we were producing, rather than suffering with the difficult-to-digest output that the programming staff was satisfied to produce.
In Watts Humphrey's Introduction to the Personal Software Process, students record their time and keep a log book and journal very early [PSP]. This becomes a progressive historical account of actual effort, including the ideas that were tried, the problems that were discovered, and how the course of a project evolves over time. I've used engineering notebooks many times over the years, but I was inspired by its promise for a personal software discipline that I have begun to rely on journals for consistent accounts of all my activities. I am in PSP-inspired notebook #20 right now, taking about two months per 100-sheet spiral notebook. I write a lot more than that every day, along with reading as many as 200 e-mail messages, yet my notebook has distinct use and is rarely far from reach. My notebooks are lifesavers for backtracking and reconstructing changes to my computer systems after problems materialize. I carefully do not keep any notebook on-line. My notebook is on the side when my computer has cratered or there are other things taking up the display's real-estate. I carry my notebook on a bus, in the car, into meetings and seminars, and on air travel. Whenever I rebuild a computer configuration, I refer to my notebooks for past experiences and always record the new effort. I use many computer tools, but notebooks provide the thread among all activities that lets me recover a sense of what I was working on at a given time, what I did, and what happened. Checklists for projects, deliverables, and trips will be started and completed in my notebooks. Test sequences and defect discoveries are recorded immediately in my notebook, well before being transcribed into more formal records.
My point is that basic accountability -- keeping physical records of what was done, what happened, and ideas that came up -- builds awareness of how ones energies are expended. It reflects how accomplishment occurs over time. It leaves behind an accounting of key decisions and also what the consequences were later found to be. It is an important contact with reality separate from any illusions I have for what I am capable of and what my efforts have actually been.
Introduce accountability while young people are 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.
For me, sustained accountability has been an unnatural act, and I resist it mightily. I recognized it as an important aspect of producing useful results, and I keep practicing. At last, it is almost second-nature for me.
I have been looking for a better word than this. I am giving up that search.
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 by the magnificence of that undertaking and the contributions that so many people made in so many ways to bring 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. I want to see some sense of the possibility of collegiality in the way CP4E is introduced, especially in schools.
Human activities of any scale are cooperative activities. As a young software developer that I easily maintained the illusion that it was all up to 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. I am not so stingy with myself any longer, yet I am still caught wasting more time than necessary before consulting someone else for assistance or to serve an essential sounding board for ideas I am struggling with.
In my first serious programming job (as a "Clerk Typist A" student programmer -- they hadn't invented programming positions at that university yet) after the engineering aide experience, the faculty member I worked for was creating a handbook of software. He had a funded grant to collecting what was available and republishing it with the documentation needed for making use of it. We were also cleaning up the disparate implementations so that the programs and routines could be used together as part of a coherent body of work. I loved it and was constantly frustrated in my struggles to write intelligible documentation. Nowadays I begin designing documentation as an inseparable part of the design of programs. Assuring that a program is explainable is one of my tests for conceptual economy of the program itself.
[Make early point about overcoming the reticence to show work to others as soon as possible. That it doesn't have to be perfect first, it's faster when you bring in the perspectives of others. Explaining something to someone else will provide insights into what I am doing that I wouldn't have had, even when non one else says a word.]
In my first moonlight hacking project, three of us student programmers modified a piece of open-source software. It was the SOAP II Assembler for the IBM Model 650 Computer System. We were privileged that the source code and documentation for the assembler were printed in the back of the manual. By inspecting the code and finding ways to tighten it up here and there, we eked out enough free memory to add the goodies we wanted.
Programming skill are almost entirely learned by first working from existing code. It becomes important to have good examples. At some point, the practice of refinement and adaptation begins to show the qualities of craftsmanship, and our programs can be increasingly diverse from one to the next.
This progressive refinement toward mastery of programming as a problem-solving skill is not a solitary activity, no matter how much we go through it individually. 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. Those became the inspirations for our generation of programmers, and it was possible because those programmers made their work available to read and adapt.
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. Especially in settings where code walkthroughs were not 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.
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 an article, 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 in a game bigger than my comfort zone, so that stuff comes up. The only way I have every conquered that is to play anyhow.
Here's the key aspect of collegiality. It is not just that we are always always building on the work that comes before us, or that such work is available for us to work on. That's no small thing. The importance of collegiality is that software development is far more of an empirical and social process than we 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 get back on track. I also notice that I always get something out of discussions of ideas and projects, if I am willing 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.
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 at which one begins to do that reliably. It's a big leap from not knowing what line of code to write first in ones early teething. 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.
[Wrap it up here.]
- [CP4E]
- Computer Programming for Everyone. Complete this reference to the CP4E space reachable on python.org, with the project description and links.
- [Edu-SIG]
- Complete reference to python.org and key to accessing this discussion list.
- [Hacker]
- Raymond, Eric S. How to Become A Hacker. Published on the Web as a Frequently-Asked-Questions file. Updated periodically. http://www.tuxedo.org/~esr/faqs/hacker-howto.html
- [Project]
- Crisp Publications. Project Management. A 60 minute book. Have requested the reference to this from M.K. Beeby.
- [PSP]
- Humphrey, Watts. Introduction to Personal Software Productivity. Find and include the Addison-Wesley Reference. It will be on fatbrain or amazon.com.
- [Tracker]
- Figgins, Stephen. Hackers and Trackers: CP4E. On-line article. O'Reilly Network. January 31, 2000.
- [Vixie]
- Vixie, Paul. Software Engineering. In Open Sources: Voices from the Open Source Revolution. O'Reilly (Sebastopol, CA: 1999). ISBN 1-56592-582-3.
- [Ward]
- Ward, Greg. Re: Software Engineering for everyone? Posted to Edu-SIG, March 27, 2000. Create link to the archive where this note lives.
This article arose from discussions on [Edu-SIG]. Greg Ward took a position that had me notice my own experience in gradually recognizing the value of software engineering. I responded on March 27, 2000. Create link to the archive of that too.
- draft 0.03 2000-05-03 ist (+0200) by orcmid.
- Smooth the coverage in each topic and begin pruning to the intended size. Get the key points and suggestions made more authoritatively and toss illustrations that don't get right to an important point. Submit to editorial checkpoint. Remember to run spelling checker first. There are 3191 words in this version. I want around 1200.
- draft 0.02 2000-05-02 ist (+0200) by orcmid.
- Developed basic context and theme. Pasted in and organized the original e-mail notes and clippings that provided the initial thinking on this topic..
- draft 0.01 2000-04-05 pdt (-0700) by dh
- Initial draft set up as web page using an existing document for boilerplate.
$$Author: Orcmid $
$$Date: 02-10-13 15:23 $
$$Revision: 5 $
HomeEnd of Document