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: brunnstein%rz.informatik.uni-hamburg.dbp.de@unido.uucp
Please report problems with the web pages to the maintainer