Mailman 3 March 2000 - Edu-sig

Software Engineering for everyone?
by anders schneiderman March 28, 2000

March 28, 2000

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

1 0

Software Engineering for everyone?
by Greg Ward March 27, 2000

March 27, 2000

[oops, sent this to Dinu personally -- meant to send it to the list, here 'tis] On 21 March 2000, Dinu C. Gherman said: > I found this two days ago while surfing the SEI web site > and think it might be of interest to some people in this > group. Although definitely aiming at higher academic edu- > cation the SEI (Software Engineering Institute at CMU) > addresses many concerns in the introduction below (as well > as in other parts of the document) that match very well > with the motivation behind CP4E as I understand it. Remember, the "E" stands for "everyone", and full-bore, industrial-strength "software engineering" is most definitely not for everyone. (Yes, it *is* something that needs to be taught to prospective professional programmers as part of their undergraduate degree: the ability to write solid, maintainable code is at least as essential as the ability to understand quicksort. Good coding practices are certainly the first step on the road to full-scale "software engineering", and good coding practices are something that CP4E should emphasise. But there's no need to go all the way -- after C++, the best way to discourage people from programming is probably forcing them to do requirements analysis or write test suites. *yaawn*) Greg -- Greg Ward - software developer gward(a)cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

4 4

The passion of EDU-SIG
by Arthur Siegel March 24, 2000

March 24, 2000

Inspired by some recent posts, I have gone back over some of the EDU-SIG archives, particularly the archives from before my involvement. I was struck my the degree of passion of a good deal of the discussion. Since I have been truly surprised at the degree to which discussions on this list have stirred my own passions, it helped give me some perspective. Early on in the list Guido had posted up a letter of resignation to the list from Terry Gabriel which said, among other things: "I think Python is what is going to be instrumental in saving democracy." I probably couldn't be further from Mr. Gabriel's general political bent. He talks of fighting "the corporate interests who want to dumb the society down". I consider the $1,200 piece of unfathomable genius and energy from which I write (a Gateway, as it happens) - as proof that the demonization of "corporate interests" are not on target. But I am in agreement with his general point of what's at stake here. His point was - a lot. And it is about demystification, and putting people in a position to be at home in the world, the real world, circa 2000. I also relate to to Stephen Figgins analogy to wilderness tracking. When I explain to friends - and my wife - the passion I developed for learning programming, I always use the term 'orienteering'. It seems to be coming from a deep place - a survival instinct. Circa 2000 I need to understand the algorithm to help me understand where I am, in effect. We recognize what's at stake, and have different ideas. I would hope we can let the passions stir here, rather than feel embarrassed by them.

1 0

Python for non-programmers
by Dennis E. Hamilton March 24, 2000

March 24, 2000

I posted this to python-list and I was kindly requested to post it here too. I am very interested in the objectives of CP4E. -- Dennis -----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Dennis E. Hamilton Sent: Wednesday, March 01, 2000 08:07 To: Donn Cave; python-list(a)python.org Subject: RE: Python for non-programmers I am teaching my 35-year-old son about programming using Python. He is a musician and has learned to do impressive things with the DVD + CD-RW + SB Live! on the Windows system that I set up for him. He does his own web pages, surfs a lot, and can get around pretty well. He wanted to know how to do more and learn how people do multi-media, game animation, and so on. I figured this was a good occasion to get involved with Python for some projects I have and as a learning laboratory for him, rather than getting into C Language, GUI object manipulation, etc. Yesterday, I sat next to him as he used Python and started to go through the tutorial, me making notes on my desktop machine and him trying to figure out things on my laptop next to it. I learned a lot. One thing is that the tutorial is full of things (I called it toolcraft in a different conversation here) that are meaningless for someone in Doug's shoes but leave him thinking that he is supposed to know what is being discussed. This was discouraging for him. It was an eye-opener for me. I have a list of all the terms (from shell to object-oriented) that have no context for non-programmers. I just skip past that stuff when I run into it. It is in the noise for me. He doesn't know that. I told him to treat it all as yack-yack-yack and just look for things that provided examples or gave him some things to do. That helped him get through to section 2.1 but things got tough around section 2.1.1 where there was no way to get through what was being talked about without more grounding. ("Argument," for Pete's sake!) So, I talked him through a "hello world" exercise, after organizing a Python/Projects folder enough so that he can see what corresponds to Python libraries and modules. This is without getting too technical about it. I want him to have enough about library organization just so he can get by for now, with deepening after as he gets some confidence with basic operations. He knows to make __init__.py files but not why. I wanted him to have a basic setup where he could begin self-guided activity and see useful results that can also be grown to bigger projects and organized work. He can see how to get in and out of the interpreter. I showed him the DOS editor and we built a "hello.py". We ran it from the python command line and by importing it in the "interactive mode." I set him up with 4DOS just because it is a little easier to know where you are and explore inside a command shell. (I figure learning about console mode would be an easier way to have useful work in python before dealing with the GUI and the fledgling IDEs available for Python). But mostly we learned things that one could also do using the MS-DOS command.com shell. He doesn't know what either of those are, but he knows how to start a shell and start working with files and the python processor. If we practice more today and tomorrow, while he is visiting me from Portland, I figure he will be able to sustain himself when he is back home next week, especially with me as a telephone and Instant-Messenger and NetMeeting consultant. He saw me use Python like a calculator, and he saw me assign strings and calculation results to variables an reuse them. He was fading fast (I need to make the first steps smaller yet leave him in accomplishment), but he was intrigued and I need to walk him through it again. That was more than enough for a first time out. If there were any good toy applications that did useful things around, I could have him doing engaging things at the console shell and python level that he could learn to analyze and replicate later. (I don't care if it is simply playing Hangman, or tic-tac-toe or How Many Petals Around the Rose, something that is a complete thing which can be used without having anything to do with building software.) He was tired and I was overwhelmed by how much we geeks operate on assumed understanding and an incredible amount of unexplainable lore. I saw that his Windows knowledge is spotty -- there are things that he has missed so far, such as the right-click menus and ability to make new documents and folders. He didn't know about the wheel on the wheel mouse to help with scrolling. Just the same, he has picked up ways to get around in Windows applications and can get by (that's part of Windows usability). He hasn't a very coherent model and doesn't have a confident way to learn more. Yet Doug is the kind of guy who *does* read manuals and he does work through tutorials, but he has, after 8 months with his own computer, mostly developed a personal craft based on things that were discovered to work for him. He watches me and others with more experience and he picks up more craft all of the time. This has really brought me up short about what it takes to introduce something like Python to a non-programmer (or even a programmer with a whole different paradigm of computer use, operation, and programming). I have to shed all of my intuitions, developed over 40 years around these fascinating mechanisms, and learn to see through his eyes. That is daunting! Doug has called the two of us the cybersmiths. He was remarking on how, in the past the blacksmith's kids would learn smithing from their dad by hanging out and watching and developing a trade, absorbing the smithie's toolcraft. He sees himself as an apprentice cybersmith. I like that. Now I am looking at what would make his experience more successful and effective. -- Dennis -----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Donn Cave Sent: Tuesday, February 29, 2000 21:53 To: python-list(a)python.org Subject: RE: any non programmers out there? Quoth "Cristian Echeverria" <echeverria(a)interactiva.cl>: | I think a very good and basic introduction is the Python tutorial: | | http://www.python.org/doc/current/tut/tut.html I started with that document and liked it a lot, too, but it's probably a little hairy for someone who really has no background in this area. I mean this not as criticism of the document, which is perfect for its normal audience, but in case someone out there is thinking ``Man, I must be retarded, that was Greek to me!'' Donn Cave, donn(a)oz.net -- http://www.python.org/mailman/listinfo/python-list -- http://www.python.org/mailman/listinfo/python-list

5 8

Learning and Doing
by Stephen R. Figgins March 23, 2000

March 23, 2000

I ran into this quote this morning: A common and mistaken idea hidden in the word "learning" is that learning and doing are different kinds of acts. Thus, not many years ago I began to play the cello. I love the instrument, spend many hours a day playing it, work hard at it, and mean someday to play it well. Most people would say that what I am doing is "learning to play the cello." Our language gives us no other words to say it. But these words carry into our minds the strange idea that there exist two wvery different processes: (1) learning to play the chello; and (2) playing the cello. They imply that I will do the first until I have completed it, at which point I will stop the first process and begin the second; in short, that I will go on "Learning to paly" until I "have learned to play," and that then I will begin to "to play." Of course, this is nonsense. There are not two processes, but one. We learn to do something by doing it. There is no other way. When we first do something, we probably will not do it well. But if we keep on doing it, have good models to follow and helpful advice if and when we feel we need it, and always do it as well as we can, we will do it better. In time, we may do it very well. This process never ends. John Holt Instead of Education While not specifically about CP4E, it reminded me of my own direction in education and python which is providing new programmers opportunities to do programmming, find good models, and people to provide helpful advice when needed. I want to weave together something like the pattern "Network of Learning" as described by Christopher Alexander in A Pattern Language. Instead of the lock-step of compulsory schooling in a fixed place, work in piecemeal ways to decentralize the process of learning and enrich it through contact with many places and people all over the city: workshops, teachers at home or walking through the city, professionals willing to take on the young as helpers, older children teaching younger children, museoums, youth groups travelling, scholarly seminars, industrial workshops, old people, and so on. Conceive of all these situations as forming the backbone of the learning process; survey all these situations, describe them, and publish them as the city's "curriculum"; then let students, children, their families and neighborhoods weave together for themselves the situations that comprise their "school" paying as they go with standard vouchers, raised by community tax. Build new educational facilities in a way which extends and enriches this network. To this end, I am sketching out some ideas for a database of information on opportunities to program, good models, and people to provide helpful advice or act as masters to apprentices. I hope to have enough things together to launch the database in mid April. For the opportunities to program, I am thinking of something like classifieds, people looking for assistance and willing to act as the master on a certain project. For good models I am thinking of something like Amazon's review of books, but applied to code, tools, libraries, tutorials, etc.. I will post some more specifics next week. I still need to flesh it out a bit more. Stephen

2 1

SEI's Guidelines for Software Eng. Education
by Dinu C. Gherman March 21, 2000

March 21, 2000

Hello, I found this two days ago while surfing the SEI web site and think it might be of interest to some people in this group. Although definitely aiming at higher academic edu- cation the SEI (Software Engineering Institute at CMU) addresses many concerns in the introduction below (as well as in other parts of the document) that match very well with the motivation behind CP4E as I understand it. Recognizing this I wonder if there would be any reason to get in touch with SEI, or maybe not, given the fact (well, rather my own estimate) that they are better known for a solid, systematic, academic, engineering-like approach to software development than for one more based on soft qua- lities like playing, exploration, self-discovery? In fact, I wouldn't be surprised if SEI would discourage people from using script languages for 'serious program- ming'. Anybody having experience/evidence backing this opinion, or the contrary of it? Regards, Dinu -- Dinu C. Gherman ................................................................ "The thing about Linux or open software in general is that it actually tries to move software from being witchcraft to being a science," [...] "A lot of the programs you see today are actually put together by shamans, and you just take it and if the computer crashes you walk around it three times... and maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC) Guidelines for Software Engineering Education Version 1.0 http://www.sei.cmu.edu/publications/documents/99.reports/99tr032/99tr032abs… Introduction Into the foreseeable future, software will play an in- creasingly important and central role in all aspects of daily life. The number, size, complexity, and app- lication domains of programs being developed will grow dramatically. Unfortunately, there are serious problems in the cost, timeliness, and quality of development of many software products. The code in consumer products is doubling every two years; it is almost the norm for software projects to overrun their planned cost and schedule. Many large-scale development projects are never completed, and many of those completed do not meet the user requirements and are of poor quality [...]. These issues have placed an increasing demand for soft- ware developers who are equipped not only to deal with the scientific and technical aspects of computing, but for those who have professional education and prepara- tion for the practice of software engineering [...]. This includes practice related to use of software pro- cesses, measurement and analysis, front-end development methods, quality engineering, software maintenance, testing, and working as part of a team. Unfortunately, too few academic programs offer curricula that focus on this type of education. The solution to this problem depends heavily on the ability of faculty to redesign and implement curricula that not only emphasize computer science, information science, and technology, but also focus on the "practice" of software engineering (SE) and include the equally critical people and process issues. The main purpose of these Guidelines is to provide assistance to faculty in the design and development of programs in software engineering and related curricula.

1 0

CIGS
by Arthur Siegel March 19, 2000

March 19, 2000

Attached is some information I sent to http://forum.swarthmore.edu/dynamic/ informing them of my own activities and that of CP4E. The general efforts at forum.swathmore.edu are making its (good) influence felt. My 9 year-old nephew is actively involved with one of their programs . I'm not sure how he found it. ART

1 0

(no subject)
by zev＠mail.ru March 17, 2000

March 17, 2000

Hello edu-sig, i have large practice in solving one problem... python dosn't support cyclic import/// i mean you can't write something like this: #p1.py import p2 def pp1(): print 'yep' p2.pp2() #p2.py import p1 def pp2(): p1.pp1() so .. even now i cant understand why it doesn't work on the one hand PC commands admitted cyclic import/including on the other hand why dont use this commands in Python?? actually i solve this problem ... but i spend 3 weaks solving it... please comment me -- Best regards, zev mailto:zev@mail.ru

1 0

*2* SF Bay Area Python education events
by Wesley J. Chun March 15, 2000

March 15, 2000

1. BayPIGgies (San Francisco Bay Area and Silicon Valley Python Interest Group) monthly meeting... if you're in the Northern California area tonite, you can come to Mountain View, CA to hear Guido give his talk on CP4E as well as Python Futures and Q&A: When: (today) Wednesday, March 15, 2000, 8pm Where: Mountain View, CA Who: special guest speaker, Guido van Rossum, creator of Python! What: Guido will discuss the following topics: 1. Computer Programming For Everybody 2. Python Futures (1.6, etc.) 3. Python Q&A Info: for more, see the BayPIGgies website: http://www.baypiggies.org/ public transit directions and map can be found at: http://linuxmafia.com/bale/ 2. another UC Santa Cruz Extension Python course in Silicon Valley, Spring quarter 2000: speaking of teaching/learning Python... for those of you interested Python training and are able to make it to Northern California, due to the popularity of its first Python course, UC Santa Cruz has decided to offer this course again in Silicon Valley, so if you know anyone who wishes to get up-to-speed quickly on Python or those self-taught who perhaps would like to fill-in any missing gaps, this would be a good opportunity. the maximum enrollment is set at 50, and their rate ($400) is pretty reasonable, being a public institution and all. (shameless plug: i am also available to contract for corporate training services too if there too many people from your company or if you're too far away!) the website below is not 100% accurate but close enough! When: Tuesdays, April 4 - May 30, 2000, 6:30pm-9:30pm Where: Sunnyvale, CA Who: Wesley Chun What: intro to Python, data types, statements, errors and exception handling, functions and modules, OOP and classes, execution environment, regular expressions, network/Internet progamming, inter- facing to your operating system, creating GUIs with Tkinter, intro to JPython, and Extending Python Info: for more info, see the UCSC Extension website for the next Python course: http://www.ucsc-extension.edu/knowledge_is_timeless/qd/softlist.taf?functio…

1 0

RE: [Edu-sig] re: New game in town
by Arthur Siegel March 15, 2000

March 15, 2000

Martijn Faassen writes: >But, we have something else you may not be aware of: the Vaults of >Parnassus. http://www.vex.net/parnassus >Click 'latest' for at least a nice list of recent Python software >(and also info) announcements. It's a great resource. Good advice. Things change. The focus of python.org does appear to be shifting. The Vaults are a resource I and perhaps others need to pay more attention to. And hopefully there will be other alternatives, like the one Stephen is discussing. Martijn Faassen writes: >I didn't think Alice was being held forward as anything like a cool >piece of Python software with a GUI that's aimed at beginners. But I >thought Alice's aim wasn't CP4E, it was letting people play with 3d environments. I'm not sure what Alice's aim is. The fact is one of only a few software efforts on the EDU-SIG page and is described page as follows: "Alice A 3d virtual reality system that teaches 19-year olds without prior programming experience to write Python scripts to control interactive 3d experiences." Alice is a monster which I don't get - and Python and 3D is sort of my thing. What is educational about it in any possible sense of the word? Unless you bill it more honestly as something that provided an educational experience for the folks who built it. Having 19-year olds (did they say 19-year olds?) play with scripting it is serious dumbing down. An opinion. I seem to have a lot of them. And I honestly hope that my stating them bluntly is not an annoyance to the list or distructive of the progress of EDU-SIG. Martijn Faassen writes: >And there it'd be nice if there was more discussion on course materials, >and the best ways to approach teaching Python. Hopefully. An alternative to me yakkking would be welcome by all, including me.

1 0