Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
In a previous article, Vince Manis wonders about software project failures and tries to figure out why they happen. I can think, offhand, of a number of hypotheses to explain the continuing inability to deliver reliable, useful, on-budget software: [He gives 5 reasons...] Undoubtedly, the true answer is a mixture of these, along with others that I just can't think of at 4:45 am. Well, it's 4:45 am here too, but I can propose at least one more hypothesis. How about: 6) The structured programming revolution is a real bad idea that has been significantly holding back progress for years. Now, as I wait for the structured programming police to go after me, I'll try to defend this statement. First, isn't it just a little bit silly to think that making rules about how programs are indented, whether or not to use goto statements, ...etc. will really make a difference to a large software project. A piece of software can be perfectly indented, totally goto free, and absolutely positively wrong. Likewise, it can be full of goto statements, line up as straight as a board against the left column of the page, and still be provably correct. In fact, for any purported structured programming rule that I've ever heard of, I propose that one could create a perfectly correct piece of software which violates that rule. So maybe the structured programming movement isn't really about correctness. Maybe it's strong suit is helping us make maintainable software. This may or may not be true, but I've sure seen lots of purportedly structured programs that were very difficult for me to maintain. Likewise, I can conceive of programs which would offend a structured programming supporter, but which could quickly and easily be comprehended by a maintenance programmer. Anyways, when you are selling into a competitive market of millions of end users, maintaining software is impractical. It has to be correct on the first shipment and it can't really be changed once it's out there. So having a maintainable structured program really isn't all that useful. Being maintainable is just an excuse to be buggy. Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence. Maybe the structured programming movement is about allowing a group of programmers to work together on a large project. OK, but what REALLY happens when a group of structured programmers tries to develop a large program? Usually they argue about how the program should be indented, what the comments should be like, how the subroutines should be nested, ... etc. Often they argue about those issues much more than they argue about things like how can the algorithms be checked for correctness, how will the end users perceive the programs, what should the program's performance be like ... etc. You know, the stuff that the customer cares about. So maybe structured programming is about making programs run faster and use less of the computer's resources? Yes, structured programming techniques don't really improve correctness, maintainability, usability or performance. But the real problem with the structured programming movement is that so many programmer believe in it. They believe that by following these techniques, they will produce good programs. It just isn't so. Programming is much harder than that. The RISK is that these programmers initiate projects based on the belief that structured programming is the atomic bomb of the software war. When the structured programming techniques fail to make the problem easier, and the programmers are confronted with the grim reality of how incredibly much work it takes to make the project succeed, the project usually fails. Occasionally, there are enough resources on the project that if the programmers put in enough all night work sessions, they can just barely get the project out before somebody pulls the plug on the whole thing. Usually, during this exercise, structured programming takes a back seat to getting the project finished. This is how successful software projects happen. Programmers and their all night programming sessions have become a national joke. I don't know if we'll soon figure out how to make successful large systems. As far as I know, nobody's really got that completely figured out yet, or they'd be turning out a flood of really great programs. I haven't seen that flood yet. In the mean time, instead of structured programming, I have some other ideas: 1) Concentrate much more on what the end user gets than on how structured the program is. Don't let the user's view of the program happen by accident. If the program is interactive, then everything counts here. For example, you even have to take into account the real-time behavior of the program. Page faults or swapin/swapout are no excuse to an end user who is trying to get his work done and the system's performance isn't good. Everything that the user sees the program do is the program developer's responsibility. 2) Look closely at other people's attacks on the problem. Very rarely are you the first or second to tackle any given problem. Learn from others successes and mistakes. Spend a lot of time reading other peoples code. 3) Rely on logical reasoning to decide whether or not something will work. Even if it's perfectly structured, it probably fails under some condition. Use your mind and your logical reasoning skills to make sure that it doesn't. 4) Don't use algorithms that you don't understand. First figure them out, then consider using them. This is especially true of numerical methods. It's not really a very good excuse to the end user to say that the reason that the software failed is because some supposedly black box procedure failed. Understand black boxes. Open them up when you can. 5) Don't kid yourself into thinking that you are sure about how a piece of software will behave when you really aren't sure. If you aren't sure, the software is probably is wrong. Go to step 3) above. 6) Take personal responsibility for every single character that you put into the source. If something is wrong, and you put it there, then it's your fault. ... even if it's perfectly well structured. I'll end this note with a plea. Let's let the structured programming movement die. The computer science field is too young to let that kind of stifling pseudo-science suppress inovation. We need to continue to experiment with entirely new ways to structure programs. The ones we have now are not good enough. Let a thousand new kinds of structuring bloom!
Network Working Group IAB Request for Comments: PPPP January 1989 Ethics and the Internet Status of this Memo This memo is a statement of policy by the Internet Activities Board concerning the proper use of the resources of the Internet. Introduction At great human and economic cost, resources drawn from the U.S. and government, industry and the academic community have been assembled into a collection of interconnected networks called the Internet. Begun as a vehicle for experimental network research in the mid-1970's, the Internet has become an important national infrastructure supporting an increasingly widespread, multi-disciplinary community of researchers ranging, inter alia, from computer scientists and electrical engineers to mathematicians, physicists, medical researchers, chemists, astronomers and space scientists. As is true of other common infrastructure (e.g. roads, water reservoirs and delivery systems, and the power generation and distribution network), there is widespread dependence on the Internet by its users for the support of day-to-day research activities. The reliable operation of the Internet and the responsible use of its resources is of common interest and concern for its users, operators and sponsors. Recent events involving the hosts on the Internet and in similar network infrastructures underscore the need to reiterate the professional responsibility every Internet user bears to colleagues and to the sponsors of the system. To the extent that the Internet resources are provided by the U.S. Government, this responsibility becomes a Federal matter above and beyond simple professional ethics. IAB Statement of Policy The Internet is a national facility whose utility is largely a consequence of its wide availability and accessibility. Irresponsible use of this critical resource poses an enormous threat to its continued availability to the technical community. The U.S. Government sponsors of this system have a fiduciary responsibility to the Legislature to allocate government resources wisely and effectively. Justification for the support of this system suffers when highly disruptive abuses occur. Access to and use of the Internet is a privilege and should be treated as such by all users of this system. The IAB strongly endorses the view of the Division Advisory Panel of the National Science Foundation Division of Network, Communications Research and Infrastructure which, in paraphrase, characterized as unethical and unacceptable any activity which purposely: (a) seeks to gain unauthorized access to the resources of the Internet (b) disrupts the intended use of the Internet (c) wastes resources (people, capacity, computer) through such actions (d) destroys the integrity of computer-based information or (e) compromises the privacy of users The Internet exists in the general research milieu. Portions of it continue to be used to support research and experimentation on networking. Because experimentation on the Internet has the potential to affect all of its components and users, researchers have the responsibility to exercise great caution in the conduct of their work. Negligence in the conduct of Internet-wide experiments is both irresponsible and unacceptable. The IAB plans to take whatever actions it can, in concert with Federal agencies and other interested parties, to identify and to set up technical and procedural mechanisms to make the Internet more resistant to disruption. Such security, however, is extremely expensive and may be counterproductive if it inhibits the free flow of information which makes the Internet so valuable. In the final analysis, the health and well-being of the Internet is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability.
At the Congress, 48 electronic documents including position papers, agenda, press material etc. were available free of charge. Most of the documents are in German (better: Anglo-German techno slang), but several documents are translated in English, French, Swedish and Netherlandish, so people without German language knowledge may get an impression of CCC'88 in their respective language (if available). This document describes the content of the diskette which I received; the electronic documents are essentially in ASCII, except in some German documents where vowel-mutations appear. Name, content and size of each documents are described below. Content is either described by the headline or (if not available) by information selected from the texts (in parentheses), both in the respective language; in the German package, the content is also described in English. The documents are collected in packages, and they are essentially unchanged (I only deleted many blank lines; special non-ASCII characters have not been changed). You may get the package(s) either by e-mail or via traditional post from my address (below). [Note: in Byte counts, "." auf deutsch = "," in English; in dates, 30.12 is 30 December.] Content of Chaos Computer Congress '88 diskette (ASCII files) ============================================================= Package 1: The `Newspaper'/German/Size=51.840 Bytes --------------------------------------------------- ALL.GER ( 51.840 Bytes): Alle deutschen Texte/all German text Package 2: German documents/Size=61.261 Bytes --------------------------------------------- ARMENIEN2.GER ( 923 Bytes): Armenienhilfe (Teil von ARMENIEN.GER) ARMENIEN.GER ( 2.176 Bytes): Armenienhilfe AUFTAKT.GER ( 1.734 Bytes): ***AGENTUR*** Hackerkongress eroeffnet BIOFEED.GER ( 2.125 Bytes): Vortrag: Neue Perspektiven der Mensch-Maschine-Kommunikation ueber Bio-Feedback (new perspectives in man-machine communication via bio-feedback) CCC1.GER ( 3.388 Bytes): Wege zur Informationsgesellschaft (ways towards Information Society) COMKIND.GER ( 1.363 Bytes): Kinder an die Computer - aber zuegig !!! (children should use more computers in school - now!!!) COMPOST.GER ( 1.840 Bytes): Das Oekonetz COMPOST (CCCs econet) CRACK.GER ( 1.748 Bytes): (Informationen ueber Cracker meeting) (inform.about cracker meeting,not CCC) DIARY28.GER ( 4.933 Bytes): 88 Zusammenfassung CCC '88 (summary) DIEBE.GER ( 967 Bytes): Briefmarken fuer 59500 Mark weg (stamps stolen/ relation to CCC'88??) DONNERST ( 1.405 Bytes): Congressfahrplan CCC'88 Donnerst 29.12. (time schedule Thursday, 29 December) EINDRUCK.GER ( 3.749 Bytes): Erste Eindruecke zum CCC-Congress '88 von Ralf Rudolph (first impressions) FIDO.GER ( 786 Bytes): Das FIDO Netz (report about FIDONET) FREITAG.GER ( 1.037 Bytes): Congressfahrplan CCC'88 Freitag 30.12. (CCC time schedule Friday, 30 Dec) HACKER.GER ( 141 Bytes): (Hacker-Witz) [Hacker joke] LEIDEN.GER ( 1.386 Bytes): `Die Leiden des Layouters' oder `Umlaute - die Letzte' (problems of layouting with vowel-mutation) MITTWOCH ( 1.046 Bytes): Congressfahrplan CCC'88 Mittwoch 28.12. (CCC time schedule Wednesday, 28 Dec) NETZE.GER ( 885 Bytes): fido,zerberus,(btx-net) Vortrag/Disk. (CCC networks plans) PACKETRA.GER ( 1.734 Bytes): Packet Radio PC-DES.GER ( 2.083 Bytes): Privater Nachrichtenschutz (PC-DES) (DESprogram protects private messages) PKZ.GER ( 4.758 Bytes): (PKZ, Sicherheits/Sozial-Gesetze) (personal identification code, new social and security laws) POLIT.GER ( 2.067 Bytes): Hacker - Neue Soziale Bewegung? POST.GER ( 2.017 Bytes): 1. Hagener Woche fuer Jugend und Computerkultur (17.10-22.10.88) (report about 1st Hagen week for youth and computer culture, Oct.88) REDEROP.GER ( 6.611 Bytes): (Kongressbeschreibung, Autor ?) (personal congress report, author?) RUECK.GER ( 1.784 Bytes): Vergangenheitsbewaeltigung des Chaos Computer Clubs: Bitte was ? (experience report about Steffen Wernerys imprisonment) RUECKBLI.GER ( 5.238 Bytes): Rueckblick (CCC-Erfahrungsbericht) (CCC experience report including consequences of different hacks) STEFEN.GER ( 327 Bytes): (Steffen Wernery krank) (Steffen Wernery hit by real virus) SYSOPVO.GER ( 837 Bytes): Sysoptreffen: Oeko-Netze/Th.Vogler (Sysop meeting econet) UUCP.GER ( 1.996 Bytes): UUCP (UUCP concepts/networks) UUCP2.GER ( 1.961 Bytes): UUCP - Das Netz fuer Eingeweihte (UUCP concepts/networks, 2nd paper) WAULOCH.GER ( 5.138 Bytes): Ist Lochte gestolpert? (report about a panel discussion about hackers where Hamburgs local Intelligence chief had accepted invitation but didnot appear) Package 3: English documents/Size=9.507 Bytes --------------------------------------------- PCDES.ENG ( 1.527 Bytes): Private message security (PC-DES) POLIT.ENG ( 2.073 Bytes): The Hackers - A new social movement? REDE.ENG ( 2.971 Bytes): (..new human right of free exchange of data.., FREE DATA NOW) ROP.ENG ( 2.936 Bytes): == essentially same as REDE.ENG == Package 4: French documents/Size=12.195 Bytes --------------------------------------------- ABTREI.FRA ( 1.996 Bytes): (sur chiffrage PC-DES) CCC1.FRA ( 3.454 Bytes): Chemins a la societe informatisee CCC1TVS.FRA ( 3.420 Bytes): == essentially same as CCC1.FRA == DES.FRA ( 1.996 Bytes): (sur DES-programme) FRANZ_2:FRA ( 3.325 Bytes): Ralf Rudolph: premieres impressions du congres CCC'88 Package 5: Swedish documents/Size=10.920 Bytes ---------------------------------------------- ARMENIEN.SWE ( 1.320 Bytes): Kan man aennu raedda tyska byraakratien? Obyraakratisk hjaelp foer Armenien blockerar ! CCC1TVS.SWE ( 2.922 Bytes): Freedom of Information HAGEN.SWE ( 3.598 Bytes): Det som Faschismen inte klarade av: det enhetliga Personnummern kommer nog! HAGEN2.SWE ( 1.149 Bytes): Barn, set er vid datorerna - men snabt RUECK.SWE ( 1.493 Bytes): Behaerskningen av det foerflutna i Chaos Computer Clubben: Foerlaat, vad? UUCP.SWE ( 1.758 Bytes): UUCP-Foeredrag Package 6: Netherlandish documents/Size=8.545 Bytes --------------------------------------------------- MARKTHAL.NIL ( 1.889 Bytes): PODIUMDISCUSSIE CCC CONCENTREERT ZICH OP GEVAREN NIEUWE COMMUNICATIETECHNIEK REDE.NIL ( 6.656 Bytes): TOOSPRAEK `HACKEN IN HOLLAND' door Rop Gongrijk PostAdress: Prof.Dr. Klaus Brunnstein, Faculty for Informatics, Univ.Hamburg, Schlueterstr.70, D 2000 Hamburg 13 Tel: (40) 4123-4158 / -4162 Secr. ElMailAdr: Brunnstein@RZ.Informatik.Uni-Hamburg.dbp.de FromINTERNET:Brunnstein%RZ.Informatik.Uni-Hamburg.dbp.de@Relay.CS.Net FromBITNET: Brunnstein%RZ.Informatik.Uni-Hamburg.dbp.de@DFNGate.Bitnet FromUUCP: firstname.lastname@example.org
Please report problems with the web pages to the maintainer