[ Skip Navigation] [CSUSB] / [CNS] / [Comp Sci & Eng] / [RJBotting]. Search
[My image] [Text Version]
blog008 Wed Jun 16 15:13:31 PDT 2010
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).


    RJBottings Web Log 2008

      2008-12-22 Mon Dec 22 09:12 Contributions

      I'm very pleased to get the following Emails. I will be posting them to [ samples/etc.html ] Real Soon Now.


        First, I would like to thank you for maintaining the resource at csci.csusb.edu/dick/samples/etc.html as it has been of great help to me in my studies.

        Second, since I noticed that you are interested in suggestions, I know of a really useful resource on computer science, and thought I might pass it on.

        The website address is [ compsci.html ] and it contains both computer science degree information and subject resources (math, programming, journals, links etc).

        I think professionals and students alike might find good use for it. I personally appreciated the programming section with the tutorials and guides to different programming languages.

        Anyway, let me know what you think!

        Regards, Joanna



        We have looked through the following page on your site: [ etc.html ]

        and noticed that you have a "jobs" section in which several sites were listed.

        We would like to recommend the addition of our site Careerjet [ http://www.careerjet.com ] , an employment search engine for the USA. In one simple search, Careerjet gives the job seeker access to a massive selection of jobs that are compiled from various internet sources, saving the trouble of having to visit each site individually.

        Some of our embeddable tools might be of interest to you: JobBox - [ jobbox.html ] SearchBox - [ searchbox.html ]

        We hope this site will interest you and can be included in your listings.

        Thank you.

        Kind regards,

        Emily Kovak

      2008-12-17 Wed Dec 17 19:12 Happy Holidays

      The server went wrong again during the weekend and the snow separated the systems administrator from the servers.... hence no recent posts.

      I've decided to give this blog a holiday, until January 5th.

      I wish you a happy holiday... snow if you like snow, and no snow if you get trapped in it...

      I'll be back with some more recent readings in software development in 2009.

      I'll be dropping into FaceBook as "Richard John Botting" and LinkedIn as well...

      I'll probably change the "look and feel" of this web site during the break.

      See you next year.

      2008-12-11 Thu Dec 11 15:12 Computability

      Here is a nice introduction to current thinking on problems that have no computer solution, or have known efficient solution. It is as well for a practitioner to know, in advance, that certain problems are effectively off-limits.


      1. David Lindley
      2. The Limits of Computability
      3. Commun ACM V51n11(Nov 2008)pp17-19 [ 1400214.1400219 ]
      5. Interesting problems have solutions that are easy to check, but not before you have found one.

      2008-12-10 Wed Dec 10 19:12 Social Networks

      Several entries in this blog in the last year have been about social networks. It is an interesting topic especially now that we have systems that are driven by social networking. My interest is also because of an important principle that I've never seen stated before -- even though it is one that I have used it for decades. This is the Principle of Software Eversion. It states that any important question or property of a piece of software can be everted to become a question or property of the environment in which the software operates. Thus by investigating the environment we learn properties that can be everted -- turned inside-out -- to derive the structure of the software. Thus the question: how can a web site grow by volunteer contributions without being perverted to other purposes can be everted to ask what social networks have been and are successful. In particular, I want to open up parts of this site, but not lose its focus of software and mathematics. The idea of eversion and turning software inside-out comes from William Gibson's Neuromancer series and more recently in `Spook Country`. I'm not sure I've got what he means. My use here, is my own.

      Anyway, enough of me. Here we have two items on social networks. One historical and the other statistical. They agree with other observations documented below, see Nexus, Kleinberg08, Shirky08, and Weber05.


      1. David Alan Grier
      2. Edward Elgar's Facebook Page
      3. IEEE Computer Magazine V41n11(Nov 2008)pp6-8
      4. =ESSAY SOCIAL NETWORKS SCIENCE invisible colleges Email cell-phones
      5. How "Pomp and Circumstances" became the graduation song because of Elgar's social network.
      6. invisible_colleges::="Concluded that loosely organized groups drive scientific research", Derek de Solla Price 1960s.
      7. Connection can have different strengths. Weak connections can be important -- if they distribute a message widely or allow wide collection of data.
      8. Maintaining an invisible college can take time and travel.


      1. Bernardo A Huberman
      2. Crowdsourcing and Attention
      3. IEEE Computer Magazine V41n11(Nov 2008)pp103-105
      4. =SURVEY WEB/NET OPEN SOURCE WIKI SOCIAL NETWORKS HP Labs YouTube Digg Twine FaceBook Google MySpace
      5. The publish and filter model.
      6. Many casual contributors and a core ofcommitted editors.
      7. Social capital: payment in the form of attention.
      8. Distribution of attention is highly skewed: just a few get nearly all the attention.
      9. law_of_surfing: probability of n pages being surfed declines rapidly with n. Google position.
      10. Book recommendations: different areas have different types of networks. [ viral-ec06.pdf ]
      11. Social structure influences the flow of Information.
      12. Attention tends to lead to more attention via the networks. But once an item is no longer novel, attention to it declines.
      13. Stats on Digg sites. Attention is log-normal and decays slowly as a stretched exponential.
      14. Similar patterns with traditional published papers.
      15. Possible effects of style, popularity, ...

      2008-12-10 Wed Dec 10 10:12 Hiatus Over

      Well the servers are all running.... and I can now update my web pages/blogs/grades/....

      However, I've left my special "computer"/"VDT" glasses at home. My normal glasses are bifocal and when I look at a computer screen my neck is stretched and twisted enough to make it hurt. In time this gets rather bad and I have to stop.

      So "Normal service will be resumed as soon as possible".

      2008-12-09 Tue Dec 12 10:17 Hiatus

      The CSE dept servers went down over the weekend. The web server is up but the lab machines and the SSH server is still off line.

      As a result I'm suspending my usual week day editions of this blog.

      2008-12-05 Fri Dec 5 14:12 Graphics for Large Data Sets

      Here is a topic that fascinates me: methods and tools for representing complex data using graphics. The paper below describes a new system:


      1. Chris Stolte & Diane Tang & Pat Harahan
      2. Polaris: a system for query, analysis, and visualization of multidimensional databases
      3. Commun ACM V51n11(Nov 2008)pp74+75-84
      5. Introduced by Jim Gray.
      6. applied to software, GIS, etc.
      7. Previous version: IEEE Trans Visualization and Computer Graphics V8n1(Jan 2002)pp52-65

      By the way -- this is the first of these bibliographic items to be written on my iPod and eMailed to my work address, and cut and pasted into these files. I'm wondering why there is no copy/paste on an iPod. This changes the way it is used drastically.

      2008-12-04 Thu Dec 4 14:12 Shapes of Social groups and networks

      First a fun application for FaceBook people:
    1. Nexus::= See http://nexus.ludios.net, in return for giving it your face book data it draws a graph of the connections between your frinds. Very interesting.

      I found it illustrating the following article:


      1. Jon Kleinberg
      2. The Convergence of Social and Technological networks
      3. Commun ACM V51n11(Nov 2008)pp66-72 [ 1400214.1400232 ]
      5. Evidence that real social networks are "small worlds" as predicted.
      6. Evidence that ideas spread in jagged trees through the network.
      7. "Contagion as a Design Priciple"

      2008-12-03 Wed Dec 3 14:12 History of Open Source F/OSS

      It appears that the computer industry started out sharing source code and is now returning to that model. The history makes it clear that it is hard to predict the future.


      1. Martin Campbell-Kelly
      2. Historical Reflections -- Will the future of software be open source
      3. Commun ACM V51n10(Oct 2008)pp21-23 [ 1400181.1400189 ]
      4. =HISTORY 1950s-2000s OPEN SOURCE F/OSS
      5. Initially source code was distributed with the executables and libraries.
      6. Unsuspected technologies have and will disrupt predictions.

      2008-12-02 Tue Dec 2 13:12 Data Models and PDAs

      I'm in the midst of shifting platforms for my PDA. I've had some kind of personal data assistant since the 1980's. I'll be writing about the history going back to a paper I presented in 1985 on the agile way that I developed code for a TRS Model 100 laptop.

      Meanwhile I'v discovered that a Palm Pilot is the procrastinator's best friend -- it is so easy to write up a task "to do" and repeatedly put it off. Even worse is the 1Mb of memoranda of thoughtd, facts, formula, etc that I can not easily move from a Palm to an iPod. Why? Because the note application on the iPod does not synchronize to a readable desk top application. So I can't just transfer Palm memos to iPod Note. The iPod has no Copy/Paste feature. So you can not easily move notes into the calendar or from calendar to notes, Email or a Web form.... So I'm starting to move public data from my memos to the web where I can get read it on the iPod. See [ samples/reference.html ] for the first 100 or so random notes...

      All these problems come from the different data models betwen Palm and iPod. There is an architectural mismatch between an evolved PDA and a evolved MP3 player/Cell Phone. This the kind of observation made by Wilde and Glushko below:


      1. Erik Wilde & Robert J Glushko
      2. Document Design Matters
      3. Commun ACM V51n10(Oct 2008)pp43-49 [ 1400181.14001945 ]
      5. Web applications evolve. Not top-down design. Can not have a "one true model". Must connect to different models adopted by different subsystems.
      6. XML doesn't make it easy to share data. See [ WildeGlushko08 ] below
      7. REST::="REpresentational State Transfer".
      8. Need to involve the consumers of data in the design of documents.

      2008-12-01 Mon Dec 1 13:12 New Code Exploring Tools

      I've always found the UNIX tool set (see [ Kernighan08 ] below) plus the ability to speed read an effective toolset for understanding code. Prior to UNIX I once found myself hopelessly lost inside 8K of machine code -- numerical machine code -- no labels or mnemonics -- just numbers. I was drawing page after page of flowchart when I was saved by a professor who asked me what I was doing.... and suggested I ask the company for the documentation. Which I did -- pseudocode. Very helpful. But these days I guess I'd use more complex tools. Here is a recently reported pair: Doxygen and DTrace.


      1. George V Neville-Neil
      2. Code Spelunking Redux
      3. Commun ACM V51n10(Oct 2008)pp36-41 [ 1400181.1400194 ]
      4. =DEMO TOOLS CODE Doxygen DTrace

      2008-11-26 Wed Nov 26 14:11 Mashups and reuse

      Just before this blog takes a holiday break he is a source of information on the ancient but dishonourable activity of making software by combining components that were not intended to be connected.

      IEEE Software Magazine has had a special issue on creating software by combining components that were not design to work together. An interesting discussion of a process that has existed for decades and is growing more powerful and prevalent.


      1. Cornelius Ncube & Patricioa Oberndorf & Anatol W Kark
      2. Opportunistic Software Systems development: Making Systems from what is available
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp38-41
      5. OSSD::="Opportunistic Software Systems development".
      6. Introduces a special section -- pages 42-83.
      7. Comparison with "Junkyard wars"/"Scrapheap challenge".
      8. Argues that the market forces the assembly of systems from components that where not intended for combination or even reuse.
      9. Tends to require a different process: ad hoc, experimental prototyping, scavenging, attending to mismatches, smart engineering, creativity, innovation, imaginative gluing software pieces together.
      10. Need to develop combinations and negotiate requirements later about gaps with stakeholders.
      11. Architecture tends to evolve.
      12. Risk of architectural mismatches (Boehm).
      13. Mostly treat components as black boxes.
      14. Testing "is the main disadvantage".
      15. Need for fast release, collaboration, cooperation, and negotiation.
      16. Good for startup companies.
      17. Need a different curriculum -- closer to traditional engineering -- with more systems setup support(Obrenovic & Gasevic & Eliens).
      18. (dick)|-in one sense nothing new here, but an acknowledgment of an existing process.
      19. Also see [BoehmBhuta08] [Jansen08]


      1. Barry Boehm & Jesal Bhuta
      2. Balancing Opportunities and Risks in Component-based software development
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp56-63
      5. ICM::acronym="Incremental Commitment Model",
      6. ICM::lifecycle=exploration; valuation; foundations; develeopment & foundations; do(Operations & Development & Foundations ).
      7. Mentions example of an architectural mismatch leading to a 4 times over-run, taking 5 person-years rather than 1.


      1. Slinger Jansen & Sjaak Brinkkemper & Ivo Hunink & Cetin Demir
      2. Pragmatic and opportunistic Reuse in Innovative start-up companies
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp42-49
      5. Page 43 has a useful table and figures showing 8 different ways components can be connected.
      6. how_to_mashup::=following,
        1. Send object through filter.
        2. Use method calls.
        3. Write glue code.
        4. Components share a data object or data base
        5. Use a component bus like CORBA
        6. Use a plugin architecture as in Java and Eclipse.
        7. Use network and services -- MySQL, SOAP, ...
        8. Enterpise service bus passes calls to best component to provide service.

      2008-11-25 Tue Nov 25 13:11 Reality Bytes

      This from the "Blinding glimpse of the obvious" department. It turns out that programmers are less than honest when estimating projects and reporting progress, and other things.


      1. Robert L Glass & Johann Rost & Matthias S Matook
      2. Lying on Software Projects
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp90-95
      5. Lies observed: Estimation(commonest), Status Reporting, Politics, Hype(rarest).

      2008-11-24 Mon Nov 24 14:11 A dose of reality about software process improvement

      I turns out that not every body is madly enthusiastic about software improvement -- some people resist it. Even people on an process improvement team can work to slow the process. It was ever thus.... but it is nice to see empirical evidence published in a reputable magazine about software development.


      1. Anna Borjesson Sandberg & Lars Mathiassen
      2. Managing Slowdown in Improvement Projects
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp84-89
      5. People can: not show up, delay answers, say nothing, not implement.
      6. Two factors: commitment & motivation >< allocation of personal resources.
      7. Proposes techniques for each problem. Example: if people don't show up -- go to them, measure and report participation, replace them, perhaps reorganize the team...

      2008-11-21 Fri Nov 21 15:11 A tool to help program maintenance


      1. Martin P Robilard
      2. Topology Analysis of Software Dependencies
      3. ACM TOSEM Trans Software Eng & Methodology V17n4(Apr 2008)#17pp1-36 [ 13487689.13487691 ]
      5. Given fuzzy set of items of interest gives most relevant items highest membership in set of cross references.
      6. Most important are listed first -- have more membership in relevant items set.
      7. References are weighted by their specifity and reinforcement.
      8. Defines an different fuzzy set union:
      9. (A or B)(x) = A(x)+B(x)-A(x)*B(x).
      10. (dick)|-Looks like probabilities rather than fuzziness!
      11. Evidence that tool is useful.

      2008-11-20 Thu Nov 20 15:11 Unconferences

      Here is a novel idea -- a conference where people don't get bored listening to prepared powerpoint presentations....


      1. Mark Ingebretsen
      2. Unconferences catch on with Developers
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp108-110
      4. =REPORT SELF-ORGANIZING MEETINGS ORGANIZATION PEOPLE FOOcamps BarCamp DemoCamp Web2Open openspace meetings Eclipse Microsoft Canada
      5. Tools for planning, problem solving, and product invention and development.
      6. 1983 Harrison Owen: why not a conference made up of coffee breaks only ----> Open Space Technology. More done in two days than months done other ways.
      7. Wiki [ http://www.barcamp.org ]
      8. Several frameworks. Before: announce a real important goal. Initially participants list issues to meet goal. People select breakout sessions on issues. Breakout session activity is recorded. Records put on Wikis and/or blogs. Groups may report back in a plenary session.
      9. "You need to have places where people can just bump into each other".

      2008-11-19 Wed Nov 19 20:11 Proofs by Computer in Mathematics

      I picked up the following reading in my ACM Technical News Emailing. [ ams-pbc110608.php ]

      It appears that mathematicians have been forced by the complexity of the proofs they are writing to use computer programs to verify the proofs. It turns out that the best of the programs act as proof assistants helping the user to discover the necessary methods and lemmas to make a proof. This is very much a feature that I've desired for my MATHS system. It was designed so that you write proofs and check them automatically. I've been looking for some graduate student to develop the parser and checker. Meanwhile it turns out that there are a half-a-dozen popular proof assistants being used to prove non-trivial theorems. The links in the citations below.

      I had hopes of a gigantic repository of MATHS results on the web to make the construction of proofs easier -- compare with QED below.

      Another parallel is the use of a theory of types in HOL_light, Coq, and my own MATHS.

      I'm hoping that MATHS may give more readable proofs than the ones described in these papers. I have samples [ samples/index.html#Some%20Simple%20Examples%20of%20Math%20in%20Use ] (for example) and [ maths/logic_20_Proofs100.html ] (informal hints) and [ maths/logic_25_Proofs.html ] (rules).


      1. Unknown Editor
      2. Special Issue on Formal Proof
      3. Notices of the American Mathematical Society V55n11 (Dec 2008) [ http://www.ams.org/notices/200811/ ]
      5. Includes Hales08, Gonthier08, Wiedijk08 (below).


      1. Thomas Hales
      2. Formal Proof
      3. Notices of the American Mathematical Society V55n11 (Dec 2008) [ tx081101370p.pdf ]
      5. Good discussion of the philosophy of formal proofs and HOL Light in particular.
      6. Difficult theorems can have 1728 pages for an informal proof and take decades to write.
      7. Provide formalizations can take years.
      8. DeBruijn_factor::=Length of a formal proof/Length of a conventional proof.
      9. List of 12 "real" theorems that have got formal proofs.
      10. Description of HOL_light.
      11. Discussion of full automation and automated discovery of theorems.
      12. Coq::proof_assistant= See http://coq.inria.fr/.
      13. HOL_light::proof_assistant= See http://www.cl.cam.ac.uk/~jrh13/hol-light/.
      14. Isabelle::proof_assistant= See http://isabelle.in.tum.de/.
      15. Mizar::proof_assistant= See http://mizar.org/.
      16. ProofWeb::online_proof_assistant= See http://prover.cs.ru.nl/login.php.

      17. QED::manifesto= See http://www.cs.ru.nl/~freek/qed/qed.html.


      1. Georges Gonthier
      2. Formal Proof -- The Four-color Theorem
      3. Notices of the American Mathematical Society V55n11 (Dec 2008) [ tx081101382p.pdf ]
      5. This formal proof of the famous four-color theorem uses Combinatorial Hypermaps not Graphs!
      6. Coq and the calculus of Inductive Constructions (CiC).
      7. Inference subsumed into type inference?


      1. Freek Wiedijk
      2. Formal Proof -- Getting Started
      3. Notices of the American Mathematical Society V55n11 (Dec 2008) [ tx081101408p.pdf ]
      5. Describes the leading proof assistants and theorems that have been proved.
      6. Describes how to get the tools and use them.

      2008-11-18 Tue Nov 18 15:11 More on Ruby on Rails

      Just a demonstration of how easy and simple it is to implement a simple web-based application using the "Ruby on Rails" framework/platform. Note -- I hear that this approach does not scale to applications that do not follow the commonest paradigms. For details on Ruby see the links on [ samples/languages.html#Ruby ] and for other introductions try [Geer06] and [BachleKirchberg07]


      1. Viswa Viswanathan
      2. Rapid Web Application Developmnet: A Ruby on Rails tutorial
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp98-106
      4. =DEMO Ruby Rails WWW/NET MVC

      2008-11-17 Mon Nov 17 16:11 More on WYSINWYG

      I had another example of WYSINWYG this morning. I sent of a review of a paper in CACM to Computer Reviews (CR) and previewed it to see what errors had crept in. I copy/pasted the preview into an EMail and sent it to my work EMail address for my records. When it arrived I found it had about a dozen invisible GIFs in it. The iMac Mail showed them as attachements containing nothing. MS Outlook (at work) got scared an refuesed to open them.

      Life was a lot easier when the only code was ASCII:-)

      Meanwhile today was fresher orientation, lunch, seminar, and a heavy editting session on techniques for expressing rules and procedures. Next comes another seminar and a bus ride home to picadillo and a spud.

      2008-11-15 Sat Nov 15 09:11 Update to Previous Entry

      I delayed adding a link to Matt's flyer until I could find a copy that was not WYSINWYG.
    2. WYSINWYG::="What You See Is Not What You've Got".

      The PDF of the thesis has an abstract that includes invisible character strings which are hard to detect and difficult (as a result) to replace by the correct strings. I had to log into the campus mail server and dig through my sorted mail to find a WYSIWYG "doc" file and upload that.

      We also have to more seminars on Monday, see [ seminar/ ] for details of upcoming events.

      2008-11-15 Sat Nov 15 08:11 Yesterday was Busy

      Friday was full of seminars and so I'm posting this entry one day late. I did think of just jotting my notes into this blog during the presentation but that looks like I'm not focussing on the speaker -- distracting and rude.

      My day started at 5am by sending a draft review of [Henning08] to CR (Computer Reviews). They have a site that lets you save a draft, print it, review it, spot an improvement, and change it, before you finally submit the review. I find that such an iterative process is the only way I can "write" good stuff. I will return to this theme in a future item on "writing code". But it a similar cycle: draft, render, edit, and submit is built into the tool I developed this summer to send things to this blog and web site.

      The first seminar was presented by Aram Acemyan who is one of our undergraduates who worked on Bioinformatics at California University, Santa Barbara last summer. His work was developing a tool for comparing a two methods of detecting 3D nuclei. For example it will see whether two humans have found the same nuclei in a photograph or whether a particular algorithm matches a human "Ground truth". His presentation [ seminar/20081114AramAcemyan.txt ] described the iterations his program went through.

      I was on the committee for the next seminar. Natalie Wiser-Orozco presented [ seminar/20081114NatalieWiser.txt ] her MS CSCI thesis on simulating the movements of planets and comets. She reviewed the development of Kepler's and Newton's laws and how they lead to an extensible piece of software -- using Python and Scilab -- for planetary simulations. This include rendered planets and solving the n-body problem numerically. The model of the Sun, Mercury, Venus, the Earth, and its Moon was run as a demo. A nice piece software and ripe for further growth. For example we all discussed the possibility of running a simulation of the new planetary system photographed recently -- 3 super-large planets orbiting a star only slightly larger than our sun.

      Then we had lunch.

      After Lunch: [ seminar/20081114.txt ] Chen-Yu Lin described the application of Reinforcement Learning to playing Blackjack. He showed how a learning algorithm compared with the Greedy algorithm in a simplified version of blackjack.

      Then Matt Richardson presented his Interdisciplinary Master of Arts thesis: "PYSAFE: AN INTERDISCIPLINARY APPROACH TO INTERFACE DESIGN". [ seminar/20081114MattRichardson.txt ] This surveyed the history of Human-Computer Interaction design and tested out a model process based on the ideas in the literature. First develop a rough mock up of the design, then work on the machinery behind the mock up.... and iterate. This lead to a long discussion of the possible next steps with the software.

      Interesting -- every project presented used Python [ samples/python.html ] as part of their technology.

      2008-11-13 Thu Nov 13 15:11 The Promise of this blog and website

      Clay Shirky (Developing_a_resource next below) notes that a social web site starts with a promise, followed by a tool that facilitates the promise, and if it work, ends up with a more or less explicit social bargain made by the people taking part.

      I'v been thinking about the "promise" of this web site. I think there are several:

      1. If you tune in each work day I will share some thought or reading on software development.
      2. If you send me a contribution I will (if clean, scamless, and relevant) publish it here with full acknowledgement. [ hole.html ]
      3. Researchers and graduate students can serch the bibliography. [ lab.html ]
      4. Citations/Reviews can be added to the bibliography -- same method, same promise.
      5. You can look at samples of formal definitions and proofs. [ samples/ ]
      6. You can add to them -- same deal. [ samples/hole.html ]
      7. You can look at the system I use and the logic and mathematics involved. [ maths/ ]
      8. You can submit additions and changes to the repository and syntax. [ maths/hole.html ]

      But thinking about the idea of making a hyperlinked corpus of useful information means that there is another way to grow it. This is by linking pages kept on other servers to and from this site. This may be the best way.

      I'll return to this thought when I review the recent set of articles published by the American Mathematics Society (AMS) on "Formal Proofs".

      By the way my review of [SchneiderSEtAl06] has been published in Computer Reviews October 2008 #0810-0985.

      Meanwhile.... off to class.

      2008-11-12 Wed Nov 12 18:11 How the net and good design changes the world

      Clay Shirky's new book is well worth reading if you are planning to put a new "social networking" site up. He describes the rulles and patterns that work, and those that fail. This is an easy to read exercise in sociology. It is to be treasued for the readability alone.


      1. Clay Shirky
      2. Here comes everybody
      3. Penguin NY NY 2008 HM851 S5465 ISBN 978-1-59420-153-0
      5. Net lowers cost of communication, publication, copying, collaboration to ZERO. So a lot more of all of these.
      6. More is Different. Faster is Different.
      7. New paradigm: Publish; Filter.
      8. Many attempts, failure is free, on the way to one big success.
      9. A shared resource needs motivated people and people need Face-to-face meetings.
      10. Developing_a_resource::= Promise; Tool; Bargain.
      11. Examples: Usenet FlashMobs F/OSS Linux SourceForge Flickr MySpace FaceBook MeetMe EBay Wikipedia Wikitorial Encarta
      12. Also see short article [Shirky03]

      2008-11-11 Tue Nov 11 06:11 Classic Computer Languages from the past -- PMS and ISP

      This web log is about software development -- the tools, methods, technologies, processes, and people involved. But today's citations are about describing hardware. I dug them out for a colleague. Evry 5 years or so I go back to these two works. The languages have some novel ideas. So I want to record them here and in my bibliography for future reference.

      The PMS language describes computer systems at the Processor-Memory-Switch level. It has something of the power of a UML deployment diagram. However it does not show any software artifacts, but has a rich and well defined language for describing the qualities/attributes/properties of the "nodes" in the system. In fact PMS is one of the few computer languages to define a syntax for units so that you can specify a switch as handling 2000 char/s (in MATHS: 2000.char/sec). This was in my mind when I defined the MATHS system from dimensioned numbers.

      ISP is the Instruction Set Processor language and is a forerunner for languages like Verilog and VHDL.

      Two thoughts.

      1. If you ever need to know about the hardware from 1960-1971 the second citation (BellNewell71 below) is a definitive survey.
      2. If you are a student looking for an independent study, honors project, or masters thesis then I'm willing to supervise work on PMS leading to a description in MATHS in my [ samples ] directory.


      1. C Gordon Bell & Allen Newell
      2. The PMS and ISP descriptive systems for computer structure
      3. Proc AFIPS Spring Joint Comp Conf (??? 1970)pp351-374 [ PMS%20and%20ISP%20Descriptive%20Systems%201970%20c.pdf ] (PDF)
      4. =IDEA HARDWARE DESCRIPTION PMS Processor-Memory-Switch ISP Instruction-Set-Processor
      5. Also see [ BellNewell71 ] for details and examples of ISP and PMS.


      1. C Gordon Bell & Allen Newell
      2. Computer structures: Readings and examples
      3. McGraw-Hill computer science series circa 1971 ISBN 0070043574 TK7888.3.B37

      2008-11-10 Mon Nov 10 14:11 PSP TSP Tool

      I just put my PPI report [ PPI08.html ] online. This report explains what I been doing since my last promotion in the hope of winning a raise. A common managment technique for raising productivity ... even if it seems to slow me down as I collate the data and write the report. Now this is also the complaint made about PSP and TSP. And one of the solutions is to automate the data collection and report generation. There are several tools. I've just been told (thank you Paul Conrad) about this one. Let me know if you have any data.


      1. Project Dashboard Initiative
      2. Project Dashboard
      3. Sourceforge [ http://processdash.sourceforge.net/ ]
      5. Notes [click here [socket symbol] if you can fill this hole]

      2008-11-07 Fri Nov 7 10:11 Poppy Day

      Veteran's Day was called Armistice Day at first.

      In the UK (where I was born) it is now called Remembrance day. On the 11th of November just about every body buys and wears a little red poppy in remembrance of those killed in war. The money donated when you get your poppy goes to support veteran's and widows.

      A Remembrance Day Poppy

      The poppy was chosen because of the poppies growing in the battle fields in France during the first world war (1914..1918). They are a symbol of sleep and so death. Please visit [ http://www.poppy.org.uk/ ] for more information.

      Meanwhile I plan to change the background of some frames on this web site in memory.

      2008-11-06 Thu Nov 6 14:11 Open Source research needed

      I've been tracking the Open and Free Source movement for a long while. I've used it since BSD2.9 got our first UNIX mini running on campus here in the 1980s. I've collected several dozen books, articles, and papers... and yet according to Carlos Santos there are so many things that we don't know -- like who is really doing the work and what corporations get out of letting their people work on an open/free project.


      1. Carlos Santos Jr.
      2. Understanding Partnerships between Corporations and the Open Source Community: A Research gap
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp96-97
      4. =SURVEY OPEN SOURCE Sourceforge
      5. Research has focused on volunteers not on employees encouraged to work on open source. Similarly literature is about companies letting their source code go open.
      6. No research showing where the effort com es from and how it translates into profits.

      2008-11-05 Wed Nov 5 14:11 Catching up with Requirements History

      As noted below, I missed recording some research that Maiden08 considers very important. So I have back tracked to it to see why. It turns out that this was in the area of modeling the stakeholders "Reality" and that I have papers on the need to do this -- including ontologies before they were ontologies -- back to the late 1970's. So the following provide evidence of the value of this approach. The second item is a retrospective on the technique and mentions the need for what I've been calling "Qualities" as part of the requirements -- again since the 1970's.


      1. Alexander Borgida & Sol Greenspan & John Mylopoulos
      2. Knowledge Representation as the Basis for Requirements Specifications
      3. IEEE Computer MAgazine V18N4(Apr 1985)pp82-91 [ MC.1985.1662870 ]
      5. Also see what happened [BorgidaGreenspanMylopoulos94]


      1. Alexander Borgida & Sol Greenspan & John Mylopoulos
      2. On formal requirements modeling languages: RML revisited
      3. SIGSOFT Proceedings of the 16th international conference on Software engineering pp135-147 .See
      5. Also see [BorgidaGreenspanMylopoulos85]
      6. Need QUALITIES -- non-functional requirements NFRs.

      2008-11-04 Tue Nov 4 14:11 Interaction Design -- a history

      The word design is highly overloaded. It can mean a process or a product. When applied to software it can indicate the user's view of the product or the internal structure of the product. One of the clearest thinkers (and best writers) has just been interviewed about his contribution to "outside design": how to make the conversation or interaction between a machine and a human something that is good rather than bad.


      1. Jeff Patton
      2. A Conversation with Alan Cooper: The Origin of Interaction Design
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp15-17
      5. "it's creativity all the way down".
      6. Principles_of_interaction_design::={Efficacy, Conceptual Integrity, Grammar structuring primitives, Mapping control to use, Trustworthiness, Engagement}.
      7. See
        1. The Inmates are running the asylum [Cooper99]
        2. About Face [Cooper95]

      2008-11-03 Mon Nov 3 10:11 Requirements -- a History

      Neil Maiden has put together an excellent history of the theory and practice of requirments engineering. Most enjoyable and indicating that some things I've missed over the years -- in particular the spread of AI techniques into the techniques for expressing what stake holders wnat and need.

      In the folloiwng I've added links to items in my bibliography that may not be the same as the ones that Maiden cites. Where thre are no links there is an oportunity to add some items to my bibliography -- click here [ hole.html ] if you can fill in the gaps, and your work will be acknowledged in this blog and add to the 4k items in the bibliography.


      1. Neil Maiden
      2. Requirements 25 years on
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp26-28
      4. =HISTORY 1983-2008 REQUIREMENTS
      5. 14 references
      6. 1970s: Requirements were monolithic and used natural language with "noise, silence, contradiction, ambiguity, and wishful thinking". VDM [Bekic70] and JSP [Jackson75]
      7. available but not used. Pencil and Paper
      8. 1977: Ross [Ross77] developed SADT notation (IDEF) and method [Ross85] and story telling.
      9. 1978: [Jackson78] System maintains a model of reality. Leads to JSD in the 1980s
      10. 1979: DeMarco [DeMarco79] , Gane&Sarson [GaneSarson79] , Yourdon [Yourdon75] & Constantine. DFDs. Logical vs Physical. STDs. Functional decomposition. Informal diagrams. structured analysis and design. First CASE tools help draw informal graphics.
      11. 1980s: Greenspan. Semantic networks, logic, frames model knowledge about situation. RML: the model is collection of objects of different types. Ontology: entities, activities, assertions. Leads to TROPOS, i*, KAOS (Knowledge Acquisition in Automated Specification). Goals and Constraints. Expert systems.
      12. 1980s: Stakeholders have difficulties articulating requirements. So, repertory grids, card sorting, Laddering.
      13. 1990s: Ethnography, HCI. Complexity of the working environment.
      14. 1998: Beyer & Holtzblatt [BeyerHoltzblatt94] [BeyerHoltzblatt95] : Contextual enquiry.
      15. 1999: Vicente: Cognitive work Analysis
      16. 2004: [MaidenGizikisRobertson04] : Inventing requirements.
      17. Today: better at identifying stakeholders, use cases and scenarios, quality requirements, reasoning about natural language, multiply viewpoints, detecting and handling conflicts, social techniques, Tracing requirements, tailoring to different domains, training analysts.
      18. Meanwhile: We are tackling larger and more complex systems.
      19. Also see [Maiden05] on requirements research.

      2008-10-31 Fri Oct 31 13:10 Old tools still useful

      Sometimes it is very comforting to read that someone else agrees with you. Especially if that person is a well respected expert who does not know you. Hence my pleasure in Brian Kernighan's contribution to the celebration of IEEE Software's 25th Anniversary, below.

      I'd add a single thought: he uses these tools for handling code. I've also used them for analysis and design. As long as you stick to a line oriented format -- tables with tabs between columns, one short sentence or formula per line -- then the UNIX tools are still powerful and helpful. I'd also add sed and awk to his list. Then you can do Keyword In Context (KWIC) searches which are very handy...


      1. Brian Kernighan
      2. Sometimes the Old Ways are best
      3. IEEE Software Magazine V25n6(Nov/Dec 2008)pp18-19
      5. Old tools still good and useful: grep, diff, sort, wc, find, shell scripts
      6. Good tools: do something better than manually, available everywhere, can be used creatively, not to specialized or intelligent.
      7. Need for tools to ashare a uniform representation -- for example ASCII.
      8. "I can often have the job done while experts are still waiting for the IDE to start up."

      2008-10-30 Thu Oct 30 06:10 Sorry for the Vanishing Home Page

      It looks like that on October 28th I used the wrong tool to create my home page -- and removed a fair chunk of it. I make occasional back ups of my web pages and backtracked to a 2006 version ... that may have some broken links. The result has been uploaded and can be seen at [ index.html ] in the maion "body" frame. Let me know if you spot any broken links.

      2008-10-29 Wed Oct 29 09:10 Grammars used in Model Checking

      I've been arguing for using grammars in the analysis and design of systems and software since I was trained in Jackson Structure Programming in 1979. Prior to that I just use them for language design and translator construction. Basically a grammar is a natural way to define the possible patterns of data fowing in and out of a process. Further, using some sophisticated coding techniques, the grammars lead directly to a structure for the code that is guaranteed to work -- and reflect the client language and data. Pretty cool. But it is not inexpensive, needs special training, and the code is interesting. If you'd like to see what I mean try [ tools/br.ansi.c ] a C program to word-wrap (BR-eak) a piece of text. The structure of the program reflects two grammars that can be drawn like this [ tools/br.d.in.jpeg ] and [ tools/br.d.out.jpeg ] while the whole derivation of the code (using MATHS) is in [ tools/br.d.txt ] and [ tools/br.d.html ] (rough HTML).

      Now someone have found another way to use grammars. You can express the possible calls and returns to an Application Programmers Interface and check that software is following the rules:


      1. Graham Hughes & Tevlik Bultan
      2. Interfaces Grammars for Modular Software Model Checking
      3. IEEE Trans Software Engineering V34n5(Sep/Oct 2008)pp614-632
      5. Uses nested context free grammars with semantic elements <<action>>.
      6. Meaning as traces including calls and returns from methods using structural operational semantics -- derivation rules.
      7. Interface grammar language....
      8. Describes how EJB Persistance API is used.
      9. Algorithms for model checking.
      10. Experiments -- some executions took 13 seconds.

      2008-10-28 Tue Oct 28 20:10 Avoiding decaying qualities

      Tom Gilb used to say that Software Rusts. It is what in England is called Plumber Rot: the legitimate work of maintaining a system leads to its structure being weakened. Tus we get a bath tub curve for costs. But we can also improve the structure of software by refectoring it. We can also bring up other qualities: performance, security, reliability, etc. by putting effort into it. So why not include test of qualities in regression testing to tell us what goals are not being met and give clues as to where to improve the software?


      1. Jane Cleland-Huang & Will Marrero & Brian Berenbach
      2. Goal-Centric Traceability: Using Virtual Plumblines to maintain critical Systemic qualities
      3. IEEE Trans Software Engineering V34n5(Sep/Oct 2008)pp685-699
      5. GCT::acronym="Goal Centric Traceability".
      6. Put tests for qualities into regression testing and derive tests from goals.
      7. Tests can be done statically or by running code. But are automatically traced to impacts on quality goals.
      8. QAM::acronym="Quality Assessment Methods", These may be manual or automatic.
      9. They can be: executable models(simulations), Manually evaluated models, Runtime monitors, or test cases.
      10. Develops from [Cleland-HuangEtAl07]

      2008-10-27 Mon Oct 27 18:10 Network Externalities

      Back when the first telephone companies were starting economists made a new discovery. The value of signing up with a particular company increase with the size of the network. This applies strongly to mass marketted software. The more people use a particular word processor the more value there is in buying that piece of software. See [Botting95b] and [Botting97a] for instance. Here is another example. The tremendous number of people using the current Internet (protocol IPv4) blocks the adoption of the new IPv6 protocol. People prefer incremental patches to keep the old Internet running. Whereas the standards seem to expect a completely change over -- until recently.


      1. David Geer
      2. To Boost Adoption IPv6 Proponents Back Once-Shunned Technology
      3. IEEE Computer Magazine V41n10(Oct 2008)pp16-19
      5. IPv6 (128 bit +authenticating and encrypted packets) may be better than IPv4 (32 bit). No need for DHCP with IPv6.
      6. But it is not being adopted.
      7. So standards body is allowing an new architecture using network-address Translation (NAT). Uses dual-stack routers.
      8. (dick)|-network externalities strike again. Converse of the inventors dilemma.

      2008-10-25 Sat Oct 25 06:10 Updated list of Masters Projects

      If you are looking for a graduate project to carry out at CSE CSUSB, checkout [ project.html ] on this web site.

      2008-10-24 Fri Oct 24 17:10 Most dangerous blog

      Seems that some people really don't like the link in the next entry. See [ 001178.html ] which also has a comparison of two ways of compressing files.

      2008-10-23 Thu Oct 23 11:10 The One Thing Every Software Engineer Should Know

      Again Jeff Atwood nails it. And he reads dirty books.... [ 001177.html ] go and find out the one skill you need as a programmer that you've never expected to need.

      2008-10-22 Wed Oct 22 19:10 Quality is Job 1

      Here we have an article that shows hoe tackling qualities first give rise to a less tangle and "slimmer" architecture. This is not new -- books have been written on the topic.


      1. Ragvinder S Sangwan & Li-Ping Lin & Colin J Naill
      2. Structural Complexity in Architecture-centric Software
      3. IEEE Computer Magazine V41n10(Oct 2008)pp96-
      5. Tangle::=dependencies that form cycles.
      6. Fat::=cyclomatic complexity of dependency graph.
      7. Better structures have no tangles, few dependencies, and minimal fat.
      8. Express qualities as scenarios and assign business and developer priorities.
      9. Refactored structure to handle each scenario in order of priority.
      10. Claim: New architecture better than old.
      11. Compare with [Larman98] UP and [KrollKruchten05] RUP.

      2008-10-21 Tue Oct 21 14:10 Estimation does not get better

      We have known for a long while that it is difficult to estimate how long a software project will take. Partly this comes from expecting software development to be like building a house when it is often more like walking through a minefield. But another source is the low estimation skills of programmers. Humphey's "Personal Software Process" (PSP) tackles this head on with many forms and statistics. The following paper shows that giving feedback on the accuracy of estimates doesn't improve later estimates.


      1. Tanja M Gruschke & Magne Jorgensen
      2. The Role of Outcome Feedback in Improving the Uncertainty Assessment of Software Development Effort Estimates
      3. ACM TOSEM Trans Software Eng & Methodology V17n4(Apr 2008)#20pp1-35 [ 13487689.13487693 ]
      5. Letting programmers see their estimation errors does not help them improve their future estimates -- especially if they use intuitive prediction methods.

      2008-10-20 Mon Oct 20 20:10 More on E-speranto and logic

      As I predicted [ 2008-08-27 Wed Aug 27 13:08 An ancient controversy -- universal languages ] Neville Holmes has got a reaction to the use of a variation of Esperanto as an intermediate language for computers and Europe. In IEEE Computer Magazine V41n10(Oct 2008)pp6-7 Letters Patrick Durusau notes that people add ambiguity and idiosyncracies to any language they use -- including mathematics. But Holmes replies that usage as an intermediate language should stop semantic drift and creative inconsistencies.

      I'm updating the bibliographic item [Holmes08] to include the correspondence.

      I, personally find it interesting that Durusau note the different meaning given mathematical terms in different papers -- something that, perhaps, an online and formal repository of definitions [ maths/ ] might help.

      2008-10-18 Sat Oct 18 10:10 Types and Programming Languages

      Matt Richardson just posted (on my FaceBook Wall) a link to a description of the following book. I don't want to forget about it and may be able to use it in one of my classes. So the following is a place holder which I hope will expand.


      1. Benjamic C Pierce
      2. Types and Programming Languages
      3. MIT Press (Feb 2002) ISBN 0262162098
      5. Praised [ ?p=58 ]
      6. More.... [click here [socket symbol] if you can fill this hole]

      2008-10-17 Fri Oct 17 15:10 Debugging tools for formal methods

      It is interesting that people are developing tools that let you find defects in formal specifications of software. Initially we thought that it was easier to get specifications correct than it was to program code that fitted the specification. But now we have Daniel Jackson's work on Nitpick and the Alloy language and tools that check properties of specifications. A recent example is in this publication:


      1. Johannes Henkel & Christoph Reichenbach & Amer Diwan
      2. Developing and Debugging Algebraic Specification for Java Classes
      3. ACM TOSEM Trans Software Eng & Methodology V17n3(Apr 2008)#14pp1-37
      5. Formal specifications need debugging. A tool helps.

      2008-10-16 Thu Oct 16 17:10 Software Reliability Increases Under Usage

      The following result fits with my experience. It also sounds paradoxical -- especially when seen from the normal point of view that reliability is a property of software. In this case there is clear evidence that a piece of software gets more reliable -- without being changed -- as it is used. In otherwords reliability is a relationship between a user (who can learn) and the software they are using.


      1. Pankaj Jalote & Brendan Murphy & Vibhu Saujanya Sharma
      2. Post-release reliability Growth in Software products
      3. ACM TOSEM Trans Software Eng & Methodology V17n4(Apr 2008)#17pp1-20 [ 13487689.13487690 ]
      5. Users learn to work round the bugs.
      6. Proposes and tests model based on
      7. Failure_rate:=transient_failure_rate + steady_state_failure_rate.
      8. transient_failure_rate:= λ * α**(-time_in_use).
      9. Model fitting handles the time when the product is sold -- monthly sales.

      2008-10-15 Wed Oct 15 14:10 PhDs Found Useful

      Some one researched the technology of a current hot market and traced back where the ideas come from. It turns out the academic graduate theses are used in industry.... but it take 20 years for the ideas to become common mainstream technology.


      1. Wolfgang Emmerich & Mikio Aoyama & Joe Sventek
      2. The Impact of Research on the Development of Middleware Technology
      3. ACM TOSEM Trans Software Eng & Methodology V17n4(Apr 2008)#19pp1-48 [ 13487689.13487692 ]
      4. =SURVEY HISTORY MIDDLEWARE J2EE CORBA IBM BEW Oracle Nicrosoft Tibco Websohere RMI .NET etc RESEARCH PhDs
      5. 20 year lag between academic research and large mainstream market.
      6. PhD. Theses are important!

      2008-10-15 Wed Oct 15 09:10 CSUSB is open

      2008-10-14 Tue Oct 14 17:10 Source code is a design document

      This is an interesting, and until recently highly controversial point of view. Indeed I'm sure that some will continue to reject the proposed theory until they die.


      1. Jack W Reeves
      2. Code as Design: Three Essays
      3. developer.* Magazine [ DevDotStar_Reeves_CodeAsDesign.pdf ]
      5. Three essays: "What Is Software Design?"(1992), "What Is Software Design: 13 Years Later"(2003), "Letter to the Editor"(1992).
      6. In engineering, design process is not complete until something has been built and tested. Engineering design is creative, and delivers instructions to build a product. The instructions can be carried out almost automatically.
      7. Evidence: Toyota, Motorola, Boeing, Lockheed.
      8. However, building and testing is many times cheaper for software than in traditional engineering. Verification expensive..
      9. So, Software design should include build and test as part of an iterative loop.
      10. Source code is the design document. All previous documents are untested and so not reliable enough to be the design.
      11. But other documents are also needed. Example: unused domain information. Example: architecture.
      12. Source code ( =the design) is complex & evolving. Software is more like a society or organic system than a machine.
      13. So, Software design is an exercise in managing complexity.
      14. We therefore need good thinking about architecture and design before coding, but this must be checked by building and testing before it is reliable.
      15. No part of the process is complete by itself: think, code, build, and test are an essential (repeated) cycle of parts in software design.
      16. "We need good architecture[...] abstractions[...] implementations" but "we have not completed the process until we have written and tested code.
      17. Analogy: can you cross the river on the design for a bridge? Or does the design define how to build the bridge?
      18. "[...] programmers are not assembly line drones."
      19. "Less Able Programmers": do you want less able doctors?
      20. [you can't] substitute process for intelligence, aptitude, and experience."
      21. Why do we perceive debugging as wasted time?
      22. Early (traditional) design work is often needed but not complete until tested -- "first rough sketches". True design must reflect the structure of the product: hence high level source code.
      23. "designing software" <> "a software design". Process is not artifact.
      24. Comments are not adequate -- auxiliary documentation is more important than in other disciplines.
      25. Repeated phrase: "Any pretense otherwise is just silliness".
      26. "[...] if we could just find the right graphical design notation[...] I disagree." Engineering is about process not about whether we use CAD to render it.
      27. Focus on improving the (programming , debug, test) cycle.

      28. Does not note Petroski's examples of disasters where there where undocumented changes between the design and the actual object that was built.
      29. Compare with a recent interview [Shustek08] with Donald Knuth.

      2008-10-14 Tue Oct 14 11:10 Campus Closed but...

      I'm telecommuting today since the campus is closed down. Watching my Email. Thinking about how to repair the dama to [ cs372/ ] schedule.

      I'll hold my office hours (2-3pm) online if everything goes as planned. I've dug up my old AIM account "richardbotting". I will also have FaceBook: "Richard John Botting" and Email open.

      The San Bernardino Sun [ http://www.sbsun.com/ ] has a good summary of the fire status. Pray that the winds drop...

      2008-10-13 Mon Oct 13 16:10 Function point estimation

      People are still trying to predict the size of the code of a project from a description of the functionality it provides. The size is a key cost driver for producing the program and so this is important. But still difficult to get right.


      1. Cigdem Gencel & Onur Demirrors
      2. Functional Size Measurement Revisited
      3. ACM TOSEM Trans Software Eng & Methodology V17n3(Apr 2008)#15pp1-36
      5. Measuring and predicting size is important for project management...
      6. More work is needed.

      2008-10-10 Fri Oct 10 10:10 Bugs on FaceBook and IEEE

      I've been blessed with the ability to find bugs in software. It happens quite unconciously that I try the road less travelled and trip over a sequence the programmers did not expect. It has been very handy over the years. And very irritating to my colleagues. But sometimes this habit is a curse.

      This rant is inspired by a sequence of three bugs.

      First I noticed that if you go to a Facebook page by an abnormal route -- say directly to the URL of your own page, or from the PhD or SigmaXi "Join Group" pages then it claims you don't allow cookies when you try to login. A login from the page with the error message now works and you can join the group or whatever. This could be stupidity or malice. The failed login method of stealing passwords was used by a student in Cambridge University way back in the 1960s! But it could be an oversight by the programmers. Irritating.

      The IEEE is a premier society for electronic and software engineers. so you don'e expect a double error message when posting a comment on one of their articles:

        Internal Server ErrorThe server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster@blogs.spectrum.ieee.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

        More information about this error may be available in the server error log.

        Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

        Apache/1.3.39 Server at blogs.spectrum.ieee.org Port 80

      It was, of course quite predictable that sending the message to the webmaster did not work:

        Your message cannot be delivered to the following recipients:

      1. Recipient address: webmaster@blogs.spectrum.ieee.org
      2. Reason: Remote SMTP server has rejected address
      3. Diagnostic code: smtp;550-The recipient cannot be verified. Please check all recipients of this message.
      4. Remote system: dns;blogs.spectrum.ieee.org (pierre.livingdot.com ESMTP Exim 4.69 #1 Fri, 10 Oct 2008 09:48:21 -0700 )

      It is a pity that it does not work on my own software. Someone else has to use it for the bugs to surface.

      Thank you for listening. Any comments will be editted and quoted here... especially if [ hole.html ] works!

      2008-10-09 Thu Oct 9 15:10 Reuse reduces fault density

      Here we have some evidence for a popular belief -- that reusing a component is better then making a new one. Note that the research did not show that it is cheaper to have a reuse process. It shows an improved quality in the code.


      1. Parastoo Mohaghehi & Sintef Ict & Reidar Conradi
      2. An Empirical Investigation of Software Reuse benefits in a large telecom Product
      3. ACM TOSEM Trans Software Eng & Methodology V17n3(Apr 2008)#13pp1-31
      5. Significantly lower fault density in reused code.
      6. Reused components are modified less the more they are reused.

      2008-10-08 Wed Oct 8 14:10 A New Approach to Formal Languages and Automata

      Here is one of those ideas that I wish had been around years ago when I was struggling to make sense of computer theory: automata, languages, grammars, etc.. It appears you can do most of it in terms of equations in various special algebras. Surely it wouldbe easier to learn and use the theories if they had a unified basis. So why not write a text book using equations as the basis?


      1. Joe C M Baetan
      2. Calculating with Automata
      3. Montanari Festschrift [DeganoEtAl08] pp746-756
      5. Demonstrates that most of standard theory can be taught using equations.

      2008-10-07 Tue Oct 7 14:10 Bonus -- Good Issue of Doctor Dobbs on Agile Processes

      Just got the latest "Dr. Dobbs Best Practices Report by EMail" -- #101. Lot's of good reading. I'm particularly impressed by the figure quoted in the VersionOne Survey [ 3rdAnnualStateOfAgile_FullDataReport.pdf ] (PDF) showing that Scrum is becoming the leading agile method. I'll have to add to my notes [ samples/methods.html#Scrum ] and if you can help why not try [ hole.html ] to help me fill the hole.

      I also like Eric J Bruno's Requirements Traceability Matrix RTM as a summary document for requirements. You can use a spreadsheet. One row per requirement.
      IDDescriptionDesign DocUnit TestTest ResultsStatusInclude Next time

      (Close Table)
      (Status is color coded). This is not a new idea... see [ Wiegers99 ] for example.

      2008-10-07 Tue Oct 7 12:10 Asynchronicity needs Bags

      Here is a nice result. It demonstrates that if you want a system to perform asynchronously then it is not enough to connect processes by buffered connections using queues (First In, First Out) or stacks(Last In, First Out). You need bags(First in, Still Waiting) to properly decouple the processes. I've always like the FISH file: First In, Still Here for every day data processing.


      1. Ramain Beauxis & Catuscia Palamidessi & Frank D Valencia
      2. On the asynchronous Nature of Asynchronous π-Calculus
      3. Montanari Festschrift [DeganoEtAl08] pp473-492
      5. Proves that to get behavior equivalent to π[a] (Asynchronous Pi Calculus) you need a normal π calculus where communication is through buffered channels that act as buffers. Queues and stacks can not simulate all π[a] behaviors.

      2008-10-06 Mon Oct 6 14:10 Modeling Biological Systems

      Here is a neat technique for generalizing Milner's Calculus so that interactions are not defined by paired inputs and outputs.


      1. Paola Quaglia
      2. On Beta-Binders Communications
      3. Montanari Festschrift pp456-472 [DeganoEtAl08]
      5. Instead of complementary paired actions (CCS) allows pairing of actions if they are of a compatible type.
      6. Defines syntax, equivalence, reductions, denotations, structural operational semantics,...
      7. Proves key results.

      2008-10-02 Thu Oct 2 19:10 Straightforward Business Model in UML Proposed

      Normally proposals for ways of using the UML to model businesses have been overly complex -- to my eye. So here is a simple approach.


      1. Egidio Astesiano & Gianna Reggio & Filippo Ricca
      2. Modeling Business with a UML-based Rigorous Software Development Approach
      3. Montanari Festschrift pp261-277 [DeganoEtAl08]
      5. BM::discipline="Business Modeling".
      6. Use multiple UML2 views of business: Static + Organization + Business Process + Data.
      7. Model business processes in the context of other business processes.
      8. Model business entities and organization.
      9. Model activities precisely.
      10. Proposes stereotypes: <<A>> for autonomous acts, <<bw>> for business worker, <<bo>> for business objects, <<ext>> external entities, <<ou>> organizational units. <<bp>> business process "use case". <<large>> high level cases.

      2008-10-01 Wed Oct 1 10:10 Attending a Webinar on Agile Methods

      This will be an intersting experiemnt. Steve McConnell is speaking on Right sizing Agile Cnd Construx experience, at 11 this morning. I intend to jot down any notes live and then post them to this blog.

      1. First Firefox updates itself and the Real Player insisted on updating.
      2. Why agile:
        • traditional was not getting the job done.
        • Waterfall absorbs costs all the way thru but value comes at the end of the project. 80% thru with 0% functionality.
        • Incremental -- a bit at a time. Functionality grows with time and cost.
        • Deliver the most important functionality first - high cost first. Then diminishing returns at end.
        • Agile lets you change plan as returns decrease and discoveries are made.
        • More customer feedback.
      3. Full blown agile when fixed cost and time -- but want the biggest business value within the resource limited.
      4. History of "Agile"... a moving target. Always incremental and non-waterfall. Usually iterative -- but can have fixed requirments with incremental development. More code based than documentation. Families of practices.
      5. Agile = "Modern practices that work".
      6. Cost + Schedule + Functionality.
      7. Continuum of approaches fitting different needs. Predicatble projects are closer to waterfall.
      8. Identified activities {Requirements, Architecture, Detailed Design, Construction, Developer test/unit test, System test} may or may not be a sequence of phases.
      9. The Life cycle model drives the success of an approach rather the particular practices.
      10. Variations depends on: %requirements up front, % design up front, %number of iterations, %Testing before the end of the project.
      11. Examples
        • Analysis of "Code and Fix" -- end up doing work at after the project.
        • Waterfall -- miss requirements and design that is done at the end.
        • XP -- more discipline, each increment is tested and releasable. Some churn. Less unexpected work at end.
        • Evolutionary prototyping is similar.
        • Pure Scrum -- works better. fewer surprises at end.
        • Variation: more reqts up front. -- works well.
      12. Presented Lots of variations of life cycles.
      13. Effective practices (based on experiences and industrial reports)
        • Short release cycles -- nearly always valuable -- variations.
        • Highly interactive release planning -- you can't plan more than 30 days but it is good to have a 30+ day plan!
        • Time boxing -- works, but sprints and breaks are good.
        • Empowered small crossfunctional teams: feature teams, represent all stakeholders on team. efficient and buy in.
        • Involve active management: coaches and scrum-master, good for high discipline practice. exercise bike. Theory Y management. -- showed benefits.
        • Coding Standards.
        • Frequent integration and test. takes effort. needs compute power. worth the effort to set up. Need the test. Daily is good.
        • Automated regression testing -- helpful. Unit test tools.
        • Retrospectives at end of release -- good idea. Covey: sharpen the saw.
        • Daily standup meeting -- accountability, not too long.
        • Test first -- works pretty well. High discipline. Some extra benefits over just SQA.
        • On-site customer? project community. "whole team". Theory-W (win) managment.
        • Pair programming -- use selectively, junior programmers. many try it and give it up. Selective.
      14. When to use? First draw your Agile profile -- Kiviat diagram: %reqts change/month, culture, dispersion, size, impact, personel experience.

      15. Summary -- high discipline needs support, verify that practices align with needs, busness value, have a realistic expectations and tradeoffs.
      16. Common Hurdles -- advert for Construx [ http://www.construx.com ]
      17. Iteration is more general than repeating a single cycle. Iterate quickly in areas of risk.

      The above is my interpretation of the webinar.... your milage may differ.

      2008-09-30 Tue Sep 30 12:09 Web sites on Architecture

      One of the pleasures of being a member of ACM's Special Interest Group on Software Engineering is reading Marc Doernhefer's regular article where he takes a topic and looks for relevant web pages on that topic. This month he has been looking for the topic of architecture. I'm worried by the number of standards and approaches and the different meanings:
      1. Systems Architecture -- structure of systems that include programs
      2. Software Architecture -- the structure of sofware


      1. Mark Doernhoefer
      2. Surfing the net for software engineering notes: Architecture Digest
      3. ACM SIGSOFT SEN V33n5(Jul 2008)p4-13 [ 1402521.1402530 ]
      5. First discusses System Architecture including:
      6. Second: Software Architecture
      7. Tools [ http://argouml.tigris.org ] [ dbdesigner4 ] [ workbench ]

      2008-09-29 Mon Sep 29 18:09 Ugo Montanari Feshrift

      When a successful academic researcher comes to a special point in the career the people whohave been influenced by the academic get together and have a conference based on the whole body of work -- a festschrift. I've been asked to review the published proceedings of one of these. I'll be noting some of the papers that seem most relevant to this blog here as they come up. Meanwhile here is a placeholder or stub (which I will change in the bibliography later) and the description of the language Ciao. It looks like Ciao is a very interesting and powerful language indeed. I haope I can find time and a way to check it out in detail sometime.


      1. Pierpaolo Degano & Rocco De Nicola & Jose Meseguer (eds)
      2. Concurrency, Graphs and Models: Essays dedicated to Ugo Montanari on his 65th Birthday
      3. LNCS 5065 Springer Verlag Berlin Heidelberg (2008)
      5. Notes: CR Oct 2008
      6. Includes [HermenegildoEtAl08]


      1. M V Hermenegildo & F Bueno & N Carro & P Lopez & J F Morales & G Puebla
      2. An Overview of the Ciao Multiparadigm Language and Program Development Environment and its Design Philosophy
      3. Montanari Festschrift pp208-237 [DeganoEtAl08]
      5. Downloads [ http://www.ciaohome.org ] [ http://www.cliplab.org ] ciao@clip.dia.fi.upm.es
      6. 91 references

      2008-09-26 Fri Sep 26 10:09 Changes on this site

      First -- I'm freeing up the look-and-feel by removing the font-families specified for the body (serif) and headers (san-serif). In MS IE and Safari you can specify your own style sheet. If you have this
      in your stylesheet you can get the old look back again. This is comming from CSUSB's attempt to make everything more accessible.

      By the way -- if you want to write a stylesheet on a Mac OSX system I would suggest you don't use "Text Edit" which will convert your text in an HTML page that looks like it was plain text. This is an example of what I call "Artificial Stupidity". The very cleverness of the designers and programmers defeats the intentions of their user. By the way -- it is lovely to be able to drop through the MacOS GUI into a classic terminal. I felt quite at home. But I was surprised at how good it felt to be using vi rather than a GUI editor!

      I've also got my sabbatical project to the level where it meets some key requirements. (1) you can put MATHS into a form and get it rendered. (2) you can edit the form and try again. (3) you can send the finished contribution to me. (4) If the contribution fits the purposes of this web site then I can post it to this blog and other places.

      Here is the link [ hole.html ] if you want to try this out or comment on something on this page/web site.

      2008-09-25 Thu Sep 25 13:09 Formal Methods

      The topic of Formal Methods has just turned up in the ACM's Journal for all Members. They do offer much more reliable software but they can be expensive and are not well understood or liked by those who don't use them.


      1. Mike Hinchey & Michael A Jackson & Patrick Cousot & Byron Cook & Jonathen P Bowen & Tiziana
      2. Software Engineering and Formal Methods
      3. Commun ACM V51n9(Sep 2008)pp54-59 [ 1378727.1378742 ]
      5. Summary of three key note speeches from ICSE&FM 2007.
      6. Describes history: increasing dependability of hardware, more intensive use of software, more ubiquitous computing, no increase in software dependability.
      7. Formal methods can increase dependability.
      8. Jackson notes that good engineeing stays within the normal design discipline associated with a given application domain. Radical design leaves the normal and always decreases the dependability of the result. Therefore the need to develop special purpose disciplines for each domain.
      9. Patrick Cousot defines formal methods and the idea of abstraction. Mentions Astree.
      10. Byron Cook notes the explosion of complexity when there is concurrency and the attempts to overcome it.
      11. Conclusion reviews the history, describes method engineering and states that the quest continues...

      Meanwhile, I'm wrestling with a server that doesn't want to send my email.... So at this time my "hole" script reports success but the Email doesn't seem to be delivered. More on this later.

      2008-09-24 Wed Sep 24 17:09 Tool finds bugs in Java

      Seems like the Findbugs tool was useful to people working at Google:


      1. Nathaniel Ayewah & William Pugh & David Hovemeyer & J David Morgenthaler & John Penix
      2. Using Static Analysis to Find Bugs
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp22-29
      5. A free static analysis tool finds real defects in real code ... Plus some false positives -- but misses some bugs.
      6. Survey of users shows it to be useful.

      2008-09-23 Tue Sep 23 10:09 MATHS defined

      I'm starting to bring my work on my MATHS language onto the front burner in preparation for the release of a Beta tool for creating web pages, and submitting contributions to this web site.

      In 1999 I wrote a manifesto for the language laying out my dreams and requiremements [ maths/10_manifesto.html ] and today I added a citation for it [Botting99a] to my bibliography. Enjoy.

      2008-09-22 Mon Sep 22 05:09 Economics vs Technology

      One of the sadder patterns in the history of programming languages is that economics tend to trump technology. The better technology will fail when competing with economic forces. Similarly a new system has to make economic sense to the stakeholders -- even if it has less than ideal technology. Especially if the technology is new (bleeding edge) and fashionable. So I'm always interested in the economic strategy adopted by technology providers. Here is a recent article on one particular example: Microsoft vs Apple. Note -- that there are complications in this particular junction that the article does not cover.


      1. Michael Cusumano
      2. Technology Strategy & Managment: The Puzzle of Apple
      3. Commun ACM V51n9(Sep 2008)pp- [ 1378727.1378736 ]
      5. MS tends to create platforms that encourage other businesses to get involved.
      6. Apple prefers a closed but higher quality (and higher priced) product.
      7. Comparison with Betamax vs VHS.

      By the way -- I'm hoping to announce a major development in the technology for this weblog this week.

      2008-09-19 Fri Sep 19 09:09 Architeture and Risk

      Organizing complex software into modules is not so much driven by what the software does (as we thought in in the 1960s-1970s) but by the risks. The Software Engineering Institute of Carnegie Mellon made a study ot the risks that where mentioned in a set of architectural documents. They uncovered 99 different ones, grouped them by type and published a report in 2006. See Below. It has some interesting observations


      1. Len Bass & Robert Nord & William Wood & David Zubrow
      2. Risk Themes Discovered Through Architecture
      4. Tech Report CMU/SEU-2006-TR-012
      5. ATAM::="Architecture Tradeoff Analysis Method".
      6. Lists 15 Risk Theme Categories: Availability, Performance, security, modifiability, integration, process and tools, requirements, allocation, documentation, Big Picture, Unrecognized needs, product lines, awareness, scope, coordination.
      7. Claims 99 risk themes.
      8. Reference to Boeing experience with ATAM and Charette's failure causes.
      9. Relation to business goals.
      10. Importance of "Performance" .
      11. No evidence that risks are independent of domain. One size does not fit all.
      12. Risks of commission and Omission. Omission more common.
      13. Odd fact: security was always a risk of omitting to do something.

      2008-09-18 Thu Sep 18 13:09 XML again

      Here are a couple of articles on XML. One agues that different parsers perform differently on different tasks. The other argues that real programmers like XML and agile methods -- possibly for all the wrong reasons.


      1. Tak Cheung Lam & Jianxun Jason Ding & Jyh-Charn Liu
      2. XML Document parsing
      3. IEEE Computer Magazine V41n9(Sep 2008)pp30-37
      5. Different parsing tools/models perform best on different tasks.
      6. Sample: DOM good for data bases and SAX & StAX for streaming. VTD will need special hardware to perform quickly.


      1. Ian Gorton
      2. XML does Real Programmers a Service
      3. IEEE Computer Magazine V41n9(Sep 2008)pp100+98-99
      5. Real Programmers write code, late at night, just before the deadline.
      6. Agile allows real programmers to do what they want and provide the stakeholders with what they want.
      7. XP: "[...] every one prefers muffins and expresso to writing specifications."

      2008-09-17 Wed Sep 17 14:09 One way to hatch a catestrophe

      Here is an ancient tale of bad engineering:
      1. Amateurish designs.
      2. Ignoring nay-saying experts.
      3. Pride.

      And it is not a software project... but I agree with the author -- all software developers need to know about it.

      Note: recent events on MetroLink in California also show a pattern of experts saying that something is dangerous, and people being killed when the advice is not taken.


      1. George Neville-Neil
      2. Kode Vicious: Pride and Prejudice (The Vasa)
      3. Commun ACM V51n9(Sep 2008)pp25-26 [ 1378727.1378737 ]
      5. The history of the Vasa Galleon (1626) shows how a leader pushing technology too far, against the advice of technical experts, lead to a catestrophe.

      2008-09-16 Tue Sep 16 10:09 Distributed Code Reviews

      Bertrand Meyer reports that using the internet leads to better code reviews. He doesn't quote any data, but claims that the process is much more enjoyable and productive. Now code review is a proven way of finding errors and improving software quality, see [ArnoldTFuson94 ] (=ESSAY) [Baker97 ] (=EXPERIENCE) [BergClineGirou95 ] (=CORRESPONDENCE) [BishopWagner07 ] (=REPORT) [DownsA00 ] (=EXPERIENCE) [HallChapman02 ] (=EXPERIENCE) [Humphrey95b ] (=ADVERT) [JonesC96a ] [KupermanEtal05 ] (=REPORT) [Lussier04 ] (=EXPERIENCE) [Voas03 ] (=EDITORIAL =HISTORY) We also have a lot of data for formal inspections working well. More informal walkthroughs and peer review have also been used for decades... So it is good to learn that VoIP+Google Docs+Wikis make them more effective -- even for international teams.


      1. Bertrand Meyer
      2. Design and Code Reviews in the Age of the internet
      3. Commun ACM V51n9(Sep 2008)pp67-71 [ 1378727.1378744 ]
      4. =EXPERIENCE REVIEW SQA WWW/Net VoIP wiki Skype X-Lite Google Docs EiffelStudio
      5. Design and code reviews can be carried out by an international team by using the web for text, chat, and voice communication in parallel.
      6. Give access to documents when inviting people to take part. Invite them to contribute to a document of issues.
      7. Web shared documents streamline the process. Reviewers post their issues and their comments on the issues into a shared document before the meeting. The authors responses are also posted. The meeting focusses on the interesting issues.
      8. The meeting uses VoIP (Voice over Internet Protocol) and chat (text) as well as editting the shared issues.
      9. Meetings are productive and not boring. Multimedia multitasking is common.
      10. No need for a secretary the discussions, conclusions and responses are already on file!
      11. Sample: [ 2008-02-sample.html ]

      2008-09-15 Mon Sep 15 11:09 Modelling Trust

      How can you make a website trustworthy? Sounds philosophical until you have a website that won't work unless your users trust it. There has been a lot written on it. Here is a summary of the best published papers:


      1. Ejike Ofuonye & Patricia Beatty & Ian Reay & Scott Dick & James Miller
      2. How do we build trust into E-commerce Web Sites
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp7-9
      5. Literature survey [ WebExtra.html ]
      6. Conclusions
        1. Trust is a complex quality depending on several linked factors:
          • Technology Acceptance Model (TAM),
            1. Which depends on the Usefulness and Ease-of-Use of the web-site.
            2. Ease-of-Use influences perceived Usefulness.

          • Benevolence-Competence-Integrity framework (BCI),
            1. Which depends on the perceived Risks and the site's Reputation.

        2. Usefulness influences Competence and Integrity.
        3. Risks influence Benevolence and Competence.
        4. Reputation influences Competence.
        5. All factors also directly effect Trust!

      Note: This is a kind of domain modeling. An example of the kind of knowledge/modelling that is very difficult to encode in a visual way that has a formal semantics... We know how to model entities and relationshps between them. But influences and qualities don't fit the traditional logic of Entity-Relationship diagrams except in the general form.

      2008-09-12 Fri Sep 12 16:09 Request for Comment

      I've just seen a positive review of the following item. If you have read the book and have any bullet points, select the "socket hole" below and send them to me and I can (if they are short and to the point) add them to my bibliography.


      1. Stephan Diehl
      2. Software Visualization: Visualizing the structure, behavior, and evolution of sofware
      3. Springer Verlag NY NY 2007 ISBN 3540465049 CR 0809-0828
      4. =UNREAD =TEXT GRAPHIC CODE TECHNICAL [click here [socket symbol] Diehl07 if you can fill this hole]
      Syntax: Put each bullet-point on a new line and put a space in front. I have tools to render it into HTML. Note: you must include a name and address to be published. You work will be creditted.

      2008-09-11 Thu Sep 11 18:09 Project cancelation rates

      Good discussion of past polls and a recent pair of polls:


      1. Khaled El Emam & A Gunes Koru
      2. A Replicated survey of IT Software Project Failures
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp84-90
      5. Published work overestimates failure rate.
      6. In this poll about 16% were cancelled in 2005 and 12% were cancelled in 2007.
      7. Reasons given: uninvolved senior management, requirements/scope changes, lack of management skills, over budget, lack of technical skills, system not needed afterall, etc..

      2008-09-10 Wed Sep 10 13:09 Empirical vs Constructionist Research

      Hakan Erdogmus has written an interesting article on why empirical research is not done in software development. It lists excuses but not my excuses: (1) it is cheaper to sit and think and code. (2) You don't have to get permission from an Institutional Review Board to do experiments on human beings. But his list of excuses is excellent.


      1. Hakan Erdogmus
      2. Must software research stand divided
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp4-6
      5. Gives a good description of the two types of research into software development.

      The idea is that an article or paper can either be based on theory, opinion or some data. Over the years (Since [Fentonetal94] ) I have tagged the 4000+ items in my bibliography on software development with the kind of evidence presented. Here is a table of the commonest tags and my comments on them. Notice that the top category is definitely empirical. To look at some of these go here [ lab.html ] and input the tag... complete with the equals(=) sign.
      489=EXPERIENCEDraws conclusions based on real software development projects -- uncontrolled and may not transfer. Often biased towards reporting success.
      444=DEMOShows what a piece of software or tool can do.
      385=ADVERTMakes claims without evidence being given. Includes a paper describing a Ph. D. Thesis.
      374=THEORYA linking of assumption to results by reasoning. The assumptions may not fit any real situation.
      289=ESSAYA balanced (assay) treatment of a topic or question. Must cover both sides and may come to a conclusion.
      229=IDEAAn idea for a method, tool, process, etc. that may or may not work.
      225=SURVEYResults based on a literature survey of published results.
      138=HISTORYRecords and comments on past events.
      132=EXPERIMENTResults found in a controlled (and so artificial) situation. Allows specific effects to be teased out but they may not move into a real situation.
      118=TEXTText books -- should state fairly well accepted ideas.
      83 =POLLResults of asking people in the field questions.
      73 =HOWTODescription of how to get desired results using given tools.

      (Close Table)
      Conclusion -- there is a lot more empirical publications than anything else on software development.

      2008-09-09 Tue Sep 9 17:09 Agents

      Here are two recent articles -- one simplistic description of software development with agents and the other discussing the complex relationship between rules and emergent properties in systems of agents.


      1. Hisham Mubarak
      2. Developing Flexible Software using Agent-Oriented Software Engineering
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp12-15
      5. AOSE::= "Agent-Oriented Software Engineering".
      6. Agents depend on a platform that lets them configure themselves to achieve their goals.
      7. The platform includes agent management, directory services, a message transport system, and an agent communication language.
      8. Article lists relevant websites.


      1. Hal R Varian
      2. Designing the Perfect Auction
      4. Commun ACM V51n8(Aug 2008)pp9-11 [ 1378704.1378708 ]
      5. Games theory predicts the outcomes for a given mechanism, mechanism design produces a set of rules that gives a desired outcome, and computer science shows that some mechanisms have intractable computations.
      6. Mentions auctions for spectrum, stamps, flowers, eBay, Google, MSN, and Yahoo.
      7. Does not mention need to model the existing situtuation or domain.

      2008-09-08 Mon Sep 8 14:09 Software Development ideas unstable

      Computer science has been a moving target for decades. Most of the topics I taught to freshers in the 1970's became high school before the decade was out. The research in my thesis entered the undergraduate curriculum within 2 years and disappeared with the arrival of standard graphics packages and powerful displays. A standing joke was that the teacher teaching Computer Graphics could always ask the same question in the final exam because the answer was different each year.

      Even in the most stable topic (theory), the arrival of the concepts of P and NP defined a new landscape that was not visible when I first taught theory.

      Phillipe Krutchen has gathered evidence that this process is continuing.


      1. Philipe Kruchten
      2. The Biological Half-life of Software Engineering Ideas
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp10-11
      4. =SURVEY IDEAS 1988..2008
      5. Half_life(C)::=The time taken before 50% of a chemical C is removed from a body, example: Half_life(caffeine) =~= 3.5.hrs.
      6. Out of 50 items in IEEE Software from 1988 no more than 3 are still important.
      7. This implies a Half_life of about 5.years.
      8. Professional organizations enforce continuing professional development.
      9. More important to learn how to learn than learn the language/system of the day.
      10. (dick)|-Compare the half life used to model radioactive decay.
      11. (dick)|-Suggests exponential decay:
      12. amount (t) = amount (t0) * 2 ** ((t0-t)/ half_life) ).
      13. (dick)|-Which ideas are strong enough to survive?

      2008-09-05 Fri Sep 5 13:09 Fear and Loathing of Upgrades -- Take 2

      This is the first blog posted from our new iMac via a DSL connection.

      Fairly typically the Macintoshes had few problems and it took 60..80 mins to configure the Windows system.

      And the Mac OS X is built on Unix so I could use the ssh out of the box to post this entry and convert it to HTML and post it...

      Next stop.... plugins and more goodies...

      Time to relax... Back on Monday.

      2008-09-04 Thu Sep 4 15:09 Understanding Big Programs

      Some problems in software development do not go away. Forty years ago, starting out on my graduate work, I was faced with figuring out a program so that I could modify it. It was compiler and I had access to the machine code -- So I started to flow chart it (a manual version of the second most popular technique below). Only about 8,000 instructions. I was just getting lost on the 20th page of the flowchart when a faculty member looked over my shoulder and asked "What are you doing?" -- I explained. "Why don't you ask the supplier to give you the documentation?" I answered -- "What is documentation?" "Oh you know -- flowcharts and things like that".

      So I phoned up the company -- "Elliott Brothers" and they sent me all the design document -- the pseudocode for the compiler. Not bad technique for the 1960's. But then this was Tony Hoare's team.

      Now, in 2008, nobody suggested digging out the documentation to help figure out a set of code. Seems that (1) programmers don't expect to have any documentation, and so (2) programmers don't prepare for future maintenance by leaving bread crumbs and silken clues through the labyrinth of finished code.


      1. Sukanya Ratanotayanon & Susan Elliott Sim
      2. Inventive Tool Use to Comprehend Big Code
      3. IEEE Software Magazine V25n5(Sep/Oct 2008)pp91-92
      5. When asked how to comprehend a novel and large corpus of code Slashdot [ http://slashdot.org ] users answered
        1. Use code navigation tool to link names to definitions.
        2. Use tools to reverse engineer diagrams.
        3. Use debuggers.
        4. Print the code out and use color markers.
        5. I've had this problem too.
        6. Don't use tools -- use your brain + an "editor and grep".

        (most frequent first).

      2008-09-03 Wed Sep 3 15:09 Recovered Item on Benchmarks

      My paln to get to the secondary backup copy (see next item) in my office worked -- I had to open the Palm Pilot desktop and copy/paste the two items into a scratch file and then synchronize, and then copy/paste them back again. Here is one with the irrelevant property of having more authors than any other item in my bibliography.


      1. Stephen M Blackburn & Kathryn S McKinley & Robin Garner & Chris Hoffman & Asjad M Khan & Rotem Bentzur & Amer Diwan & Daniel Feinberg & Daniel Frampton & Samuel Z Guyer & Martin Hirzel & Antony Hosking & Han Lee & J Eliot & B Moss & Aashish Phansalkar & Darko Stefanovic & Thoms VanDrunen & Daniel von Dineklage & Ben Wiedemann
      2. Wake Up and Smell the Coffee: Evaluation methodology for the 21st century
      4. Commun ACM V51n8(Aug 2008)pp83-89 [ 1378704.1378723 ]
      5. Developing a useful benchmark is time consuming.
      6. Using them needs understanding of relevant workloads, good experimental design, and rigorous analysis.
      7. Benchmark research is underfunded.

      2008-09-02 Tue Sep 2 08:09 Backups and disasters

      Sometime since the last four days I've managed to delete my "buffer" of bibliographic items. This held on a Palm E2 todo list. Each work day I take one or two of the items and write a short blog entry about it. So some of the less interesting ones wait in the buffer, starved of attention for a few weeks... The Palm is synchronized with a couple of laptops. And I must have synchronized the deletion between the Palm and the old Dell at home. However, the second new Dell, at work should have the older items on it. A long way from the "disaster". So I've just retyped the following new item directly into the laptop ready for uploading. I'll pick up the rest of them when I get into my office tomorrow.

      Now the rule: Always Backup Data and then keep a secondary backup copy, a long way away, of your backup data. This has been a common part of data processing system design since the first "backing store". Scientists working on long computations (200 hours, say) always included check points to save the data calculated in case the system crashed or the power was cut. And software developers are wise to distribute their source code and run a version control system!

      2008-09-02 Tue Sep 2 08:09 Crosscutting concerns and bugs

      Now back to the reconstructed item, It presents some evidence that Aspect Oriented Programming and the Don't Repeat Yourself (DRY) principle are valid.


      1. Marc Eaddy & Thomas Zimmermann & Kaitlin D Sherwood & Vibhav Garg & Gail C Murphy & Nachiappan Nagappan & Alfred V Aho
      2. Do Crosscutting Concerns Cause Defects
      3. IEEE Trans Software Engineering V34n4(Jul/Aug 2008)pp497-515
      5. Requirements mapped into concerns.
      6. Reverse engineered concern->code map and the bug->code mapping and deduce concern->bug relationship in corpus of Java code.
      7. Defects tend to be associated more with wide-spread concerns than with total amount of code implementing a concerns.

      2008-08-29 Fri Aug 29 08:08 Questions and answers from Programmers


      1. Jonathon Sillito & Gail C Murphy & Kris De Volder
      2. Asking and Answering Questions during a programming change task
      4. IEEE Trans Software Engineering V34n4(Jul/Aug 2008)pp434-451
      5. Lists the 44 types of questions asked as programmers work on changing code.
      6. Classifies them in to 4 types.
      7. Tools do not support integrating information from many questions or more complex types of question about understanding structures.

      2008-08-27 Wed Aug 27 13:08 An ancient controversy -- universal languages

      Neville Holmes has opened a can of worms... or more prosaically a box of old press clippings, booklets, notes etc. He has suggested a simplified form of Esperanto might be useful in the European Union and the computer world.


      1. Neville Holmes
      2. The European Union and the Semantic web
      4. IEEE Computer Magazine V41n8(Aug 2008)pp108+106-107
      5. E-speranto::="a simplification of Esperanto".
      6. Esperanto::="the most popular artificial universal language".

      I wonder whether there will be another flame war like in "Computer Weekly" in England in 1978. An RWar (War of Religion) that I found myself dragged into about the relative merits and demerits of various languages as intermediate languages used in machine translation between natural language.

      I'll list some of the items in this storm in a tea cup shortly but first how I got involved.

      I came out of my Ph. D. work (1971) convinced that the hard part of programming was describing the domain of the software clearly, unambiguously, and (hopefully) simply. I also believed that computers would be turning up every where. So I foresaw the need for a universal computer-friendly language. I was alos biased towards mathematical and logical expressions -- they had worked well in my graduate work on computer graphics. In other words: I saw semantics as a key problem for developing software -- understanding what the stakeholder's mean and translating this into code.

      So I collected languages and notations. These days you can check them out on the Wikipedia: [ Basic_English ] ( < 1,000 words! ) [ Blissymbol ] [ Dutton_Speedwords ] [ Esperanto ] [ Loglan ] [ Shavian ]

      These convinced me that a couple of thousand primitives would be all that would be needed.... Also that I like Loglan.

      Lately I've discovered that Loglan has an evolved rival: [ Lojban ] and some the work I did looking for the properties of words has be subsumed by the [ Cyc ] project and modern ontologies.... because the semantics is now seen as a problem on the web. Further, these days most methods include a domain modeling step which works out the logic of the user's domain. Further data bases have help us evolve methods like normalization for discovering the underlying logical structure of the data underneath the physical forms.

      Now back to the controversy in the 1978. I'm sure I'm missing some of the letters and articles but here are the ones I have preserved.


      1. Ian D K Kelly
      2. How Esperanto can aid machine Translation
      4. Computer Weekly (UK) (Jan 19 1978)p16
      5. States six criteria: rich, computer text, precise, regular, humanized interface, existing corpus.
      6. Argues that SLUNT is not proven rich enough, but Esperanto fits all criteria.


      1. Peter Sebborn
      2. Problems of language transaltion by machine
      4. Computer Weekly (UK) (1978)p16
      5. Having an ITL would reduce the number of translators form O(n^2) to O(n).
      6. Something is lost in tanslation.


      1. Richard J Botting
      2. Loglan -- a more flexible language
      3. =ADVERT Loglan Mathematics Logic ITL UNIVERSAL LANGUAGES
      4. Computer Weekly (UK) n598 (Feb 16 1978)letters
      5. Response to [Kelly78]
      6. Argues that Loglan fits Kelly's criteria better.


      1. Ian D K Kelly
      2. Loglan -- a more flexible language
      4. Computer Weekly (UK) (Mar 16 1978)p20
      5. Rebuts [Taylor78]
      6. Argues that Sanscrit might fit the criteria best and has several centuries of formal syntax.


      1. Kable S Singh
      2. Loglan -- a more flexible language
      4. Computer Weekly (UK) (Mar 16 1978)p20
      5. Need to choose ITL quickly!


      1. Chris Long
      2. Logical
      4. Computer Weekly (UK) (Mar 16 1978)p20
      5. You can write English logically!


      1. Walter Goshawke
      2. qadvantages of Number Language
      4. Computer Weekly (UK) (Mar 16 1978)p20
      5. SLUNT::="Spoken Language Numeric Translation".
      6. More details in Computer Weekly (UK) (Sep 1 1977)


      1. Alec Venture
      2. Loglan -- a more flexible language
      3. =LETTER Esperanto vs Loglan Volapuk LOGIC ITL UNIVERSAL LANGUAGES
      4. Computer Weekly (UK) (Mar 23 1978)p19
      5. Rebuts Taylor78 and Botting78a.


      1. Frank M Easton
      2. Esperanto Success
      4. Computer Weekly (UK) (Mar 23 1978)p19
      5. Rebuts Botting78a "Loglan unheard of".


      1. C G Love
      2. Lack of Support for Loglan
      3. =ADVERT Esperanto
      4. Computer Weekly (UK) n598 (Mar 30 1978)p16
      5. States that Esperanto has many speakers and political support.


      1. R Mankin
      2. Loglan -- a more flexible language
      3. =LETTER Esperanto vs Loglan Volapuk LOGIC ITL UNIVERSAL LANGUAGES
      4. Computer Weekly (UK) (Apr 13 1978)p16
      5. Argues that an ITL must be artificial so that it does not grow, adapt, and develop dialects!
      6. Rebuttal: Esperanto is used widely and yet has no dialects.


      1. Alison M Williams
      2. Growing oposition to English as an ITL
      4. Computer Weekly (UK) (Apr 20 1978)p??
      5. Examples of countires abandoning English as their second language in school.


      1. G A R Taylor
      2. The case for teaching Esperanto more widely to scientists
      4. Computer Weekly (UK) (Apr 20 1978)p??
      5. States that Esperanto is easy to read and write.
      6. However notes that other texts in other langages have to be rewritten before they can be translated...


      1. Richard J Botting
      2. Languages at the Crossroads
      3. =ADVERT Loglan Mathematics Esperanto ITL UNIVERSAL LANGUAGES
      4. Computer Weekly (UK) n598 (April 27 1978)p4
      5. Response to [Love78]
      6. Calls for "an Intermediate Text Language that benefits language translation and not use computers to help Esperanto"
      7. Need to examine many alternative solutions to a problem.
      [ dick78.gif ] (Photo from article).


      1. Chris Moss
      2. The Value of Loglan as a useful tool in Machine translation
      4. Computer Weekly (UK) (Jun 15 1978)p4
      5. Describes Loglan in more detail.

      It would be nice to think that this is the end of the debate. Somehow I don't think so!

      2008-08-26 Tue Aug 26 10:08 Virtualization

      From the "everything old is new again" file. Here is a note on virtualization -- when several independent programs/applications share a common CPU+RAM. I think this trick was first done on the Atlas supercomputers in England in the early 1960s -- along with virtual memory and time sharing. It turns out that security is harder when using virtual machines.


      1. Steven J Vaughan-Nichols
      2. Virtualization Sparks security concerns
      3. =ESSAY SECURITY VIRTUAL MACHINE Hypervisor VMware Hyper-V Xen
      4. IEEE Computer Magazine V41n8(Aug 2008)pp13-15
      5. Since the 1960s it is possible for several virtual machines/systems to run on a single CPU. A special program (supervisor, hypervisor, executive) controls resources and makes each system/program work as if it was the only program on the machine. This was first done on supercomputers, then on mainframes, and so on down to PCs.
      6. How virtual machines makes security harder to maintain than when each application/system ran on a separate computer.

      2008-08-25 Mon Aug 25 13:08 Testing Services

      Not much to add today's citation (below) other than to invite you to also see Meyer08 last Thursday(below).


      1. W T Tsai & Xinyu Zhou & Yinong Chen & Xiaoying Bai
      2. On testing and evaluating service-oriented software
      4. IEEE Computer Magazine V41n8(Aug 2008)pp40-46
      5. Using statistical analysis to select tests.
      6. Can test many services in parallel.
      7. CRM::="Coverage relationship model", Tsai et al in 2007.

      2008-08-22 Fri Aug 22 08:08 Check in Early and Often

      The "Coding Horror" blog/mailing list [ http://www.codinghorror.com/blog/ ] has done it again with the missive posted 21 Aug 2008 02:59 AM CDT. This describes how I prefer to develop code and even what I've shown students.

      Quote from [ 001165.html ]

        Perhaps what we need is a model of software accretion. Start with a tiny fragment of code that does almost nothing. Look on the bright side -- code that does nothing can't have many bugs! Test it, and check it in. Add one more small feature. Test that feature, and check it in. Add another small feature. Test that, and check it in. Daily. Hourly, even. You always have functional software. It may not do much, but it runs. And with every checkin it becomes infinitesimally more functional.

      Image: A pearl in an oyster [ oyster.jpg ]

      2008-08-21 Thu Aug 21 21:08 Meyer on Testing

      Bertrand Meyer has been a leading language designer and methodologist for a decade or two. Here he shares his conclusions on testing.


      1. Bertrand Meyer
      2. Seven Principles of Software Testing
      4. IEEE Computer Magazine V41n8(Aug 2008)pp99-101
      5. Principles
        1. Testing means trying to make the software fail.
        2. Tests are not a substitute for specifications.
        3. Regression tests: Any failure must become permanent test...
        4. Determining succes vs failure should be automatic -- use oracles. Base oracles on contracts.
        5. Good testing has both manual and automatic tests.
        6. Evaluate testing using objective and explicit criteria.
        7. The most important property for a test is the number of faults uncovered as a function of time.

      2008-08-20 Wed Aug 20 20:08 Rich Internet Applications

      I've just visitted a demonstration of MicroSofts SilverLight plugin so that I can look at real time medal counts in the Olympic games (TBA) and then read about the new technologies for doing exciting things on web pages.


      1. George Lawton
      2. New ways to build rich internet applications
      3. =ADVERT RIA Ajax Google GWT Microsoft ASP.Net Silverlight Adobe Flash AIR Flex JavaFX
      4. IEEE Computer Magazine V41n8(Aug 2008)pp10-12
      5. RIA::="Rich Internet Applications".
      6. Technology for more powerful clients in a client-server system -- mainly as plugin to a browser.
      7. Several competing new systems.

      2008-08-19 Tue Aug 19 12:08 People of Computing


      1. Mark Doernhoefer
      2. Surfing the net for software engineering notes: Computer People
      3. ACM SIGSOFT SEN V33n4(Jul 2008)p7-16 [ 1384139.1384149 ]
      5. Allan Turing, John von Neumann, John W Mauchly, J Presper Eckert, C A R Hoare, Edsger Dijkstra, David Parnas, Grace Murray Hopper, Barry Boehm, Frederick Brooks, Brian Kernighan, Dennis Ritchie, Ken Thompson, Alan Perlis, Niclaus Wirth, Donald Knuth, Richard Hamming, Edgar Frank Codd, Gordon Bell, Gary Kildall, ...

      2008-08-18 Mon Aug 18 16:08 Leroy Seifers dies of Cancer

      Those who suffer from from cancer and listen to American National Public Radio [ index.html ] will miss him.

      As he said -- knowing you are not alone is important. Spare a thought for him, his family, and for all who have been diagnosed with cancer.

      Wikepedia -- [ Leroy_Sievers ]

      My cancer is still, as far as I can tell, quiescent; thanks to hormone treatment.

      2008-08-15 Fri Aug 15 18:08 Donald Knuth

      Donald knuth's work casts a gigantic shadow accross my life. His books on the "art of Computer Programming" have inspired my research and teaching and tantalysed me. So the following interview interested me. It also has a couple of interesting quotations. One makes the case for the kind of tight feedback loop between user and programmer that is in XP. The other is completely opposed to one of the agile rules of good code. I agree with his comments on comments.


      1. Len Shustek (Ed)
      2. Interview -- Donald Knuth: A Life's Work Interupted
      4. Commun ACM V51n8(Aug 2008)pp31-35 [ 1378704.1378715 ]
      5. p32: "almost every five minutes as you are writing code, a question comes up that was not addressed in the specification"
      6. p34: "the key to good exposition is to say everything twice: informally and formally"
      7. p34: "In writing a computer program, it is also natural to say every thing in the program twice" -- once for the human reader and once for the computer.

        1. (XP)|-"Don't Repeat Yourself".

        (Close But )
      8. Comments should explain why, what does not work, and any subtleties.

      2008-08-14 Thu Aug 14 13:08 Fads and Silver Bullets

      Two articles in the latest Communications of the ACM discuss the fads that keep popping up in software development. The first is a light hearted tour of current and past Silver Bullets and the second studies the rise and fall of the CORBA standard for handling distributed objects. For an expert discussion of the same phenomen see [ 2008-06-25 Wed Jun 25 11:06 No Silver Bullets Again ] below.


      1. Alex E Bell
      2. Software Development amidst the whiz of silver bullets
      4. Commun ACM V51n8(Aug 2008)pp22-24 [ 1378704.1378712 ]
      5. Names some previous failed fads.
      6. Describes current (200n) fads.
      7. Fads sound good but do not solve the real problems of software development.


      1. Michi Henning
      2. The Rise and Fall of CORBA
      4. Commun ACM V51n8(Aug 2008)pp53-57 [ 1378704.1378718 ]
      5. CORBA_history::=bleeding_edge_technology; popular_middleware; obscure_niche_technology, -- why?
      6. Two technical issues: complexity and missing features,
      7. Reasons endemic in a democratic open consortium of customers and vendors.
      8. OMG_process::=customers generate a fuzzy and possible umimplementable RFP; vendors propose their own rival solutions with no implementation; solutions are merged with no reference implementation.
      9. Process does not create high quality standards.
      10. Proposals
        1. Only standardize existing best practice.
        2. No standard approved without a reference implementation.
        3. No standard approved without being used on realistic projects.

      11. Compare open source projects
        1. Ideas developed as competing working solutions.
        2. It is more important to say "No" than to say "Yes". A dictator or cabal is useful for saying "No" to bad RFPs. Compare [Shirky03] [DenningYaholkovsky08] on problems with getting collaborative solutions.

      12. (dick)|-UML is another OMG standard of growing complexity with no reference implementation...

      2008-08-13 Wed Aug 13 15:08 Mathematicians in the Movies

      In the previous post on this topic (below) I forgot a most excellent protrayal of a sane mathematician. It was an Australian movie called "The Bank". The mathematician is hired by a bank to develop software that will let them predict stock market changes precisely enough to make a lot of money.... From the Mandelbrot fractals for the titles (which turn out to be relevant) to the final twist it was excellent. And you didn't have to be mathematically literate to appreciate the characters and the plot.

      Reccommended -- if you can find it -- "The Bank" [ HTMLindex.html ] (links to a Flash trailer, stills, etc etc).

      By the way -- I've rescheduled my fall office hours and will be back on campus next Tuesday 19th August, not Wednsday. See [ plan.html ]

      2008-08-12 Tue Aug 12 15:08 Everything old is new again

      Back in the 80's I worked on the performance of disk based data structures. I had original met this when optimizing data base performance in SSADM ( [ samples/methods.html#SSADM ] ) by denormalizing data and other tricks during Physical Design Control. Moving from the logically correct normal data base to a tuned design would make the difference between a feasible system and one that was too slow. The key paper [PechuraShoefler83] demonstrated that the time to access a record on a disk was directly proportional to the number of tracks moved:
    3. T = a + b * t, where t is the number of tracks and T the time. This leads one to be wary of accessing data at random on a disk (where t = F/3, where F is the number of tracks in the file). Serial access was the better way to access a large number of records on disk.

      From this it followed that many of the formula that hold for algorithms that use RAM do not hold when the there is so much data that it is spread out on a disk. For example, a binary search of an array of n data items takes an average time of log(n) if the data is in RAM, but if it covers a large piece of a disk then the time is O(n) [Botting88].

      So I was attracted by the title of the following article, and then gratified by some of the conclusions.


      1. Daniel Kunkle & Gene Cooperman
      2. Solving Rubik's Cube: Disk is the New RAM
      3. Commun ACM V51n4(Apr 2008)pp31-33
      5. Many disks give the same bandwidth as RAM when accessed by many CPUs.
      6. But must avoid random access to disk. Use disk sorts + collation + RAM caches instead.

      2008-08-11 Mon Aug 11 16:08 Back from Oceanside

      I've been pleasantly offline for 7 days.

      Now for the latest, local, event involving PSP -- the Personal Software Process. [Humphrey94] =ADVERT PSP . . . [Humphrey95a] =TEXT PSP IMPROVEMENT ESTIMATION METRICS . . . [Humphrey95b] =ADVERT for . . . [Humphrey96] =advert for PSP . . . [Humphey97] =TEXT PROCESS PEOPLE CMM PSP IMPROVEMENT PAPERWORK STANDARDS . . . [Humphrey00] =TEXT PROCESS PEOPLE TEAM CMM PSP IMPROVEMENT PAPERWORK MANAGEMENT . . . [Humphrey00b0] =SURVEY Etc.

      PSP is a way of improving one's ability to develop software by following a defined series of steps and taking detailed measurements on the artifacts produced in each step. This is followed by doing statistics on the measurements. Thus you can make better estimates and also spot improvements. This is all inspired but Quality Control techniques that are standard in factories.

      There are two problems with the PSP found in Watts Humphreys. One is tendency to encourage "Big Design Upfront" with detailed design artifacts being developed before code: [ wiki?ExtremePspExperience ] The other is the time taken to gather the data using forms. Paul Conrad [ seminar/20060519PaulConrad.html ] proposed developing Eclipse plugins to gather the stats. Now we have Tom Gigler's Moops !


      1. Tom Gigler
      2. Moops: A Web Implementation of the Personal Software Process Reporting System
      4. CSUSB MS Project (May 2008)

      2008-07-31 Thu Jul 31 16:07 Taking a Break

      I'll be out of town and offline for most of next week.

      By the way I'm now on Facebook [ 1341350809 ] and will probably using it during the coming quarter.

      2008-07-31 Thu Jul 31 15:07 Good Source and Open Source

      First a welsome to "Kode Vicious" a new column on the Communications of the ACM. Second a nice summary of the growing status of open source and the various resarch directions associated with it.


      1. George V Neville-Neil
      2. Kode Vicious: Beautiful code exists, if you know where to look
      4. Commun ACM V51n7(Jul 2008)pp23-25 [ 1364782.1364791 ]
      5. First quotes a piece of "Good" code -- deep in the BSD Kernel.
      6. Good code -- version numbers, named constants, objects in C, separate CPU dependent from CPU independent code.
      7. Prototyping -- use it to find out where the difficult problems are not to give marketting something "pretty".


      1. Phillip A. Laplante
      2. Open Source: The Dark Horse of Software?
      4. Computer Reviews (Jul 2008) [ hottopic_essay_09.cfm ]

      2008-07-30 Wed Jul 30 16:07 More on the dark side of XML

      It's good to see more on the diseases associated with XML -- even if this article is not easy to read.


      1. Erik Wilde & Robert J Glushko
      2. XML Fever
      4. Commun ACM V51n7(Jul 2008)pp40-46
      5. Lists the various strains of XML fever according to the experience of the XML users.
      6. The best thing about XML is its worst feature -- being able to easily create complex new formats for data.
      7. Example: using natural language for tag and attribute names does not make XML self describing. It does not define the semantics.
      8. Problems handling non-tree-structured data.
      9. Disease: Using XML with no schema.
      10. XML tools encourage data oriented documents -- not multimedia.
      11. RDF::="Resource Description Framework".

      For more on this topic see Spinellis08 and YAML below. For an early diagnosis see [Hohpe02] from 2002.

      2008-07-29 Tue Jul 29 13:07 Change of Plan

      I've come into campus/office one day early this week. Need to be home tomorrow...

      2008-07-29 Tue Jul 29 11:07 Requirements Engineering on the Web

      I'm a fan of the ACM Software Engineering Notes journal/magazine. I read the "RISKS to the Public..." column in each issue. I also look at Mark Doernhoefer's column reviewing relevant web pages. So here is my picks for his latest column plus a link to the article on the ACM web site.


      1. Mark Doernhoefer
      2. Surfing the Net for Software Engineering Notes: Requirements
      4. ACM SIGSOFT Software Engineering Notes V33n3(May 2008)pp7-16 [ 1360602.1360606 ]
      5. Includes

      By the way I've fixed the broken YAML link from May below...

      2008-07-28 Mon Jul 28 17:07 Many names for pursuit of quality systems

      I see that one of my hobby-horses has just turned up in the literature again. The question is how to ensure that software works. Over the decades I've advocated or seen advocated many techniques. For example:

      SQA (Software Quality Assurance) emphasized adapting techniques use in manufacturing goods and in particular inspections. Inspections are still a practical, effective technique for finding defects, and an active research topic (see below).

      V&V (Validation and Verification ??) is another buzz phrase for testing and manual review techniques for checking: (1) the software works as specified, and (2) the specification give the stakeholders what they want.

      In my experience you can produce software that is defect free as long as you have a lot of extra time to develop proofs of correctness. It took me months to prove that the machine code routines in my graphic system did precisely what I wanted. THe bugs then appeared in the unproven pieces of code. I was able to extend them to some strange environments: COBOL for example, but the techniques do not scale.

      I've spent several years with data directed methods of program design. These avoid proofs by constructing software that clearly must work. A precise grammatical definition of the input and output of a program is mapped directly into the code that produces the required output from the given input. Combine these methods with SQA (above) makes the production of working data processing programs a slow but reliable process.

      Model-checking also avoids the need for program proving by making a mathematical abstraction of the solution and a logical model of the requirements. Then the various model-checking tools search cases where the solution does not produce the required results. These are very effective but again not cheap.


      1. Leah Hoffman
      2. In Search of Dependable Design
      4. Commun ACM V51n7(Jul 2008)pp14-16
      5. History: Intel Pentium Bug, FBI virtual case file, IRS tax-processing
      6. Impact of software on life and estimated costs of defects is increasing... NIST estimates $59.5 billion lost per year.
      7. Daniel Jackson: Need for precise requirements.
      8. Model checking [ Hoffman08b ]
      9. Eiffel [Meyer90] [Meyer91]
      10. Alloy
      11. Booch: human communication is critical, not coding.


      1. Leah Hoffman
      2. Talking Model-checking Technology
      4. Commun ACM V51n7(Jul 2008)pp112+110-111
      5. Interview with Turing prize winners E Allen Emerson & Edmund M Clark & Joseph Sifakis
      6. Painful birth: theoretically trivial and practically impossible!
      7. Handle programs that do not stop. Avoid humans proving programs. Based on finite state abstractions of program+hardware and requirements specified in temporal logic. If property is not satisfied by abstraction then procedure gives a diagnostic trace of the bad behavior.
      8. Problem: State Explosion: no of cases to consider can grow exponentially with the size of the model.
      9. Benefits: precise specifications.
      10. Limits: 10^100 states!
      11. Microsoft has one used for device drivers!


      1. Jamieson M Cobleigh & Gregory Avrunin & Lori A Clarke
      2. Breaking up is Hard to do: An Evaluation of Automated Assume-Guarantee Reasoning
      4. ACM TOSEM Trans Software Eng & Methodology V17n2(Apr 2008)#7pp1-52
      5. Given a system with two or parallel subsystems can we compute the necessary and sufficient conditions for the whole to perform as specified.
      6. FSF::="Finite State Verification".
      7. Using the L* algorithm to find assume-guarantee conditions can slow the process but doesn't waste memory.
      8. Some assume-guarantee conditions discovered where large: 250 states. Not known if this is the best one.

      2008-07-25 Fri Jul 25 10:07 How to get from use case requirements to design class diagrams

      First a quick heads-up. I've updated my [ plan.html ] to show that I will be on campus on all but one Wednsday until the new year starts. Check it out!

      Also -- I've now got a FaceBook entry and one or two friends:-)

      Here are some intriguing results comparing different types of developers, different tools (including pencil and paper), and different ways of approaching object-oriented design. A key result is that with professionals the method and tool doesn't make a difference. However for students the techniques made (contradictory) differences to the qualities of diagrams. SO it appears that experience is a great leveler.


      1. Bente Anda & Dag I Sjoberg
      2. Investigating the role of use cases in the construction of class diagrams
      3. Empirical Software Engineering V10n3(Jul 2005)pp285-309 CR 0807-0688
      5. Experiemnted with students and then with professionals.
      6. Compares two methods for going from usecases to design class diagrams: derivations vs validation.
      7. derivation:= use_case_text->domain_model; sequence_diagrams; design_class_diagram.
      8. validation:= use_case_text-> initial_class_diagram; sequence_diagrams; do( validate; extend).
      9. Measured time, completeness, and quality (coupling and cohesion).
      10. Tools didn't add to diagram quality with either students or professionals.
      11. Tools slowed down students but not professionals.
      12. Students got more complete design classes using validation rather than derivation.
      13. Students got better quality designs with the derivation method.
      14. Professionals -- no significant differences found.

      2008-07-24 Thu Jul 24 16:07 Object-Oriented Software Process Modeling

      I thought the following might be be interesting, but the authors do not seem to be aware of previous proposals or with the Object-Management-Group's attempts to design an OO modeling technique for software processes.


      1. Beatriz Terezinha Borsoi & Jorge Luis Risco Becerra
      2. Definition and modeling of process using object orientation
      3. ACM SIGSOFT Software Engineering Notes archive V33n3 (May 2008) Article No. 2
      5. Compare to earlier proposal [JaccheriPiccoLago99] E^3 OO process language.
          Why not just use the OMG_SPEM?
        1. OMG SPEM::="Software Process Engineering MetaModel", [ modeling_spec_catalog.htm ]

        (Close But )

      2008-07-23 Wed Jul 23 13:07 What is a Requirements Engineer

      I'm always suspicious that any document doesn't quite match the reality it attempts to capture. Just a feeling that some level of detail will be missing between a digitized model and the continuous actuality. "The amp is not the teritory" as Korzibski put it.

      So I expect curriculums to miss vital objectives and standards to some how miss the spirit -- even tho' both are vital and useful.

      Here is a description of a standard curriculum for requirements engineers.


      1. Barbara Paech
      2. What is a Requirements Engineer?
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp16-17 [ en ]
      5. Gives headings for new syllabus for certifying basic knowledge for requirements engineers.
      6. Industry-oriented
      7. Part of the SWEBOK -- Software Engineering Body of Knowledge.
      8. But how to certify experience and skill?

      2008-07-22 Tue Jul 22 16:07 Statistics about projects

      Recent publications have quoted some interesting statistics. Robert Glass reports his discovery --decades ago -- that even thorough "all-path" testing does not find 60% of errors. Les Hatton has experimented with the use of checklists when inspecting source code -- and finds that checklists made no significant difference. Most of the difference in finding errors is due to the skill of the inspector. A detailed study of open source projects shows how the complexity of the source code suddenly changes -- both in magnitude and in form. Diomedis Spinellis has counted the use of formatting in code and discovered that more than half of the characters in the code are their to make the code more readable by humans. Finally, a group of researchers have experimented with the use of the UML in maintainence and found that it improves the quality significantly for a non-significant delay.

      So: don't rely on testing alone, but have good inspectors check your code and UML. And, as always lay out code in a readable way.


      1. Robert L Glass
      2. Two Mistakes and Error-Free Software: A Confession
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp96+95
      5. In the 1970's Glass analysed testing data base and discovered that 35% of errors where omissions and 40% only appear if a combination of pieces of code were taken -- 75% of errors not found by testing every piece of code.
      6. In 1981 analysed errors that are uncovered after going live. 60% were omitted code, and 23% were failing to reset data.
      7. Conclusion: good testing does not expose most errors.


      1. Les Hatton
      2. Testing the value of checklists in code inspections
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp-
      5. No evidence that checklists decreased the number of undetected faults in a program.
      6. Idea to use capture-recapture techniques.
      7. Tried both allowing engineers to use checklists and mandatin that some used checklists.
      8. Effectiveness : the best engineers found 10 times as many faults as the worst engineers.
      9. Two person teams can increase per centage found from (average) 53% to 76%.
      10. Raw Data [ Data_Inspections_05_06_2007 ]


      1. Raghvinder S Sangwan & Pamella Vercellone-Smith & Phillip A Laplante
      2. Structural Epochs in the complexity of software over time
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp66-73
      5. XS::Metric="Excessive Structural Complexity", Tangles + Fat!
      6. In open source development complexity slower increases and trhen suddenly drops.
      7. The drop in complexity occurs as complexityanges levels.


      1. Diomidis Spinellis
      2. The way we program
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp89-91
      5. Figure 1 is an excellent obfuscated piece of C code.
      6. Also did the stats on 2 dozen open source projects.
      7. More than half of the source code is there to help developers communicate with each other not with the computer.


      1. Wojciech James Dzidek & Erik Arisholm & Lionel C Briand
      2. Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance
      4. IEEE Trans Software Engineering V34n2(May/Jun 2008)pp407-432
      5. Use 20 real developers to maintain real software!
      6. BESTweb:=Internal bibliographic data base on software cost and effort estimation. Realistic (1..2 weeks) tasks. Half had UML diagrams.
      7. Replicates on [Arisholm06BriandHoveLabiche06]
      8. UML improves quality significantly with only a 14% worse time.

      2008-07-21 Mon Jul 21 12:07 Set of articles on Managing software projects

      Back in the office again to give the older Dell it's monthly updates. This time experimented with taking the bus to campus while carrying the machine. Now to see if I can get it home again.

      The following will be of most use to managers, tho's there is little surprising here.


      1. Charalambos L Iacovou & Robbie Nakatsu
      2. A Risk profile of offshore-Outsourced Development Projects
      4. Commun ACM V51n6(Jun 2008)pp89-94
      5. It sounds like the usual suspects: lack of management commitment, miscommunicated requirements, Inadequate user involvement, Failing to manage expectations, Poor change control, developers don't understand the business or the technology, unexpected costs.


      1. Richard T Watson & Marie-Claude Boudreau & Paul T York & Martina E Greiner & Donald Wynn Jr
      2. The Businesss of Open Source
      3. Commun ACM V51n4(Apr 2008)pp41-
      4. =POLL MANAGERS CEOs OPEN SOURCE ONE SIZE OSSg2 Trolltech Qt Qtopia MySQL Sleepycat Berkely DB JBoss JEMS Hibernate Tomcat
      5. Hire the best programmers and pay well.
      6. Dual licensing: free to use, license to modify and sell.


      1. Tracy Hall & Helen Sharp & Sarah Beecham & Nathan Baddoo & Hugh Robinson
      2. What do we know about developer motivation
      4. IEEE Software Magazine V25n4(Jul/Aug 2008)pp92-94
      5. Developers motivation is not a simple thing but complex and includes these specific ones: challenge, change, benefit, problem solving, team work, science, experiment, and best practices.

      2008-07-18 Fri Jul 18 05:07 Back

      We flew in Monday night and it took until Midnight to get home. Add to this that our internal clocks are 8 hours forward.... So at 4 this morning (lunchtime in England) I found my self reading the IEEE Software Magazine V25n4 (Jul/Aug 2008). It is a special issue dedicated to devloping software for scientists. The editorial introduction (see page 19 and Figures 1 and 3) describes how scientists continually adjust there requirements as they use the software -- thus causing major problems to software engineers with a non-itterative life cycle.

      This fits well with a paper/article I read 30 years ago ( [click here [socket symbol] if you can fill this hole] ) which showed that 90% of the runs of software in a large, well run, laboratory failed. It turned out that a scientist evolves the software until it produces the required result and then discards and moves on to a new program.

      Quite different to data processing where a program is developed and then used for years (with small changes). Here you get a clear maintenance phase made up of small changed plus occasional catestrophic rewrites and replacement as the technology and/or stakeholders change.

      The only constant is iteration -- even in the Tower of London. Which has been rebuilt and modified and patch for a 1000yeras... by the way -- it is worth a visit.

      Remind me to to write up the failure of interaction design in the new rolling stock on South Western Railways -- 100% of a small (4), non-scientific sample of users couldn't figure out how to open or close the door of the new lavatories.

      2008-06-29 Sun Jun 29 07:06 Taking a break

      I'm about to fly home to England until July 14th. Wish me luck....

      I'll restart this weblog in the middle of next month.

      2008-06-28 Sat Jun 28 09:06 Expensive user or user interface mistakes

      Who should pay if the user mistypes a number and the interface does not do a " Sanity check " that would have found the error?


      1. Kai A Olsen
      2. The $100,000 Keying error
      3. IEEE Computer Magazine V41n4(Apr 2008)pp108+106-107 + Correspondence V41n6(Jun 2008)p7
      5. System accepted an extra digit in an account number and sent money to wrong account.
      6. In experimental web-based simulation with "confirm" 124/1,778 transactions had errors.
      7. 29% of wrong number had extra digits in a sequence of repeated digits. Modulo 11 would find all but 3.
      8. Confirmation does not catch common errors.
      9. Always spot and highlight too many digits -- (Sanity check)
      10. Need other checks of all user input. Example: modulo 11 CRC.
      11. (Alan Quirt)|-typed comma for period and multiplied payment 100 times.
      12. (dick)|-give a picking list rather than expecting user to input characters.

      2008-06-27 Fri Jun 27 13:06 Positive demonstrations

      The literature of software development is full of papers and articles demonstrating a new idea, methid, technique or technology ad make large claims as to the value of the idea... It is only in the lat five or six years that solid experimental and exmpirical work has started to appear to back up these ideas.

      So here are two positive and plausible ideas... (1) use Aspects to implement Features in an iterative "feature-driven" process. (2) Use tools that combine text and diagrams in a seamless way.


      1. Sven Apel & Thomas Leach & Gunter Saake
      2. Aspectual Feature Modules
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp162-180
      5. AFM::="Aspectual Feature Module", combines iterative Feature Oriented Programming (FOP) with Aspect Oriented Programming(AOP).


      1. Dov Dori
      2. Words from Pictures for Dual-Channel Processing
      4. Commun ACM V51n5(May 2008)#7pp47-52
      5. Claims that automatically linking diagrams to text makes process more intuitive. [MillerJ02]

      2008-06-26 Thu Jun 26 11:06 Standards for Small Enterprises

      More evidence (also see [OktabaEtAl07] ) that software develpment standards do not fit all companies equally.


      1. Claude Y Laporte & Simon Alexandre & Alain Renault
      2. Developing International Standards for Very Small Enterprises
      3. IEEE Computer Magazine V41n3(Mar 2008)pp98-102
      5. Survey shows that small enterprises don't implement ISO standards because (1) no resources, (2) not required, & (3) standards are difficult bureucratic and don't fit small businesses.
      6. Working Group 24 is developing special standard profiles and packages for small enterprises.
      7. Some enterprises will try out the new standards -- real soon now.
      8. See [ index.html ] [ indexEN.php3 ]
      9. (dick)|-This might fix the problems recently reported with ISO/IEC standards [Glass07a]

      2008-06-25 Wed Jun 25 11:06 No Silver Bullets Again

      One or two papers make a gigantic impact on software engineering. Fred Brookes's 1987 article "No Silver Bullets" is one of these... ten years later people are still discussing it's thesis:
    4. Software development is in essence difficult.


      1. Steven Fraser & Dennis Manci
      2. No Silver Bullet: Software Engineering Reloaded
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp91-94
      5. Fred Brookes + David Parnas + Linda Northrop + Aki Namioka + Dave Thomas + Ricardo Lopez + Martin Fowler.
      6. Guess who turned into a werewolf!
      7. Video on YouTube!
      8. All because of [Brooks87]
      9. Also see [Cox90a] [Harel92]

      2008-06-24 Tue Jun 24 14:06 Cones and acronyms

      A couple of essays on software development. Both refer to the idea of the cone of uncertainty. One has too many acronyms, but summarizes a lot of accumulated wisdom.


      1. Barry Boehm
      2. Making a Difference in the Software Century
      3. IEEE Computer Magazine V41n3(Mar 2008)pp32-38
      5. Rapid change vs
      6. THWADI::="Thats How We've Always Done It".
      7. Uncertainty and Emergence. Cone of Uncertainty. [Armour08]
      8. BITAR::="Buy Information To Avoid Risk", Do extra things to reduce uncertainty.
      9. IKIWISI::="I'll know it when I see it". So Iterate.
      10. Dependability
      11. DAVAS::="Dependability As Value Assured to Stakeholders". Example of conflicting values in a well known failed project.
      12. Diversity.
      13. OSUFA::="One Size Fits All". Culture makes a difference in the adoption of process standards.
      14. SISOS::="Software Intensive Systems of Systems". OSUFA leads to failure
      15. Interdependence.
      16. TANIA::="There Are No Islands Anymore". No part of a system or of a process is isolated.
      17. Figure 5, p36: Activities >< Phases >-> Level_of_activity, CF RUP.
      18. SISOS need more time for Architecture and Risks.


      1. Phillip G Armour
      2. The inaccurate conception
      3. Commun ACM V51n3(Mar 2008)pp13-16
      5. Cone_of_uncertainty::=map[t:time]([1/f(t) .. f(t)]* actual ), for some dcreasing function f. "Describes how estimates get more accurate as a project proceeds". At that start of new product estimates are between [0.25 .. 4.0] times the actual value. Tightens as uncertainties are removed.
      6. Express estimates as a distribution mapping qualities to probability of success. S shaped curve.
      7. commitment is not an estimate.

      2008-06-23 Mon Jun 23 16:06 Experiments on TDD and Pair programming

      Two recent ideas in programming are (1) test driven development [Beck01] [Reifer02] [ErdogmasMorisioTorchiano05] and (2) Pair programming. I've documented quite a few papers and articles about these particular tricks. In test-driven design you write the tests before you write the code and in pair programming changes to code are made by one person while another person watches and makes comments. These two following experiments try to find out how these two techniques work.


      1. David S Janzen & Hossein Saidian
      2. Does Test-Driven Development Really Improve Software Design Quality?
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp77-84
      5. Evidence that TDD is associated with simpler and better tested modules.
      6. Two myths: TDD means (1) write all tests first or (2) automate all the testing. [JanzenSaiedian05]
      7. TDD::process=High-level design; TDD_design_and_code; test.
      8. TDD_design_and_code::= unit_test; code; refactor; O(TDD_design_and_code).


      1. Kim Man Lui & Keith C C Chan & John Teofil Nosek
      2. The Effect of pairs in program design Tasks
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp197-211
      5. Used aptitude tests to act as a surogate for programming and eliminate language skill effects.
      6. Pairs substantially outperformed individuals in procedural/algorithmic design tasks.
      7. Pairs substantially outperformed individuals in deductive problem solving.
      8. Fewer errors. Faster time.

      2008-06-21 Sat Jun 21 08:06 VBScript Samples

      I've just been asked
        canyou providesample vb scripts

        From: Nsunil

      Nsunil didn't give me an EMail address to reply to, so I'll reply here.

      This site does have examples of code in many languages but nearly all of them have been written by students as part of their course work. See [ samples/ ] for these. When I have written up a language it is to help me learn the language. So far nobody has tackled any members of the VB (Visual Basic) family. [click here [socket symbol] VB if you can fill this hole]

      By the way -- this site does not host answers to home work questions.

      2008-06-20 Fri Jun 20 14:06 Toulmin Arguments Rebuttals

      I've been researching the work of Stephen Toulmin and its use in Reqirements Engineering. I've reworked [HaleyLaneyMoffettNuseibeh08] a little as a result and have added a new pair of directives (.But and .Close.But) to my MATHS language. Here is the background reading. See [ChesnevarMaguitmanLoui00] for a history.


      1. Stephen Edelston Toulmin
      2. The uses of argument.
      3. Cambridge [Eng.] University Press, 1958 BC177
      5. Developed into text [ToulminRiekeJanik78]


      1. Stephen E Toulmin & Richard Rieke & Allan Janik
      2. An introduction to reasoning
      3. Macmillan, c1979. New York BC177 .T59
      5. Based on [Toulmin58]
      6. Toulmin_argument::=data "--->" O(qualifier) claim ", " warrant O(backing) O(rebuttal) .
         Data -------------> (Qualifier) Claim
      7. Toulmin_argument::=following
        1. Claim::Utterance, conclusions
        2. Data::Utterance, facts
        3. Warrant::Utterance, general rule linking the data to the claim.
        4. Backing::Utterance, credentials when the warrant is not convincing enough.
        5. Rebuttal::Utterance, restrictions which apply to the claim.
        6. Qualifier::Phrase, possibly, likely, probably, certainly, presumably, necessarily.

        (End of Net)

          [Loui08] [HaleyLaneyMoffettNuseibeh08]

        (Close But )


      1. Ronald P. Loui
      2. A Modest Proposal for Annotating the Dialectical State of a Dispute
      3. SCRIPTed V5n1(2008)#176 [ loui.asp ]
      4. =ESSAY REBUTS Toulmin diagrams KISS RATIONALE


      5. Just list the data for a conclusion underneath the conclusion with the rebuttals etc ?(hidden) beside them.
      6. Or use a simple tree diagram: children support parents and rebuttals have a heavy horizontal link to what they rebut.

      2008-06-18 Wed Jun 18 15:06 Design as Iteration

      Here is a collection of papers and articles on the topic of how to design software. First DenningYaholkovsky08 bewail the lack of tools that help people become a team that can solve a wicked problem. WirfsBrock08 suggests some steps to help design. Glass08b notes the impossibility of supporting a single designer's intuitive process with current technology. He notes that design is iterative... a common theme. HadarLeron08 show that object-oriented design is not obvious but has to be overlaid on top of intuitive ideas. HallRapanottiJackson08 propose POSE -- a new way to manage and document the design process. This is the first method that has explicit backtracking steps the replace previous designs by better ones. Also one which seems to be able to work with many and all notation. Finally Patton08a praise iterative design methods that test early and test often.


      1. Peter J Denning & Peter Yaholkovsky
      2. Getting to "We"
      3. Commun ACM V51n4(Apr 2008)pp19-24
      5. Collaboration is when people create synergistic solutions|strategies
      6. Notes that tools support communication, coordination and cooperation rather than collaboration.


      1. Rebecca J Wirfs-Brock
      2. Design Strategy
      4. IEEE Software Magazine V25n3(May/Jun 2008)pp14-15
      5. Design is hard -- you need to choose your battles. Focus on What??
      6. First share/note stories about hopes,wishes, fears, convictions, ... .
      7. Sort out certainties, unknowns, nagging concerns.
      8. In meeting all (write; read; note) stories.
      9. Find out stakeholder priorities and desired qualities -- it can drive design.
      10. Distinguishes: core design work | revealing design problems | the rest.
      11. Revealing problems tend to be wicked.
      12. Focus on the core first.
      13. Don't forget domain models.


      1. Robert L Glass
      2. Software design and the Monkeys brain
      4. Commun ACM V51n6(Jun 2008)pp- 2008)pp21-22
      5. Research showed mental design process: understand problem; create solution; do(test; modify); tests OK.
      6. Tools & methods slow process down.
      7. Unless can record directly the designers brain!


      1. Irit Hadar & Uri Leron
      2. How Intuitive is Object-Oriented Design
      4. Commun ACM V51n5(May 2008)pp- 2008)#7pp41-46
      5. Distinguishes two different modes of thought: S1 and S2.
      6. S1: fast, automatic, effortless, unconcious, and inflexible.
      7. S2: slow, concious, effortful, but relatively flexible.
      8. S2 acts a s amonitor and critic of S1.
      9. Inheritance is backward(S1).
      10. Surface features (S1) lead to bad OODs.
      11. Confusing abstract and concrete classes (S1).
      12. Identifying coding with development (S1).
      13. It is hard to replace S1 with S2.


      1. Jon G Hall & Lucia Rapanotti & Michael A Jackson
      2. Problem Oriented Software Engineering: Solving the Package Router Control Problem
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp226-241
      5. POSE::="Problem Oriented Software Engineering", based on Jackson's Problem Frames [Jackson01] , using informal or formal satisfaction arguments that target stakeholders, refinement, iteration, backtracking, etc.,
      6. Models a problem+solution as a set of Domains+Solution+Requirements
         	D[1],...D[2], S |- R
      7. A Gentzen Sequent!
      8. Domains have a name(N) and description(E) that mentions phenomena: controlled(c), observed(o), and unshared(p):
         	D(p)[o]^c = N : E
      9. Solutions are a domain.
      10. Requirements have a name and description that constrains(c) certain phenomena and refers (r) to other phenomena:
         	R[r]^c = N : E.
      11. Progress is made by transforming problems (like inference rules in SOS or Natural Deduction). Each transformation has NAME and an adequacy argument.
      12. Arguments have a Justification, Includes, Concerns, Phenomena, and Resulting Problems (if any).
      13. Sample of Problem Transformations
        1. CONTEXT INTERPRETATION Justify a new description of a domain.
        2. REQUIREMENT INTERPRETATION Justify an expanded requirement
        3. SOLUTION INTERPRETATION Justify the expansion of the solution. Example: nSep. Separation into independent parts. Example: applying the MVC pattern. Example: Using an analogic model.
        4. SEPARABLE PROBLEM Explain how one problem becomes a set of independent problems
        5. PROBLEM PROGRESSION Changes requirements
        6. SOLUTION EXPANSION Moves known components into environment and generates a set of problems to be solved.
        7. Backtracking. Justify the abandonment of a previous solution and replacement by a new one.

      14. Has been tested in a safety critical system -- avionics -- using Alloy.
      15. Development involves learning about the context of the problem as well as about the requirements and solutions.
      16. Justifications must satisfy the stakeholders. Different stakeholders will need different justifications.
      17. Development is an iterative activity. Concerns lead to backtracking.


      1. Jeff Patton
      2. Getting Software RITE
      4. IEEE Software Magazine V25n3(May/Jun 2008)pp20-21
      5. RITE::="Rapid Iterative Testing and Evaluation".
      6. RITE_iteration::=do(test; fix).
      7. Problem: your shiny new software confuses your stakeholders.
      8. Solution: Acceptance testing.
      9. Defines formal testing.
      10. Compares to lite testing of paper low-tech prototypes initially.
      11. RITE -- pool of users, lots of iterations, electronic share prototypes.
      12. Not specs but prototypes.

      2008-06-17 Tue Jun 17 10:06 Mathematicians and Movies

      I guess it all starts with Archimedes running naked through the streets of Syracuse [ math.html ] , bearing in mind that the ancient Greek athletes were naked....

      But then you have "A Beautiful Mind" showing the peril of a mind that can see patterns anywhere... and then "Proof" where the daughter of a dead and insane mathematician may just be starting to show the same brilliance and possible instability. In both cases the movies are very well made and the acting most excellent. But do you really have to be crazy to do mathematics -- I hope not.

      But it is peculiar how you can suddenly see something that becomes in retrospect entirely obvious -- especially in a field that you know well.

      So last night at 3am I realized that my MATHS system may be capable of expressing Russell's Paradox.... and then at 6am that I'd already noted the danger of eXtreme BNF -- -- --(XBNF)
      defining sets that can not exist. Hence an update to [ papers/rjb08.xbnf.html ] a old seminar paper.

      By the way, but not unrelated, I just revized the wikipedia entry on Russell's "Axiom of Reducibility".

      2008-06-16 Mon Jun 16 16:06 Finding Defects in software

      One of the topics I researched and wrote up while with the British Civil Service (1968-82) was Software Quality Assurance -- how can youi be sure that a piece of software has zero defects, even though it is written by people who make mistakes. We had a half-a-dozen techniques including Desk Checking, Peer Review, Walkthroughs, and Fagan's Inspections.

      Fagan's technique [Fagan76] was one of the few software techniques that generated evidence of its effectiveness. Here are the key properties of Fagan Inspection:

      1. Can be carried out on any artifact.
      2. Looks for major defects that cause the software to misbehave and minor defects which lead to lower quality but no bug.
      3. Is organized by a moderator.
      4. Work is driven by check lists of things to look for.
      5. Inspectors first work alone and then have a meeting to review and collate what they have found.
      6. The producers of the artifact do not take an active part in the hunt for bugs.
      7. ...
      8. The moderator collects statistics on the defects found and tunes the check lists, the rate of inspection, etc. for find as many defects per unit time.

      Shull and Seaman have recorded how this evidence helped the technique be adopted in NASA.


      1. Forrest Shull & Caroline Seaman
      2. Inspecting the History of Inspections: an example of evidence-based technology diffusion
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp88-90
      5. How evidence of effectiveness and adaption of method moved Fagan inspections from IBM to throughout NASA during the late 80's and early 90's.

      2008-06-14 Sat Jun 14 10:06 Catching up on some reading

      If I had had a proper course on logic then I would have learned of Ramsey's work on the foundations of mathematics when I needed it -- 40 years ago. As it happened, I've just finished studying the following which shines a brilliant light on a book ("Principia Mathematica") that has had a very powerful influence on my thinking. The line of thinking lead to MATHS. The good news is that Ramsey's work does not invalidate MATHS.


      1. Frank Plumpton Ramsey (ed R B Braithwaite)
      2. Foundations of mathematics and other Logical Essays
      3. Littlefield Adams, Paterson NJ 1960
      5. Essays, papers, reviews, and notes dating from the 1920s.
        1. Published
          1. The Foundations of Mathematics 1925
          2. Mathematical Logic 1926
          3. On a Problem of Formal Logic 1928
          4. Note on the preceeding paper 1926
          5. Facts and Propositions 1927

        2. Unpublished
          1. Truth and probability 1926
          2. Further Considerations 1928
          3. Last Papers 1928

        3. Appendix: Critical Notice of L Wittgenstein's "Tractatus Logico-Philosophicus"

      6. PM::="Principia Mathematica", [WhiteheadRussell63].
      7. Dispenses with PM's pphilosophical axiom of reducibility by using Wittgenstein's Tractatus Logico-Philosophicus.
        1. PM gives a syntactic definition set of special predicative truth functions to avoid paradoxes and then has to assume that all sets (for example) of objects of a given type can be expressed using one of these functions.
        2. Ramsey uses a semantic definition from Wittgenstein that makes any truth function predicative.

      8. Argues for the need for a theory of types.
      9. Does not discard axioms of infinity and selection.
        1. PM's Axiom of infinity asserts the existence of an infinite domain, Needed to define infinite numbers. Because, in PM, numbers measure the size of sets of objects of a particular type. Indeed a number is a set of all sets with the same size of that type. So the largest number for a given type is = to the size of the type.
        2. PM's Axiom of selection is equivalent to the Axiom of Choice [ wikipedia ]

      2008-06-13 Fri Jun 13 15:06 Workload and workflow

      Understanding (=? documenting) the work needed for various tasks is a useful step in developing software. Here are two articles on the two uses of the information.


      1. Alan J Smith
      2. Workloads (Creation and use)
      3. Commun ACM V50n11(Nov 2007)pp43-54


      1. Yolanda Gil & Ewa Deelman & Marc Ellisman & Thomas Fahringer & Geoffrey Fox & Dennis Gannon & Carole Goble & Miron Livny & Luc Moreau & Jim Myers
      2. Examining the challenges of Scientific Workflows
      3. IEEE Computer Magazine V40n12(Dec 2007)pp24-32

      Does anybody know why the Innoculate update process downloads a complete new executable and runs at normal priority? Is it just one of the usual suspects for bad software:

    5. {stupudity, ignorance, malice, ...}.

      2008-06-12 Thu Jun 12 17:06 Fear and loathing of upgrades -- and bugs

      Below you will find [ 2008-05-30 Fri May 30 10:05 Fear and Loathing of Upgrades Part 2 ] [ 2008-05-27 Tue May 27 20:05 Fear and Loathing of Upgrades ] the previous episodes in the saga of upgrading my Palm Tungsten -- I may finally have got the handheld and its two laptops to agree on a collection of categories for Contacts. It only took a couple of weeks.

      Meanwhile here are some statistics about bugs: (1) bugs don't fit a Pareto distribution. (2) You can't tell if a change is clean or buggy by looking at its statistics. Perhaps Kim&Whitehead&Zhang should try the time of day when the change was made. The folk theorem is that work done after 4pm on Friday always needs fixing.


      1. Hongyu Zhang
      2. On the Distribution of Software Faults
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp301-302
      4. =EXPERIMENT STATISTICS PROBABILITY FAULTS BUGS DEFECTS MODULES Eclipse For x:[0..], Pareto(x)::= 1-(γ/x)**β.
      5. Weibull(x)::=1 -exp(-(x/γ)**β).
      6. Weibull predicts % of faults in % of modules better than Pareto in Eclipse.


      1. Sunghun Kim & James Whitehead Jr & Yi Zhang
      2. Clasifying software changes: Clean or Buggy
      3. IEEE Trans Software Engineering V34n2(Mar/Apr 2008)pp181-196
      5. Has a definition of a buggy change -- a change that is later changed and described as a bug/fix etc.
      6. Analyses a dozen open source projects.
      7. Doesn't find a simple way to recognise a change that contains a bug vs a clean change.

      2008-06-11 Wed Jun 11 15:06 Map -- Sort -- Reduce


      1. Jeffrey Dean & Sanjay Ghemawat
      2. MapReduce: Simplified Data Processing on Large Clusters
      3. Commun ACM V51n1(Jan 2008)pp107-113
      5. Very large numbers of problems have been programmed to run on large clusters. Each is written as two (2) functions:
      6. map: Key><Value -> List(Key>< Value),
      7. reduce: Key><List(Value) ->List( Value),
      8. System applies map to some data, sorts data by key and passes it to reduce.
      9. map ->sort -> reduce
      10. All the concurrency, distribution, fault tolerance etc. Is provided by the system not the programmer.
      11. Note: the idea uses functions in LISP and FP(Jim Bachus) and standard in MATHS. Similar techniques used in UNIX/Linux scripts.

      2008-06-10 Tue Jun 10 17:06 Language Design -- English XML BPEL DynAlloy

      I designed my first language before I was taught to program. It was a way of recording operations for a manual calculator. This must have been in the summer of 1963 or 1964. In my first year at college I learned my first programming language (something more primitive than FORTRAN I) and designed my second language as a way to encode flowcharts for input into a computer. Very primitive. Never implemented. The next attempt was a combination of logic and programming mostly done while commuting from Clapham to Uxbridge later in the 1960's. It was inspired by LISP -- but with fewer parentheses. In my graduate work I developed a language for drawing graphics in Algol 60 -- PICTALGOL. It was implemented as a library of procedures. It was used in a few projects in the early 1970's. Meanwhile I started work on ways to record mathematics and logic in a computer readable form. This lead to PINAPL ( PINAPL Is Not A Programming Language) in the 1980s and MATHS in the 1990s onward. I still working on this. I will say nothing of the shorthand I worked out for taking notes that I started in the 1970's and am still tinkering with to this day. No mention of the two dozen programming languages I've learned and used.

      So, I'm always interested in new languages and what people say about old ones. Robert Glass has recently noted the ambiguity of English grammar and phonetics -- how do you pronounce "Gough"? Spinellis gives a very brief style guide for using XML well. Louridas shows how a special XML document type can define a business process. Finally, Frias et al show that an extension of Alloy enables the faster analysis of specifications.


      1. Robert L Glass
      2. On the impurity of the English language
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp96+95


      1. Diomidis Spinellis
      2. Using and Abusing XML
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp88-89
      5. Don't use XML without defining a DTD.
      6. Use standard schemas if possible.
      7. Design own schemas to be used & to express meanings. Eg. Use meaningful tags with attributes in tags!


      1. Panagiotis Louridas
      2. Orchestrating web services with BPEL
      3. IEEE Software Magazine V25n2(Mar/Apr 2008)pp85-87
      5. BPEL::xml= "Business Process Execution Language"
      6. 36 line "Hello World".
      7. p87: Lists resources.
      8. process:=partner_links; variables; fault_handlers; sequence.
      9. First understand the business requirements.


      1. Marcello F Frias & Carlos G Lopez Pombo & Juan P Galeotti & Nazareno M Aguirre
      2. Efficient analysis of DynAlloy Specifications
      3. ACM TOSEM Trans Software Eng & Methodology V17n1(Dec 2007)#4pp1..34
      5. Instead of traces defines {pre}action{post}.
      6. Much faster than Alloy.

      2008-06-09 Mon Jun 9 12:06 Notes on Requirements

      There has been a spate of publications on the connections between technological solutions and business needs. I'll list the citations and notes below. But here is my personal list of things I know about Requirements:
      1. You shouldn't think of requirements as an artifact or as a phase. There are a process, a discipline, a work in progress from the start of a project thru to its obsolescence and replacement. [ CaoRamesh08 ] Requirements never go away, they mutate as technology and processes are changed.
      2. Get out of your office and out from behind the machine. Go to where the problems are. You can learn a lot by just looking. Plan interviews. Avoid rigid development processes [ Codefirst07 ]
      3. What the stakeholders require is not technology but what it can do for them. Your enterprise only needs technology to support its real business needs. Data and information is central to meeting enterprise needs. [ RagowskyLickerGefen08 ] [ Maiden08 ] [ DiesteJuristoShull08 ] [ WagnerPiccoli07 ]
      4. First provide the data, but also provide the desirable qualities: usability, safety, security, etc., to fit the enterprises needs. [ Boegh08 ] [ TondelJaatenMeland08 ] [ HaleyLaneyMoffettNuseibeh08 ] [ Patton08 ] Technology often has a bigger effect on qualities than on the information provided.
      5. You have to understand the real world situation before you propose solutions. Understanding has more value than artifacts and documents. [ DiesteJuristoShull08 ]
      6. Express user functional requirements as simple and specific stories [ Desilets08 ] [ Mugridge08 ] first. Identify the user. Identify what they need. What qualities?
      7. Executable artifacts (even bad ones) are more valuable than documents that can't be executed. [ WingM07 ] [ Rainsberger07a ] So tests are a valuable expression of requirements. [ CaoRamesh08 ] [ MartinMelnick08 ] [ Mugridge08 ]
      8. Can you describe, in detail, what is currently done and how your solution fits into this process? [ WagnerPiccoli07 ] Only connect -- design connections into the current systems information flows.
      9. There is no logical process that derives technical solutions fit what stakeholders say they need. You have to invent and create solutions and then show that the fit the enterprise requirements. [ Maiden08 ]
      10. You can use tools to connect documented requirements to code. [ MohanRamesh07 ] [ BurgeBrown07 ] [ Cleland-HuangEtAl07 ]
      11. Manuals don't introduce new solutions [ RagowskyLickerGefen08 ] -- you need to give training and support.
      12. Throwing a SRS for a new products over a wall for engineers to develop doesn't work well. [ SafayiniEtAl08 ] [ CaoRamesh08 ] [ WagnerPiccoli07 ]
      13. Iteration/Evolution often works well. Both the user's needs, the system requirements, can all the code all evolve together. [ CaoRamesh08 ] But beware the requirements creep that kills projects or makes them unprofitable.


      1. Arik Ragowsky & Paul S Licker & David Gefen
      2. Give me Information, Not technology
      3. Commun ACM V50n12(Jun 2008)23-25
      5. Business users value information and information services.
      6. They perceive IT as providing technology not business value. Technology is not about fixing the projector in the conference room.
      7. Too much technology is bad. Vendors do not help by promising too much. Technical manuals do not help, either.
      8. Systems/Business analysts should focus on user and managers as partners. Find out what information services are needed and only then proceed to Research and Development (R&D) of technology and technical requirements.
      9. Avoid solving non-problems. Listen.
      10. Avoid technical Jargon. Talk business.


      1. Neil Maiden
      2. User Requirements and System Requirements
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp60-
      5. Distinguish user requirements from system requirements.
      6. Need both, separately.
      7. A user requirement comes from a user and describes a new property of the domain or business process. Goals.
      8. A system requirement describes a desirable property of the new system. The system shall .... Use cases or other structured text.
      9. Implementing system requirements should lead to satisfying user requirements -- Satisfaction arguments.
      10. It is a design task to move from user to system requirements.


      1. Frank Safayini & P Robert Duimering & Kimberley Zheng & Natalia Derbentseva & Christopher Poile & Bing Ran
      2. Requirements Engineering in New Product Development
      3. Commun ACM V51n3(Mar 2008)pp77-82
      5. Company divided by functions with outsourced software development. Requirement Engineers separated from Market Sponsors by a Feasibility Analyst.
      6. Requirement Engineers had helpful knowledge but had a weakness with coordination.
      7. Requirement Engineers found less help especially with coordination, knowledge, and communication.
      8. In terms of functions, REs were helped by the software developers. The project manager and feasibility analysts and operations were helped by the REs.
      9. Examples: when Market Sponsors change requirements halfway thru a project the REs see it as unhelpful,.... In reverse, MS finds RE jargon unhelpful.
      10. Article includes proposals. Notes that reorganization would be a good idea that would not fly.
      11. (dick)|-Sounds like the company Dilbert works for. The lists of unhelpful behaviors should be studied by practitioners. No reference to Yourdon's analysis of Market vs Engineering speech. No discussion of possible technologies.


      1. Lan Cao & Balasubramaniam Ramesh
      2. Agile requirements engineering practices: an empirical study
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp60-
      5. Identified 7 practices each with benefits & challenges.
        1. Face-to-face communication not documents.
        2. Iterating (requirements, priorities, planning, reviews, & acceptance tests).
        3. Prototypes.
        4. Test driven development(TDD).

      6. challenges: forgotten qualities, wrong architecture, lack experience of TDD...


      1. Oscar Dieste & Natalie Juristo & Forrest Shull
      2. Understanding the customer: What do we know about Requirements Elicitation
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp11-13
      5. Many techniques and results, see [ s2voe.html ]
      6. Summary:
      7. Plan interviews in advance! Plan a Structure.
      8. Include general question when new to a domain.
      9. Introspective techniques are less useful.
      10. Sorting techniques not as useful as interviews but sometimes quicker.


      1. Alain Desilets
      2. Tell Me a Story
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp14-15
      5. Express user goals as simple, specific, and concrete stories about particular people getting valuable things.


      1. Jorgen Boegh
      2. A New Standard for Quality Requirements
      3. IEEE Software Magazine V25n2(MAr/Apr 2008)pp60-
      5. ISO 9126 Quality model{ {External, Internal}><{Functionality, Reliability, Usability, Maintainability, Portability}, Quality in Use {Effectiveness, Productivity, Safety, satisfaction }}
      6. Distinguish: computer system, mechanical part, Human process.
      7. Computer system: hardware, software, and data -- all with qualities.
      8. Stakeholder needs ->(definition)->Stakeholder requirements ->(Analysis)-> System Requirements.
      9. Many more details...


      1. Kannan Mohan & Balasubramaniam Ramesh
      2. Tracing variations in software families
      3. Commun ACM V50n12(Dec 2007)68-73
      5. Analysis & Design of system to help manage product lines for 2 companies.
      6. Do more than link requirements to designs .
      7. Figure 1. UML. Variable requirements link to variation points in designs. Variation points linked to variants, mechanisms, and justifications. Interactions + conflicts + dependencies + constraints...
      8. Provide integrated environment that can be used by whole organization: engineering, sales, marketing, etc.


      1. Janet E Burge & David C Brown
      2. Software Engineering Using RATionale
      3. Journal of Systems and Software V81n3(2008)pp 395-413
      5. Faster maintenance for nonexperts (only)
      6. Who were the subjects?
      7. What is cost of capturing the rationale?

      2008-06-06 Fri Jun 6 06:06 Four thousande plus items in Bibliography

      As I post my notes on my reading on software development I also place them in a searchable bibliography. This started 20 years ago. It now has 4521 items! You can search it by going to [ biba.php ] and inputting a word or phrase -- it will accept regular expressions as well. Or you can try [ lab.html ] for a slightly different search engine.

      The search generates a list of items showing the items unique tag and a set of keywords describing the content. The identifier is also a link that extracts the item. Every item is given a unique tag, key or identifier so you can easily link to it.

      At the end of the listing is a link to a search engine that gathers the texts and citations into a non-standard HTML bibliography on the topic.

      Please use these tools.

      2008-06-06 Fri Jun 6 06:06 Security and Requirements

      Two articles on security form IEEE Software Magazine. One on Java techniques and the other a literature survey of the methods.


      1. Charlie Lai
      2. Java Insecurity: Accounting for subtleties that can compromise code
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp13-19
      5. Example of sompromisable singleton pattern.


      1. Inger Anne Tondel & Martin Gilje Jaaten & Per Hakon Meland
      2. Security requirements for the rest of us: a Survey
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp20-27
      5. Table 1: SQUARE, Haley et al, Bostrom et al, CLASP, MICROSOFT, APvrille et al, Fernandez, van Wyk & McGraw, Peterson
      6. Tasks: definition, objectives, misuse/threats, assets, coding standards, categorize & Prioritze, Inspect & Validate, Process planning.

      More below.

      2008-06-05 Thu Jun 5 10:06 Security Requirements Engineering

      The following paper and article both describe processes for sorting out security requirements. Jeff Patton's article argues that explicit goals and metrics for them is helpful for selecting the correct features to implement next. The paper is much longer and more complex but worth study, if only to observe the subtle interplay between formal logic (proving that a system is secure) and informal arguments (challenging the assumptions that were made in the proof).


      1. Charles B Haley & Robert Laney & Jonathon Moffett & Bashar Nuseibeh
      2. Security Requirements engineering: A Framework for Representation and Analysis
      3. IEEE Trans Software Engineering V34n1(Jan/Feb 2008)pp133-153
      5. Describes a complex process and set of languages that work from security goals, to assets that are to be protected (compare [Stoneburner06] ), to requirements, thence to arguments for a particular system design satisfying the requirements, and so to the assumptions that can be rebutted, and the mitigation of the rebuttals and so forth.
      6. Security requirements are non-functional requirements and are closely related to the context of the machine being designed.
      7. Must expose assumptions about the machine and its context.
      8. Arguments that the system satisfies the requirements lead to lists of assumptions that can be challenged (WHY?) and rebutted.
      9. Rebuttals lead to mitigators that change the context.
      10. Hence an iterative process designing a more secure system.
      11. Uses Jackson Problem Frames ( [Jackson95c] [Jackson01] ), Toulmin type arguments, Propositional logic, and a causal logic based on
      12. Event 1 shall cause Event2.
      13. Outer_argument::jargon=Formal logic showing the design satisfies the requirement and exposing assumptions
      14. Inner_argument::jargon=Explores assumptions in terms of rebuttals and mitigators.
      15. Process involves engineers and stakeholders in intense and fruitful discussion.
      16. (dick)|-Compare the [Lakatos76] model of the mathematical process. Also methods used to achieve safety.


      1. Jeff Patton
      2. Ambiguous Business Value Harms Software Products
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp50-51
      5. IRACIS::acronym="Increase Revenue, Avoid Costs, Improve Service", [GaneSarson77].
      6. Brainstorm->cards; cluster; Vote on priority (ceiling(|clusters|/3) votes per person), metrics, Poster

      2008-06-04 Wed Jun 4 20:06 Teams and Technology

      What technology should a distributed team use when developing software? What new technologies can we use in our systems?


      1. Dominick M Thomas & Robert P Bostrom & Marianne Gouge
      2. Making Knowledge Work in Virtual Teams
      3. Commun ACM V50n11(Nov 2007)pp85-90
      5. ICT::="Information and Communication Technologies".
      6. More than 20 different ICTs.
      7. It is not enough to make technology available.
      8. Problems: team volatility, time pressue, interoperability all lead to work stopages and managerial intervention.
      9. All teams used audio confeences, EMail, and the phone.
      10. >70% used: Fax, project management, calendar, IDEs,many-to-many chat, versioning, instant 1-1 messaging,...
      11. Intervention:=(opportunity | problem) triggers leader actions and changes; aim for higher participation and capacity, leading to project outcomes.
      12. May have to shut down an ineffective technology as well as promote a better one.
      13. Triggers: outside the team, inadequate tools, breakdown of trust and relationships, interference in group work, member knowledge.
      14. Interference:turnover, cultural difference, physical distance, time zones


      1. Jeff Brown & Bill Shipman & Ron Vetter
      2. SMS: The Short Messaging Service
      3. IEEE Computer Magazine V40n12(Dec 2007)pp106-110
      5. SMS::protocol="Short Message Service", not just for teenagers, also connects to the web and EMail.


      1. Karen Heyman
      2. A new virtual private network for today's mobile world
      3. IEEE Computer Magazine V40n12(Dec 2007)pp17-19

      2008-06-03 Tue Jun 3 19:06 Having a Fit

      Luckily I'm not having a fit about the local IRS office not letting us get in line for a sailing permit, or about my anti-virus software grabbing 90% of the bandwidth to download a complete new executable on Tuesdays and Thursdays.... But a proposes way of documenting requirements in an executable form -- a test expressed as a scenario with tabular steps.


      1. Robert C Martin & Grigori Melnick
      2. Tests and requirements, requirements and tests: a Mobius Strip
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp54-59
      5. FIT::tool= See http://fit.c2.com , Framework for Integrated Testing [ samples/methods.html#Fit ]


      1. Rick Mugridge
      2. Managing Agile project requirements with storytest-driven development
      3. IEEE Software Magazine V25n1(Jan/Feb 2008)pp68-75
      5. FitLibrary::= See http://sourceforge.net/projects/fitlibrary/.
      6. FitNesse::= See http://www.fitness.org/.
      7. Also see [ samples/methods.html#Fit ] [MartinMelnick08]

      2008-06-03 Tue Jun 3 10:06 Out Source and Open Source

      Four items in this batch. First a report of changes in outsourcing, then two books and a paper on F/OSS (Free/Open Souce Software. We have a text book on the technology and system, a political economists view of why open source has been successful, and a report of open source being used to teach software evolution/maintenance.


      1. Neal Leavitt
      2. The Changing World of Outsourcing
      3. IEEE Computer Magazine V40n12(Dec 2007)pp13-16
      5. Consolidation. More countries. Smaller tasks/projects/companies. More complex systems. Not just the cost!


      1. Fadi P Deek & James A M McHugh
      2. Open source: technology and policy
      3. Cambridge UP NY NY 2008 ISBN 0-521-88L03-X
      4. =TEXT Open source


      1. Steven Weber
      2. The success of open source
      3. Harvard University Press Cambridge MA ISBN 0674018583 CR 0611-1091
      5. (dick)|-Excellent survey by an outsider of the open source phenomenon.
      6. (dick)|-Last chapter has too much social science jargon.
      7. (dick)|-Only spotted one error: confused JavaScript with Java.
      8. (dick)|-Some small omissions: in the 60's software was bundled with the hardware & user groups shared their developed software, KDE may be a pun on Sun's CDE, Wikipedia, ...


      1. Maksym Petrenko & Denys Poshyvanyk & Vaclav Rajlich & Joseph Buchta
      2. Teaching Software Evolution in Open Source
      3. IEEE Computer Magazine V40n11(Nov 2007)pp25-31
      5. SC::="Software Change".
      6. Software_Change_Process::= Initiation; locate_concept; analyse_impact; (testing & (prefactoring; actualization; change_propagation; postfactoring)); new_baseline.
      7. CVS -- change version system for source code control and to provide data for grading. Note: difficult to set up. Students must get special training and practicebefore being let loose on the real code.
      8. Students work on realistically sized code and make realistic changes.
      9. Graduate students act as managers -- either for one team or all teams.
      10. Grades based on CVS records and interviews.
      11. Student opinions collected.

      2008-06-02 Mon Jun 2 19:06 Fear and Loathing of Complexity

      The following reflects my own beliefs:


      1. Simone Santini
      2. Making computers do more with Less
      3. IEEE Computer Magazine V40n12(Dec 2007)pp124+122-123
      5. Argues that invisible downloads into a personal machine is a kind of trepass.
      6. Argues for using the simplest non-invasive technology for software and web pages.

      2008-05-30 Fri May 30 10:05 Fear and Loathing of Upgrades Part 2

      Below I described how well the Palm Tungsten Software upgraded from an E to an E2. But when I updated the Palm Desktop on my office laptop ( Part2 ) things were not as good. (1) The desktop crasshes if you are viewing a daily calendar and try to look at your to-dos at the same time. (2) most of my categories in the calendar have gone.... Events at work looked like they were for my wife. Not good.... spending time putting the categories back. (3) The Media application (Photos and videos) decided that it should send all its photos to the hand-held, even if they were duplicates. Spent time removing them.

      And my own personal cradle -- a rather nice Chinese Panda [ palmpanda1.jpg ] -- no longer fits the new handheld+cable:-(

      Well I wonder what will happen next.

    6. 16:05 Ugly First the story so far: Installing the upgraded Palm desktop software lead to the Palm E2 losing all the categories. Going back to the back machine deleted them from that back up system.

      Oddly each application on the palm behaves differently when you recreate deleted categories. The "Tasks" application accepts them and places the records back in the right (old) categories. The "Calendar" accepts them and assigns the event to categories so that most are right, but some are wrong. The "Memo" and "Contacts" application on the desktop refiles items in deleted categories as "Unfiled" so that you have to go thru it and file them correctly their -- even tho' the handheld has the categories OK!

      The cost: 2..3 hours of refiling on the laptop. Then I discovered that if you force the HotSynch to update the desktop from the palm top, AND if they have the same categories listed then the Memos and Contacts get filed in the category. To be precise, this is how I read the warning message that "File Categories" are not updated when the handheld over-rides the desk-top.

      Note that the data has not been normalized. These are all the kind of anomalies found in a less than third normal form data base.

      Notice that there is clearly no reuse of code or designs between these different parts of the Palm software.

      2008-05-29 Thu May 29 20:05 Economic ideas

      I agree with the first idea below: figure the value at risk of data as well the total cost of ownership. I'm not so sure about Michael Wing's code-centric view of software.


      1. Paul P Tallon & Richard Scannell
      2. Information Life Cycle Management
      3. Commun ACM V50n11(Nov 2007)pp65-69
      5. Can't mitigate all risk without high cost. Low costs can mean unacceptable risks.
      6. Keep the total cost of ownership of data ballanced with the value at risk -- cost of losing the data.
      7. information_life_cycle::= capture application decline. Value highest in the application phase.
      8. value at risk: graph frequency vs busines consequence of various events.


      1. Michael Wing
      2. On the Economics of Software
      3. ACM SIGSOFT Software Engineering Notes V32n6(Nov 2007)pp8-9
      5. Code is one of the most valuable artifacts -- even if it is of bad quality. The value comes from it being used.
      6. The cost of code has a complex relation to its quantity.
      7. Each relase costs twice as much.

      2008-05-28 Wed May 28 18:05 Components and Reuse

      Here are an article and a paper on components in engineering. The first is about how a technical solution to a problem leads to new problems. The second is a comparison of different component frameworks:


      1. Han Oshri & Sue Newell & Shan L Pan
      2. Implementing Component Reuse Strategy in complex environments
      3. Commun ACM V50n12(Dec 2007)pp63-67
      5. Engineers unhappy with reuse: exploration became exploitation + too many meetings.
      6. The design of a component does not record its rationale.
      7. Proposes that meetings to present new components should be held in laboratory with technical tools to demo ideas.
      8. Problems with redesign feedback loops and time needed to reuse previous work.
      9. (dick)|-management confused research with development.


      1. Kung-Kiu Lau & Zheng Wang
      2. Software Component Models
      3. IEEE Trans Software Engineering V33n10(Oct 2007)pp709-724

      2008-05-27 Tue May 27 20:05 Fear and Loathing of Upgrades

      We spent Memorial Weekend looking for a place to retire: cooler than San Bernardino, near libraries, entertainment, and affordable on pensions. One realtor talked about how he wouldn't be tackling any searches of the Multiple Listing Service until the system was upgraded. I always loathed the effort involved in upgrades -- inserting endless CDs (UNIXen) or a long World Wide Wait for downloads (or both)... and the occasional MS windows freeze when the MS upgrade collides with the touch pad driver on one laptop....

      I Stan Kelly Bootle's dictionaries there used to be a "Riddle Song" with the line:

    7. I promised my love an upgrade without any crying.

      Plus the punch line

    8. I was lying.

      I particularly fear new software because I am blessed with the ability to discover bugs. It happens without thought. As the old saying had it "Nothing is fool proof -- fools are too ingenious".

      So I was not looking forward to upgrading my Palm Tungsten E to an E2. It was forced: the battery charger for the old E was held together with toothpick splints, the glue on the keyboard had broken, the digitizer was consistently about 1/8 inch low on the bottom left of the screen and horrifically slow on the middle left of the screen, and the on-off button had arthritis. A system has to be this bad to force me to upgrade.

      So I ordered a replacement from Palm. And expected it to arrive on next Thursday. And tried to not worry about it. Would the 17Mb of data move to the new machine? How do I move the encryption software to the new machine? Would the digitizer have similar fault? What new bugs would I have to work around.

      The E2 arrived today at about noon. All undamaged... and it took 3 hours to charge the battery. The CD updated the Software on the Back up lap top -- and installed all the data and the old applications with the first hot-synch! Pretty good going. A slight glitch when I didn't set the date and found I had no todos or scheduled events -- the E2 was set to 2005 -- which crashed the OS:-( Another small crash in the notepad when testing the digitizer:-( My grafiti shorthand has gone and needed reprogramming. And I've gained some categories that I don't want -- and since I can only have 15 all my Vendor contacts moved into unfiled:-(

      In summary -- much better than I feared. We will see what happens next. See Part2.

      2008-05-23 Fri May 23 06:05 Workflow determines a helpful interface

      This paper reports an experiment that shows that helpful user interfaces can be automatically constructed from a model of the what the user has to do. The result provides the context for the work which helps non-experts to do the work.


      1. Ying Zou & Qi Zhang & Xulin Zhao
      2. Improving the usability of e-Commerce Applications Using Business Processes
      3. IEEE Trans Software Engineering V33n12(Dec 2007)pp837-855
      5. Tools derive user interface directly from an encoded model of the workflow and the needed data, forms, and functions.
      6. Result improves usability for non-expert users.
      7. Screens show Navigation + Processes + Tasks + Workspace panes/frames.
      8. The workspace shows only the relevant screens for current Tasks.

      2008-05-22 Thu May 22 12:05 Evidence for an old fashioned step being useful

      My campus [ http://www.csusb.edu/ ] has a long history of fairly painless changes in Information Technology(IT). This includes the recent implementation of a system wide ERP. Last year the faculty started to use the new CMS system for handling rosters, adds, drops, and grades. The reading below states that on two other campuses, even though faculty were involved in developing new IT, they did not like the resulting system -- in one case it has dubbed a failure and completely redeveloped. Here is the citation:


      1. Erica L Wagner & Gabriele Piccoli
      2. Moving beyond participation to achieve successful IS design
      3. Commun ACM V50n12(Dec 2007)pp51-55
      5. Users were really involved with current system not the new one until the project was went live.
      6. Start by focusing on what users are doing in current system.
      7. Get user stories of current challenges and successes.
      8. Analysts must learn to translate user expertise into designs that fit.
      9. Change SDLC to include iterations after it goes live.
      10. (dick)|-3 known techniques confirmed.
      11. (dick)|-presumes "Big Design Up Front", A more incremental approach gets users involved within their current work process.

      Now, here is story that explains why CSUSB has not had failures like this. When I arrived, in 1982, the registration process was based on a main frame computer and punched cards. Each department had a faculty representative sitting in the gym handing out cards to students. These card represented seats and acted as tickets. A classic "visual record" system. But I knew that this was about to change -- I had made sure to court my colleagues in the "Computer Center". Experience with software development lead me to worry about the change. To be honest I worry about all upgrades -- I'll write something on "Fear and Loathing in Upgrades" real soon now.

      In this case, the system being changed was central to the enterprise and it would be a large change. So I was worried. Then I saw, across the gym, the systems analyst in charge of the project. He was observing what was going on. He checked on each of the departmental "booths". He was also frowning. When he came by, I asked him what he felt. He said there was a lot going on that nobody had mentioned in meetings.

      It was at that moment I knew that the new system would be an improvement of the old one.

      So, in 1982 computer professional knew something that some current computer professionals have forgotten -- the importance of studying the current system. In the 1970's the first step is to analyze the current system -- know what people do, know what is good about it, know what is bad, know what is supposed to done vs what actually happens. Perhaps, the movement that proposed skipping this step and focusing on the "Essential System" may have encouraged many places to abandon a useful practice.

      The other suggestion of expecting changes to be made after the project goes live has also been a part of software development for decades -- plan to throw one away, you will anyway.

      2008-05-21 Wed May 21 19:05 Unsafe software

      Here are a couple of articles on attempts to establish procedures for assuring the safety or at list trustworthiness of software. Both articles take a pessimistic view of government procedures and standards.


      1. Matt Bishop & David Wagner
      2. Risks of E-Voting
      3. Commun ACM V50n11(Nov 2007)p120
      5. The authors found buffer overruns, hard-coded encryption keys, dumb pseudo-encryption, dumb passwords etc. in all voting systems.
      6. Federal tests did not disclose the flaws. Code review did.
      7. Voting systems must be transparent.
      8. Need for audits.


      1. Martyn Thomas
      2. Unsafe Standards
      3. IEEE Computer Magazine V40n11(Nov 2007)pp109-111
      5. Based on a recent NRC Report.
      6. Safety is a systems property not just a software one.
      7. Three_Es::= Explicit safety claims + Evidence + Expertise.
      8. We don't have the evidence to substantiate the claims specified in the current standards.

      2008-05-20 Tue May 20 19:05 Ruby on Rails

      Here is a short introduction to a very popular way to rapidly develop a web-based application


      1. Michael Bachle & Pauk Kirchberg
      2. Ruby on Rails
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp105-108
      5. Also compares with Apache Struts, Tapestry, Cocoon, and ASP.NET

      2008-05-19 Mon May 19 14:05 Practical research and standards

      Robert Glass is something of a gadfly but sometimes he reports something that is novel, reliable, and has practical implications... in this case about a well known standard having problems. I've matched it to a report on how standard software imporvement process had to be tuned to their environment. I've added a report that confirms one of the blessed Glass's claims: software projects do not fail as often as some have reported: a 60% success rate is common.


      1. Robert L Glass
      2. A Research project with important practitioner-oriented findings
      3. Commun ACM V50n11(Nov 2007)pp15-16
      5. H Al-Kilidar & K Cox & B Kitchenham, The use and usefulness of the ISO/IEC 9126 standard, Proc ISESE 2005 conference.
      6. The standard was ambiguous and not easy to use (by student teams).


      1. Hanna Oktaba & Felix Garcia & Mario Piattini & Francisco Ruiz & Francisco J Pino & Claudia Alquicira
      2. Software Process Improvement: the Competisoft Project
      3. IEEE Computer Magazine V40n10(Oct 2007)pp21-28
      5. One size does not fit all: small enterprises need special software improvement methods.


      1. Chris Sauer & Andrew Gemino & Blaize Horner Reich
      2. The impact of size and volatility on IT project performance
      3. Commun ACM V50n11(Nov 2007)pp79-84
      5. 2/3 projects succeed (according to their managers).
      6. CF [Glass05]
      7. More effort (person*months) increases risk of failure.
      8. Changing team increases risk of failure.
      9. Moving targets increases risk of failure.

      2008-05-16 Fri May 16 06:05 Incubating Projects

      In the traditional systems life cycle a critical first stage is deciding what projects to tackle, gathering information that is needed to develop the software, organizing a team, etc.

      It appears the Free/Open Source communities have spontaneously developed well defined procedures which can turn a single person's vision in to a project that the community is committed to. Here is a comparison of the Apache and the Eclipse processes for incubating projects.


      1. Juan C Duenas & Hugo A Prada G & Felix Cuado & Manuel Santillan & Jose L Ruiz
      2. Apache and Eclipse: Comparing open source project incubators
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp90-98
      5. Incubation is the process of developing and defining new project/subprojects to be further developed and integrated into a the current (evolving) system.
      6. Apache and Eclipse have well defined processes and share many features (Table 1 page 97)

      2008-05-15 Thu May 15 17:05 Started Organizing MATHS Project

      I've decided to treat my sabbatical project as a sample project: [ samples/maths.html ] so that it will use MATHS (the notations and tools) to develop MATHS (the tools and notations). I've copied some of the items below into a new blog.

      You can always findout what is going on -- spread over several blogs by visitting my home/index page [ index.html ] , by the way.

      2008-05-14 Wed May 14 18:05 The Choice Uncertainty Principle

      Lot of exercise today: walkinging and weights first thing, then getting leaves out of the pool, then walking accross the parking lot carrying this old Dell for its monthly dose of updates,... But a pleasant morning in the library checking out Jerry Weinberg's Introduction to General Systems Thinking and Principia Mathematica chapter *93. Brought home a book of F P Ramsey's papers on logic and philosophy.

      Now here is an interesting new working rule from Peter Denning


      1. Peter J Denning
      2. The Choice Uncertainty Principle
      3. Commun ACM V50n11(Nov 2007)pp9-14
      5. CUP::= "No choice between near-simultaneous events can be made unambiguously within a preset deadline".
      6. 9 refs. Many examples: hardware, software, and mundane.

      2008-05-13 Tue May 13 14:05 What people think about software development projects

      Here are a couple of papers that are based on "Surveys of the literature".


      1. Erran Carmel & Pamela Abbot
      2. Why 'nearshore' means that distance matters
      3. Commun ACM V50n10(Oct 2007)pp40-46
      5. nearshore::= low geographical temporal cultural linguistic political economic historical distance to lower wage software development.
      6. Some places are both exporters and importers of software work.


      1. U N Umesh & Len Jessup & Minh Q Huynh
      2. Current issues faced by technology entrepreneurs
      3. Commun ACM V50n10(Oct 2007)pp60-66
      5. Market dominance depends on overcoming hurdles rather than the quality of the idea.
      6. Outsourcing can be both a resource and a challenge.
      7. hurdles: finance, skill, fit customers, fitting existing products, ease of use, security, useful.
      8. TAMSM::="Technology Acceptance and Market Success Model". Based on TAM 1989.

      Meanwhile -- working on requirements and the available technologies for my sabbatical project, and sorting out leaks in (1) my accounting and (2) a bath room tap. Also reviewing the syntax and semantics of documentation in my MATHS language -- [ maths/notn_13_Docn_Syntax.html ] [ maths/notn_14_Docn_Semantics.html ] [ maths/notn_15_Naming_Documentn.html ] etc. .

      2008-05-12 Mon May 12 14:05 YAML -- XML considered harmful

      My favorite blog just sent me an excellent article [ 001114.html ] which says something that I have been thinking ever since XML was invented -- that it may not be the best solution for all your data encoding needs. As evidence the author gives is using YAML which is both easier to read and still 99% unambiguous.

      Like my own MATHS language it use white space to indicate structure. But it goes further by having no open+close bracketing syntax. It is all done by indentation. Much the same way CODIL did (does?). More in [ samples/languages.html#YAML ]

      I'm tempted to formalize YAML into my MATHS language as a long format for complex objects:

    9. CIRCLE( center=> POINT( x=>1, y=>2 ), radius => 10 )
              x : 1
              y : 2
           radius : 10

      But this will need some thought about current features of MATHS and how simple implementation might be. Can it be done with the UNIX standard tool kit -- sed/auk/...?

      By the way I've added some links to Polya's book "How to Solve It" below.

      2008-05-09 Fri May 9 17:05 Sabbatical Project -- MATHS

      My sabbatical project is not making much progress. The next post is typical of the reading that I have been doing that indicates that there may not be a market for a simple, formal notation for mathematics -- even if designed to have a lot in common with programming languages. The language exists [ maths ] and has stabilized over several years personal use. My project is to add a new feature heading in the direction of a wiki.

      In the project I was hoping to move in the direction of a wiki-style site that used the language with a lot of people contributing information, notes, samples, and so on. Yesterday I looked into a "PHP Phrasebook". It is full of warnings about the bad things can do if they supply data and some of the things you can do to avoid them. I knew about the risk of passing HTML code with "<script>" tags and have (for years) translated HTML-special symbols in MATHS into entities on HTML pages.

      What I had not thought about is that URLs can not be trusted. I'm quite paranoid about clicking on links and attachments for example in EMail. But I'm starting to wonder if I can trust links in the WikiWikiWeb and the Wikipedia any more.

      This is fairly typical of requirements... a desirable feature comes with a poison pill. It is also typical that you discover the poison pill after the project is well under way. It is also an example of a negative requirement -- something that must not be possible.

      MATHS Project Features

      1. (REQ1): Users should be able to edit MATHS web pages.
      2. (REQ2): Users must not be able to include links to illegal and/or malicious URLs.
      3. (NAT1): Some people attempt to include illegal and malicous links in my pages.
      4. (above)|-Anonymous users may need to have their changes vetted before inserting.
      5. (above)|-Untrusted users may be limited to local links.
      6. (above)|-There may be away to join a group of trusted users who will get full access to the system
      Note: In the above I distinguish requirements (labeled REQn) from known facts (NATn). This comes from the SCR project and Michael A Jacksons recent publications.

      Contact me if you have an thoughts.

      2008-05-08 Thu May 8 16:05 Mathematics Made Boring

      Here is a powerfully expressed argument that mathematics is taught the wrong way:
    10. LockhartsLament::= See http://mail.geneseo.edu/pipermail/math-thinking-l/attachments/20080507/b091d446/LockhartsLamentArticle.pdf

      To quote from the end of the article

    11. "SIMPLICIO: Alright, I'm thoroughly depressed. What now?"

      (Polya): one antidote for the above Lament is Polya's method of teaching and doing mathematics [Polya88] ("How to solve it"). Also see some notes [ samples/polya.html ] and [ maths/logic_20_Proofs100.html#polya ] on Polya's "New Heuristic".

      2008-05-08 Thu May 8 14:05 Alloy and JacksonD06a

      I've just updated my previously unannounced bibliographic item for Daniel Jackson' 2006 text book. Previously it was tagged "=UNREAD" in my bibliography and didn't have much details. I've now spent a week studying it and have posted this:


      1. Daniel Jackson
      2. Software Abstractions: Logic, Language, and Analysis
      3. The MIT Press Cambridge MA 2006 ISBN 0262101149 CR 0802-0116
      5. A neat way of finding bugs in specifications and requirements.
      6. Small_scope_hypothesis::=Most bugs have small counterexamples.
      7. Notes the difficulty of creating consistent formal models that have the desired properties.
      8. Alloy::language=a formal first order relational logic expressed in ASCII with tools in Java.
      9. Alloy_examples::= See http://softwareabstractions.org.
      10. Alloy_analyzer::= See http://alloy.mit.edu.
      I like the quirky examples: how can I be my own grandfather? How do hotel key-cards work and what bugs do the have? ...

      Alloy is something of a rival to my own MATHS language. It is a cleverly chosen subset of first order logic that can be analyzed by a Java program -- you can check for consistency and also check to see is properties must be true. It relies on finding counter-examples to assertions in a small universe. The general problem is clearly intractable. Hence the limit on the help that can be provided by tools using my own MATHS language -- which is more general.

      2008-05-07 Wed May 7 18:05 Tools for teams

      I've just improved my very sketchy notes on probability theory [ maths/math_81_Probabillity.html ] to the point of sketching definitions of expectation, entropy, mean, moments, etc.

      Meanwhile here are three articles/papers on tools that teams can use:


      1. Randall Frost
      2. Jazz and the Eclipse Way of Collaboration
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp114-117
      5. Jazz extends on Eclipse to coordinate many programmers.


      1. Jorg Rech & Christian Bogner & Volker Haas
      2. Using Wikis to Tackle Reuse in Software Projects
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp99-104
      5. Wiki made it easier to save and share documents etc.


      1. Beat Fluri & Michael Wursch & Martin Pinzger & Harald C Gall
      2. Change Distilling: Tree Differencing for Fine-Grained Source Code Change Extraction
      3. IEEE Trans Software Engineering V33n11(Nov 2007)pp725-743

      2008-05-06 Tue May 6 18:05 Experimental prototypes and pair programming

      Here are two articles that are worth reading. The first presents the case for experimental protoypes and describes the risks. A pretty good summary of experience. The second reports on the research that' has been done on pair programming where two people work on an artifact at once. One has the keyboard and the other makes comments. Here the value comes from experiments done with the technique.


      1. J B Rainsberger
      2. Just Try It
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp16-17
      5. Sometimes it is better to try at an idea than spend time debating it -- running an experimental prototype.
      6. Risks of dominant programmers.
      7. Risks of keeping experimental code.
      8. Need for a clear question and time limit for experiments.


      1. Tore Dyba & Erik Arishlm & Dag I K Sjoberg & Jo E Hannay & Forrest Shull
      2. Are two heads better than one? On the effectiveness of pair programming
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp12-15
      5. Quality tends to be a little better and the time to complete the project is better. The effort (people * time) is slightly worse.

      2008-05-05 Mon May 5 13:05 Software Reliabillity Probabillity etc

      I've made some small improvements to some pages introducing my MATHS language: [ maths/intro_records.html ] showing how to describe structures with optional and multiple parts. For example to state that a cat has 4 legs...
    12. CAT::=Net{ cat: $ LEG ^ 4 ,...}.

      I've gathered an article and a paper on the use of probabillity theory and statistics to predict the reliability of software.


      1. Vincent Almering & Michiel van Genuchten & Ger Cloudt & Peter J M Sonnemans
      2. Using Software Reliability Growth Models in Practice
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp82-88
      5. The models got better as more data was fitted.
      6. λ(t) :=failure intensity function.
      7. (GO): λ(t) =a*b*exp(-b*t).
      8. (delayed S): λ(t) =a*b^2*t*exp(-b*t).
      9. (log power): λ(t) = α*β*ln^(b-1)(1+t)/(1+t).
      10. (log Poisson): λ(t) = λ[0] / (λ[0] * θ * t + 1).


      1. Yuan-Shun Dai & Min Xie & Quan Long & Szu-Hui Ng
      2. Uncertainty Analysis in Software Reliability modelling by Bayesian Approach with Maximum-Entropy Principle
      3. IEEE Trans Software Engineering V33n11(Nov 2007)pp781-795
      5. Problems: few tests fail, incorporating prior information, uncertainty in models reduces reliability.
      6. MEP::= "Maximum-Entropy Principle", choose an a prior distribution to maximize the entropy given the known data.
      7. For distribution p, entropy(p):= Expected_value(-ln(p(_))).
      8. Use Bayesian a postiori formula to encorporate data from tests.
      9. Use simulation and analysis to predict relibilities of whole system.
      10. Gives examples.
      11. Refers to texts for calculations of MEP.

      2008-05-02 Fri May 2 10:05 An Example of Bad Requirements Analysis

      To some extent I'm writing this entry now to keep our home phone line busy to shut up the repeated calls by the local school district substitute system also known as SmartSearch. If you answert the phone by saying something then the nice voice identifies itself and invites you to either input the substitutes ID number folowed by the star key, or by star key to wait for the substitute to come to the phone. There don't seem to be any other scenarios.

      So if the substitute is out of the house there is no real response you can make. So cover the phone and wait for the system to go away. It phones back a few minutes later.

      The old system had included the assumption that the substitute could not come to phone -- you dialed "**3" and it went away for several hours. The new system does not.

      Of course the substitute can program the system to not call -- but this process takes about 15 minutes and is error prone...

      So how do you spot holes in your understanding of the world in which your software is going to operate?

      It is a common problem. And the best solution I've seen is to construct a model that expresses the structure and logic of the real world outside the computer. I've spent years looking at ways to do this. One technique might be called literate analysis and uses a mixture of natural language, mathematics, logic, and diagrams. I have an old example [ papers/rjb0xa.lift.html ] of a model of the famous lift problem. I plan to revise it sometime real soon now and include manual UML diagrams.

      Another approach is to have a set of patterns or an ontology for requirements. I've just read about two books on this topic, which I hope to read in detail one day: [Hruby06] and


      1. Michael Roemann & Peter Green (Eds)
      2. Business systems analysis with ontologies
      3. Idea Group Pub Hershey PA 2005 ISBN 0804-0350 CR 0804-0353
      5. BWW::="Bunge-Wand-Weber".
      6. Notes [click here [socket symbol] if you can fill this hole]
      (The "plug hole" above invites you supply your thoughts on the items... I will review, edit and post...).

      2008-05-01 Thu May 1 11:05 Users and Human Computer Interfaces

      I was very interested in what we used to call user friendly computing in the 1980's. It was very much a matter of creative design in those days. Also a battle with inadequate hardware interfaces: no mice or other pointing devices. But I was able to create "FRED, the FRiendly EDitor" for beginning Computer Science students.

      Since then we have seen the emergence of a dominant WIMP model. The MIT press have recently published a couple of books challenging it. I've just found them in CSUSB library new books.


      1. Thomas Erickson & David W McDonald (Eds)
      2. HCI Remixed -- Essays on Works that have influenced the HCI Community
      3. The MIT Press Caambridge MA 2008 QA76.9.H85H4125 ISBN 978-0-262-05088-3
      4. =HISTORY =ESSAYS USERS Human Computer Interfaces HCI
      5. Any book with an essay on Ted Nelson's Computer Lib/Dream Machines must be good!


      1. Victor Kaptelin & Mary Czerwinski (Eds)
      2. Beyond the Desktop Metaphor -- Designing Integrated Digital Work Environments
      3. The MIT Press Caambridge MA 2007 QA76.9.H85B539 ISBN 978-0-262-11304-5
      4. =PAPERS USER HCI METAPHOR Lifestreams Haystack Task Gallery GroupBar Scalable Fabric Soylent

      (And in the middle of writing the above entries seated in the CSUSB library the WiFi network went down and so I had lunch... Now back in my office... and much quieter than the library, sadly)

      2008-04-30 Wed Apr 30 18:04 Requirements worst practices

      Neil Maiden claims to interviewed a leading expert in the field of requirements ... but his advice seems to be the reverse of the best practices. For example: use fuzzy natural language and weasel words to avoid committing the developers to anything. I also like the advice to be very rigorous with the process...


      1. Colin Codephirst (alias) & Nail Maiden (ed)
      2. From the horses mouth
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp21-23

      2008-04-29 Tue Apr 29 19:04 Social Processes of Mathematics

      I've recently read something a little outside the main thrust of this blog. Be warned this entry is not, at first, linked through to software development. I, by accident read a layperson's introduction into a esoteric bit of pure mathematics: the Poincare Conjecture. See [ OShea07 ] below for the citation. The description of the publication of the proof of the conjecture, and then it's public presentation -- a walkthrough that took several days -- and exposed a few small errors is an example of a social process that iterates towards the truth.

      One of the mistakes in early "formal" methods was in glossing over this part of mathematical work. We stressed the formal correctness of results rather than the need for people to review the proofs to correct them.

      One of the things I want to do is to develop a more open system that allows mathematical ( and logical ) work to be published and then worked on by many people. I envision the creation of documents ( requirments, designs, code, tests) that can be shared and edited -- and that include a rich hypertext structure -- definitions linked to usage of terms -- and mathematical notation for convenience.

      2008-04-28 Mon Apr 28 18:04 Charrettes in Software Development

      First an apology -- the coughs and sneezes and fevers knocked me out for another week or so. April is something of a write-off.

      In the latest weekend edition of the Los Angeles Times I met a word that I not seen before: charrette and had to search through three dictionaries to get a definition. A charrette is an intensive group or individual period of architectural design. It comes from the French for tumbril -- a cart used to take people to the guillotine for execution. I found a very good description and history of the term on the Wikipedia:

    13. charrette::= See http://en.wikipedia.org/wiki/Charrette

      The above description reminds me alot of the intensive all night work that is done in developing software in some organizations. However I can only trace one example of the word charrette being used as part of a software process. And here [ Mindjet-Labs-Charrettes.aspx ] a software developer is using his education as an architect to create a design/requirements workshop.

      Perhaps we should seek to apply charrette to eliciting requirements and blitzing a design.

      I would like to see any evidence for the value of this technique in eliciting requirements and designing interactions.

      However if the whole development provcess degenerates in a ride to the scaffold <audio source=Berlioz\> then we are almost certainly in a death march project [ bib.php?search=death.*march&from=blog ] and definitely breaking the XP practice of a 40-hour week. I thinki we should deprecate this kind of charrette.

      2008-04-11 Fri Apr 11 14:04 Assertions annotating source code

      In the previous entry I developed the idea that good code may need extra comments in it that explain what it is doing and how it is supposed to do it. See [ beautiful code ] below.

      I finished with the promise of an example. It took me a chunk of last night. I'll be using a code fragment in a language like C/C++/Java/etc/. This is based on code I learned from a colleague 30 years ago... but with a twist.

      Here it is without comments

       		while ( low < high - 1)
       			middle = (low + high) / 2;
       			if( array[middle] < target )
       				high = middle;
       			else if( array[middle] > target )
       				low = middle;
       			else low = high = middle;
      You probably recognize it. But do you really know what the variables are doing? What properties they must have? The odds are you'll be wrong.

      (Yes, a few test cases would help -- examples always help ).

      Now here is the same code with added invariant assertions

       	// array and target are constant
       	// if i < j then array[i] > array[j]
       	// low=-1 and high = sizeof(a)/sizeof(a[0])
       		while ( low < high - 1)
        	  // array[low] > target and array[high] < target
       			middle = (low + high) / 2;
       			if( array[middle] < target )
       				high = middle;
       			else if( array[middle] > target )
       				low = middle;
       			else low = high = middle;
      Now I haven't proved the above fragment -- proving is an expensive task reserved for highly reusable algorithms and life-critical software in my current play-book.

      But you have been warned that this binary search is a reversed version that requires the array to be in decreasing order. You can also see that the low and high variables are always just outside the range of elements that might contain the target

      Also notice that

       	// if i < j then array[i] > array[j]
      can not be written as a C/C++/Java/etc. Boolean expression. First of all it has "if_then". Now you can simulate this quite elegantly by using "<", but you can not handle the implicit quantifiers. The formula must be true for all valid i and j. In fact, if N is the number of elements then in MATHS you would write:
    14. for all i:0..N, j:0..N, i<j ( array[i] > array[j] ).

      This ( and the first comment) makes my partly backed idea below less than half-baked. Back to the oven.

      2008-04-10 Thu Apr 10 19:04 Beautiful Code

      I've seen several discussions of beautiful code in recent blogs and articles. Here is one that casts doubt on the whole idea of a piece of code being beautiful:


      1. Rebecca J Wirfs-Brock
      2. Does Beautiful code imply Beautiful design?
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp18-20
      5. Can one determine the beauty of a piece of code without knowing it's context?
      6. Shouldn't identifiers have meaningful names?
      7. Shouldn't there be some comments giving a clue as to purpose and design of the code?

      This article mentions the need for meaningful identifiers. And I was reminded of the reaction of a business student doing a first C++ class last quarter. In my code I tend to use i, j, k in for loops as subscripts. And x and y for real numbers... The student thought it too much like algebra. Which was precisely the comment made 30 years ago by a colleague who used US (Universal Subscript) where I used i. And then that lead me to think about a research student sitting in the same office as I did who used ZIET in his code... but he was German. So I wonder if you can actually chose good names without knowing the background of your reader!

      Worse you can lie when you choose names.

      I've seen a very cogent article [Zokaites02] that argued that one wants code to be self-explanatory -- if a comment is needed then the code needs to be refactored: better variable names, better method/function names, ... Mainly because comments can not be checked. This does discuss the possible use of a formal language for comments (for example Ada had the Anna language) and tools for model checking.

      It is also ignores the problem of expressing purpose: what is this code trying to do. One modern way to to document the purpose of code is to document the tests that is must pass -- ideally in a form that enables the tsting. And indeed this is one of the benefits of Test Driven Development claimed in [Beck01] however tests can only indicate the generl rules governing the purpose and design of code.

      The traditional solution [Floyd67a] [Botting75] has been to include Invariant Assertions in the code. The Wikipedia has a short and pretty accurate introduction [ Assertion (computing) ] to the topic. And that lead me to an amazing survey of the past and present of the use of assertions to make code better:


      1. C A R Hoare
      2. Assertions: a personal perspective (Draft)
      3. Microsoft Research Ltd., Cambridge, England (6 Jun 2001) .See http://research.microsoft.com/~thoare/6Jun_assertions_personal_perspective.htm
      5. Assertions as annotating designs.
      6. Assertions and axioms defining semantics.
      7. Assertions as an executable part of code.

      A Partly Baked Idea -- Assertions in C++ and C

      Perhaps we could use the 'assert' function inside a comment to record formal assertions:
      1. Invariants
         	//inv assert(....);
      2. Pre and post conditions/contracts [Meyer00]
         	//pre assert(....);
         	//post assert(....);
      3. Specification and safety conditions [Maddux96]
         	//safe assert(....);
         	//spec assert(....);

      We could easily make this executable to check our reasoning. but our real purpose is explain the code. I'll see if I can construct an example, and an explanation of why the 'assert' still doesn't provide a powerful enough language for assertions.

      2008-04-09 Wed Apr 9 20:04 Good intentions and Proofs in Practice

      I had intended to make an entry on this blog every week day during my sabbatical. But yesterday night the coughs came back and I spent the morning trying to sleep.

      But I did make a small change in the previous post in the proof of the lemma.

      Now this is quite typical -- you work for several days on preparing an accurate and rigorous proof only to find the next day a trivial error in it.

      But this is very much the pattern described in [Lakatos76] [ maths/logic_20_Proofs100.html#Proofs and Refutations ] however with a longer timescale: mathematics progresses by the correction of false proofs and the discovery of mistakes and false assumptions in apparently good work.

      A very similar pattern is described in


      1. Donald O'Shea
      2. The Poincare Conjecture: In Search of the Shape of the Universe
      3. Walker & Co NY NY 2007 ISBN 0-8027-1654-7
      5. Compare to similar process noted by [Lakatos76]
      6. Need for peer review of mathematical results.
      7. Use of presentations.
      8. Mathematics as a social process. [DeMilloLiptonPerlis79]
      9. Rise of www.arXive.com.

      The other observation coming from this is that in every mathematical field of any interest there are always a large number of "Low lieing fruit" that are easily proved results. These tend to become part of the standard curriculum for the subject. But there is nearly always one very hard to reach result -- every body believes the conjecture but nobody has proved it. It can take millenia to figure out a proof or a refutation.

      Euclid's GeometryParallel PostulateDefines a special geometry
      Planar GraphsFour color theoremProof using FORTRAN program
      Number TheoryFermat's Last theoremProof after 400 years
      Computer ScienceP=NP?Unknown (2008)

      (Close Table)

      Now, Goedel showed that in sufficiently interesting logic there are results that can not be proved within the logic that are clearly true in a wider "Meta" system. So, perhaps, we should be surprised that there are always hard to prove cojectures in interesting mathematics.

      2008-04-07 Mon Apr 7 18:04 Start of sabbatical -- Pencil power

      Well I have one last antibiotic to take and the coughing and sneezing is much reduced... So back to work.

      I've been thinking about the following article


      1. Diomidis Spinellis
      2. On Paper
      3. IEEE Software Magazine V24n6(Nov/Dec 2007)pp24-25
      5. Notes the many advantages of using pencil and paper compared to computerized tools.

      When I need to prove something -- a recent example was an unexpected theorem (*13.192) in "Principia Mathematica" I reach for scrap paper and rough out a tree structure [ maths/logic_27_Tableaux.html ] that analyses the cases when the theorem does not hold. I taught this method to CSci undergraduates decades ago. It is quick and easy but the result is not something that I can share with others.

      In my last but one sabbatical I developed a language, like a programming language, that could express proofs. I moved it onto the web [ maths/logic_25_Proofs.html ] in the 1990s. I've also had some graduates develop tools that might help. But the fact remains that it easier to use paper and pencil rather than my own language.

      On the other hand, I can convert the tree structure into my language and tools can render the proof for the web. For example, to prove

    15. (MATHS)|- (PM13p192): for some c ( for all x(x=b iff x=c) and F(c) ) iff F(b).

      I start by assuming the negation and then split into cases for analysis...

      Proof of PM13p192

      1. not (for some c ( for all x(x=b iff x=c) and F(c) ) iff F(b) ).

        1. |- (a1): for some c ( for all x(x=b iff x=c) and F(c) ),
        2. |- (a2): not F(b).
        3. (a1, ei, c=>c)|-for all x(x=b iff x=c) and F(c) ,
        4. (-1)|- (a3): for all x(x=b iff x=c).
        5. (-2)|- (a4): F(c).
        6. (a3, ui, x=>b)|-b=b iff b=c,
        7. (-1)|-b=c,
        8. (-1, a4)|-F(b),
        9. (-1, a2)|-RAA.

        (End of Case)

        1. |- (b1): not for some c ( for all x(x=b iff x=c) and F(c) ),
        2. |- (b2): F(b).
        3. (b1, c=>b)|-not (for all x(x=b iff x=b) and F(b) ).
          1. |-not for all x(x=b iff x=b),
          2. (-1, x=>d)|-not (d=b iff d=b),
          3. (-1)|-RAA

          (End of Case)
          1. |-not F(b),
          2. (-1, b2)|-RAA

          (Close Case )

        (Close Case )

      (Close Let )

      By the way

    16. RAA::="Reducto Ad Absurdum".

      Today I verified that the same result is derived much quicker by first establishing

    17. (MATHS)|- (lemma): for all x(x=a iff x=b) iff a=b.

      Then using substitution to generate a chain of 'iff's like this:

      1. for some c ( for all x(x=b iff x=c) and F(c) )
      2. (lemma, a=>b, b=>c)|-
      3. iff for some c( b=c and F(c))
      4. (one_point_laws)|-
      5. iff F(b)

      (End of Net)

    18. one_point_laws::= See http://cse.csusb.edu/dick/maths/logic 25 Proofs.html#The Gries/Schnieder Laws

      Now, if you except the lemma then the above proof is complete. If not, click on the "turn-style"

      to link to the

      Proof of lemma

      1. not ( for all x(x=a iff x=b) iff a=b ),

        1. |- (c1): for all x(x=a iff x=b),
        2. |- (c2): a<>b.
        3. (c1, ui, x=>a)|-a=a iff a=b,
        4. (-1)|-a=b,
        5. (c2, -1)|-RAA.

        (End of Case)

        1. |- (d1): not for all x(x=a iff x=b),
        2. |- (d2): a=b.
        3. (d1)|-not( x=a iff x=b )

          1. |-x=a,
          2. |-not(x=b),
          3. (-1, -2, x=>a)|-not(a=b),
          4. (d2, -1)|-RAA.

          (End of Case)

          1. |-not(x=a),
          2. |-x=b,
          3. (-2, d2, a=>b)|-not (a=b),
          4. |-RAA.

          (Close Case )

        (Close Case )

      (Close Let )

      Again I roughed out the proof walking and then on paper and only afterward wrote it up using my formal MATHS language. I can now throw the rough work into the trash.

      Notice that hyperlinks make it fairly easy to check the proof by linking evidence to its statement...

      2008-04-03 Thu Apr 3 17:04 Sickness

      Followed up a cold by doing our taxes and going down after Easter with strep throat. Much rest and penicilin. Hope to get started back to work real soon, now.

      Meanwhile I see that there willbe a CSE Seminar [ seminar/20080411KenRice.html ] on applying high technology to proton beam therapy.

      2008-03-28 Fri Mar 28 11:03 Insight into Computers embedded in Humans

      Just read the following fascinating book.


      1. Michael Chorost
      2. Rebuilt: How becoming part computer made me more human
      3. Houghton Mifflin NY NY 2005 ISBN 0-618-37829-4
      5. How do you feel when what you hear depends on a program written in C and you can read the source code?
      6. Excellent discussion of science fictional treatments of cyborg's, androids, and the Butlerian Jihad in Dune.

      2008-03-24 Mon Mar 24 17:03 Sabbatical Next Quarter

      I've just posted my grades for the Winter quarter so I'm ready to take a break (taxes + a trip?).

      Next quarter I will be on sabbatical. This is a long tradtion in Universities. I guess it is assumed that after 7 years of teaching you will need a break to get your perspective and energy back. In CSUSB you have to apply and the aplication includes a form defining the project you plan to carry out on the sabbatical. Here is the short description

        To develop software and a web site that enable other computer scientists to experiment with and use my MATHS language. The software will enable the creation of linked, mathematical, and searchable documentation in HTML, XML, and ASCII.

      Here [ sabbatical.html ] are the details.

      I hope to start a new blog to track progress... and I have to decide where it fits this website. More later.

      2008-03-20 Thu Mar 20 17:03 Celebrating end of term by posting C++ FAQs

      This quarter I collect nearly 200 questions from students studying CS1 with C++. I put them into [ samples/c++.FAQ.html ] and linked it to the search engines for the site and [ samples/ ] , I hope it will be helpful.

      2008-03-07 Fri Mar 7 15:03 Getting over the cold of last week

      Just started to work on [ wiki?ClassesShouldKnowTheirObjectsPattern ]

      2008-02-29 Fri Feb 29 08:02 Got the Cold/Flu

      I started to get the fever and itchy mouth yesterday... I'm putting myself in quarantine and to bed.

      And while I remember... I submitted a review of a paper on pitfalls in the UML to CR this week.


      1. T Schattkowsky & A Forster
      2. On the Pitfalls of UML 2 Activity Modeling
      3. Proc Modeling in Software Engineering ( May 20-26 2007)
      5. Complexity + Informallity = Pitfall

      2008-02-15 Fri Feb 15 12:02 Review Published

      My review of [DamianiEtal06] has been published in the hardcopy Computer Reviews (CR) as #0802-0110 (Feb 2008) pp71-72.

      2008-02-13 Wed Feb 13 10:02 Seminar Update -- today Room UH250

      We moved it.... to get more space.

      2008-02-12 Tue Feb 12 18:02 Model checking with Aspects

      This is in my back log of readings...


      1. Shriram Krishnamurthi & Kathi Fisler
      2. Foundations of Incremental Aspect model-checking
      3. ACM TOSEM Trans Software Eng & Methodology V16n2(Apr 2007)pp1-39
      5. Models code as finite state machines with special (paired) transitions for entering and leaving subprograms.
      6. Aspects are modeled as finite state machines that are place in before/after/arround the special transitions.
      7. Aspects placed using regular expression on the state of the stack of calls.
      8. CTL modal operators used to state required properties.

      2008-02-11 Mon Feb 11 15:02 UML Usage

      Apparently only parts of the UML are used in practice


      1. John Erickson & Keng Siau
      2. Theoretical and practical complexity of modeling methods
      3. Commun ACM V50n8(Aug 2007)pp47-51
      5. People use parts of the UML: class statechart, sequence, use case,...
      6. Subset scores only 40% of complete complexity.

      2008-02-08 Fri Feb 8 09:02 Waterfalls vs Iteration -- and co-routines

      I've recently took note of a couple of articles in CACM that have me thinking about translating between phased processes and iterative ones.


      1. Michael P Papazoglou & Willem-Jan van den Heuvel
      2. Business process development life cycle Methodology
      3. Commun ACM V50n10(Oct 2007)pp79-85
      5. Very similar to classical systems life-cycle but with different details.
      6. No iteration or increments mentioned.


      1. Michael A Cusumano
      2. Extreme Programming compared with Microsoft-Style Iterative Development
      3. Commun ACM V50n10(Oct 2007)pp15-18
      5. Useful comparison

      Now at the end of the 1970s I had studied (and taught from) Knuth's magnum opus "The Art of Computer Programming" which describes co-routines as a coding technique in Section 1.4.2 and figure 22 shows that a four-pass algorithm, storing the data between the passes (phases?) could be transformed in a one-pass algorithm by making the programs in co-routines. Converting a program to a co-routine could easily be automated. For a new way of doing this in C, see [ co-routines ] below.

      At the end of the 1970's I left academe and learned (and taught) the "Jackson Structured Programming" where we would design a set of programs, each concerned with a different part of the problem, and connected by sequential files. One program would write the data to a file and another would then read it. Jackson had a technique for "inverting a program" or creating "semi-co-routines" that turned the multi-pass, phased system into a single program with co-operating pseudo-parallel processes. Typically, one process would generate a single piece of data and call another process to handle it. We used to tell stories of taking a Lego model to pieces and then reassembling a new one. We would point out that you could do this in "batch mode" and put all the pieces on the floor, and then start assembling the new model. You could also set it up so that an adult takes the old model to pieces and hands each piece to a child who builds the new model. For the details see [Jackson75] [Ingevaldsson79]

      I wrote up the various coding techniques in [ papers/restartable.txt ] in the early 1980s.

      I think that this idea of sequential designs running as parallel networks may have inspired McIlroy to put Pipes into UNIX and C.A.R. Hoare to develop CSP. Certainly Jackson's methods are a delight to use in UNIX, and are easily expressed in CSP.

      When I returned to academic life in the 1980's, I had got into the habit of looking a diagram that showed a series of phases and thinking in terms of cooperating parallel processes. Typically, a network like this does not stop so much as react to a stimulus, make a set of adjustments -- that ripple through the network -- and then stabilize again. It was a very nice way to think about human systems as well. Buffered connections between parallel workers describes nearly all the human systems that currently exist.

      It occurred to me that this idea also applied to software processes. A waterfall diagram could easily be implemented so that the "phases" actually execute in parallel. A change in the environment would trigger a bit of analysis, that would in turn trigger a bit of design, a bit of code, a bit of testing, and so on. This was how I thought circa 1985 when I wrote a text book (unpublished) and later in the 1990's when I wrote a monograph [ monograph/ ] on software development.

      Of course, we now see the "analyze a bit, design a bit, code a bit, ...." as a part of agile processes.

      So when I see a paper like PapazoglouHeuvel07 above I wonder whether the process could be executed in an agile way.

      2008-02-07 Thu Feb 7 11:02 Seminars Announced in JBH

      [ seminar/20080213YairCensor.txt ] (Visitting speaker) [ seminar/20080215ArpitaParikh.txt ] (MS Presentation) [ seminar/20080215Turing.txt ] (Faculty presentation) [ seminar/20080218YashaKarant.txt ] (Faculty presentation) [ seminar/20080222EliasChibli.txt ] (MS Presentation)

      2008-02-04 Mon Feb 4 13:02 Mapping nonsequential designs to sequential code

      Yet another example of simple nonsequential designs being implemented by more complex systems:


      1. Leonardo Mangeruca & Massimo Baleani & Alberto Ferrari & Alberto Sangiovanni-Vincentelli
      2. Semantic-Preserving Design of Embedded Control Software from Synchronous Models
      3. IEEE Trans Software Engineering V33n8(Aug 2007)pp497-509
      5. How to map functional requirements into a buffered network that is guaranteed to meet performance requirements.

      Which fits right in with an updated item next below.

      2008-02-02 Sat Feb 2 15:02 Co-routines revisitted

      I am a fan of co-routines [ Coroutine ] and other simple ways of faking parallelism such as semi-coroutines and and Jackson's restartable subroutines and program inversion. These techniques formed a key part of the methods I described in the 1990s [ 2.6 From DFDs to Code? in 01 2 ] and in a textbook I used but never published in the 1980's.

      So I was glad to be sent a new (to me) way of doing this in C by Andrew Murphy (and CS320 student). Here is the link [ coroutines.html ] to page showing how to do restartable code using the C/C++ preprocessor.

      Sometime I hope to retrieve, decode and update my notes on coding restartable subprograms. I've been waiting for a mainstream language to provide a simple light-weight form of nonsequential code for too long...

      2008-02-01 Fri Feb 1 12:02 Change Department name at 25th Anniversary Celebration

      President Karnig of CSUSB announced yesterday at the end of the 25th anniversary celebrartion for the department that the Department will have a new name: Computer Science and Engineering or CSE for short.

      I've just realized that this means I will have regenerate a lot of web pages.

      2008-01-30 Wed Jan 30 10:01 Todays non-reading

      Here are some of the goodies that I may need to refer to in the future. The references come from CR for January 2008.

      Ajax patterns and Best Practices [Gross06] Notice how pattern and best practice are popular these days. CR 0801-0009

      The Geek Gap [PflegingZetlin06] Why business and technology professionas don't understand each other and why they need each other to survive. CR 0801-0011

      In Search of Stupidity [Chapman06] Over twenty years od high tech marketing disasters (2nd Edn) CR 0801-0047

      2008-01-28 Mon Jan 28 09:01 Rainy day and Agile Bridge Building

      For once it is raining in San Bernardino. This is rare enough to cause flooding and car accidents. Meanwhile my brakes need work so I'm at home and telecommuting. So I have time to share an interesting article by Henry Petroski in the "American Scientist" (Jan-Feb 2008, page 14-18) with title "A Bridge and Observatory". He is describing the new suspension bridge at the Penobscot Narrows in the state of Maine on Route 1. I was intrigued by the "agile" techniques used in making this bridge -- for example the pillons at the bottom where being built while the top part of the bridge was being detailed. This could work because the bottom was built to specifications and the top parts relied on no more than these specifications. In other words, a classic "Design by Contract" and "Information Hiding" strategy.

      If you would like an example of throw-away prototyping then check out the history of the Victorian Forth Bridge at the border of England and Scotland. The engineer demonstated the strength of his idea by using men sitting on chairs with walking sticks -- supporting tremndous weights with ease.

      It is a pity that software is never as beautiful as most of the bridges I see when driving. I sometimes think taht software developers should do a course on bridge projects -- there is a lot to learn there.

      By the way -- check out [ http://25year.csci.csusb.edu ] this department's 25th anniversary celebration on Jan 31st -- 12-2pm in the Santos Manuel Student Union events center.

      2008-01-18 Fri Jan 18 16:01 Principia Mathematica and me

      On the 18th day of Xmas my true love gave to me:


      1. Alfred North Whitehead & Bertrand Russell
      2. Principia Mathematica to *56
      3. Cambridge University Press UK1997
      5. Facsimile of the beginning of the original 1927 magnum opus going from the propositional calculus to the definition of the numbers 0, 1, & 2!
      6. PM::="Principia Mathemtica by Russell and Whitehead, 1927".
      7. Attempts to construct traditional mathematics in formal symbolic logic.

      This is like giving an achoholic a crate of whisky. I first met it at about 11..12 years old and it didn't make much sense: many hieroglyphics all leading up to the definition of 2. Wierd. But then I tripped over logic with Lewis Carrol and hence traditional logic... and got a better hang of modern algebra and set theory. So the next time I opened it it made a lot of sense and I took copious notes. At college I use the PM notation as a shorthand -- it worked well mostly. The ε δ formalism of the calculus is easy to state in the PM notation.... But I was defeated by "The nest of intervals theorem" and by "Modern Mathematics" -- where the teacher proved set theoretic results by translating them into English. Of course I was translating the English into PM theory of classes and so end up with tautologies:-)

      Modern logic and set theory treats PM as a biway as far as far as I can tell tho' many academics borrowed some of their symbols (but not their dotty notation). And most mathematicians have no interest in an attempt to ground their work in logic.

      I can't prove this but Russell and Whitehead introduced a theory of types that seems to have inspired Algol 68 types.... which were inherited by C and so C++. Very interesting.

      Of course my design of much of [ maths/ ] is inspired by this book. However my notation used ASCII and was more readable than writable. My proof systems are intended to by powerful rather than pure and simple. In the next 6 months I hope to transcribe a large piece of PM into a sample of what MATHS.

      Anyway -- my bed time reading recently has been Dickens's iritating "Pickwick" and PM. The PM is sooooo relaxing that I tend to fall asleep almost as soon as I start to read it. I'm back doing my Ordinary Levels at school and reading PM when I don't have an exam. If you want to know what this was like -- check out "Ordinary Wizarding Levels" in the Harry Potter series.

      2008-01-14 Mon Jan 14 12:01 Swim Lane Based Analysis and Design

      Here is a tantalizing "straw in the wind" -- a letter making large claims that I haven't been able to substantiate.


      1. Sidney L Burnsten
      2. To map a process, first find its swimlane
      3. Commun ACM V50n10(Oct 2007)p14
      5. SLB::="Swim Lane Based".
      6. Draw both "as is" and "to be" diagrams.
      7. Involve users and stakeholders.
      8. Each actor has a swimlane. Show activities & decisions in lanes. include information.
      9. Claims many years of successful use.
      10. Claims better than DFDs or Usecases.
      11. Sounds like it is compatible with UML2.0 Activity diagrams.
      I'm familiar with UML2.0 activity diagrams with swimlanes. Here is a link to an example I use in a course [ cs372/07ActivitySwimLane.gif ] and some notes [ cs372/r1.html#Activity Diagrams ] from the same course on activity diagrams. I've always found them attractive and I think students find them easy to learn. On the other hand DFDs do a good job of showing how many processes/components interact. It would be good to have some data on the best way to use the two notations in real projects.

      2008-01-10 Thu Jan 10 07:01 Personal note on anosmia and snoof

      As I noted previously I've lost my sense of smell, and my mother once defined the word "snoof" to describe this handicap on a BBC broadcast. She lamented that there was no scientific or medical word for this disease. Today, on my local Public Radio Station (KVCR [ fmprograms1.htm ] ) I discovered that the disease is called anosmia. See "A Moment of Science" [ anosmia.html ] for the transcript of what I heard.

      Meanwhile a footnote to PaiDuggan07 below for a source for Alberg diagrams of the prevalence of bugs in software:


      1. Niclas Ohlson & Hans Alberg
      2. Predicting Fault-prone software modules in telephone switches
      3. IEEE Trans Software Engineering V22n12(Dec 1996)pp886-894
      4. =EMPIRICAL METRICS FAULTY MODULES 130 Alberg diagrams Pareto Ericsson
      5. Metrics can predict the 20% most fault prone modules.
      6. Alberg diagram plots cumulatve %faults vs %modules with that # of faults.

      2008-01-03 Thu Jan 3 16:01 Bayesian Methods

      I've been seeing a lot of "Bayesian Methods" used to model software processes and qualities recently. So here is the original source, a critique of a particular approximation, and an application of BBNs -- (Bayesian Beleief Neteworks) to a NASA database of C++ source code.


      1. T Bayes
      2. An essay towards solving a problem in the doctrine of chances
      3. Phil Trans Royal Society V53(1763)pp370-418
      5. Bayes approach to probability was to assume that the number represented the degree of belief a person had in the proposition.
      6. He argued that a rational person would have to follow certain rules. For example is P(A|B) is the probability of A given that B is true, then
      7. P(A&B) = P(A|B)*P(B).
      8. He worked out rules for rationally reevaluating the beliefs as new data came in.
      9. The heart of this is:
      10. (Bayes)|- (Bayes_theorem): if H is a set of mutually exclusive events, and E some new evidence, then for h:H, P( h | E) =P( E |h )*P(h )/Σ P( E | _ ).


      1. Feng-Jen Yang
      2. Eliciting an overlooked aspect of Bayesian reasoning
      3. ACM Inroads & SIGCSE Bulletin V39n4(Def 2007) & proc ITiCSE'07 pp45-48
      5. if H is a set of mutually exclusive events, then Bayes theorem calculates for h:H, P( h | E) =P( E |h )*P(h )/Σ [h:H]P( E | h ).
      6. If E=&e then assuming that
      7. P( E |h ) = Π[i](P( e[i] | h )) leads to large errors in some cases.


      1. Ganesh J Pai & Joanne Bechta Dugan
      2. Empirical analysis of software fault content and fault proneness using Bayesian methods
      3. IEEE Trans Software Engineering V33n10(Oct 2007)pp675-685
      5. Works as well as traditional stats did.
      6. NASA_data::= See http://mdp.ivv.nasa.gov/.
      7. Netica::tool= See http://www.norsys.com/.
      8. BayesX::tool= See http://www.stat.uni-muenchen.de/~bayesx/.
      9. Uses Alberg diagrams from OhlsonAlberg07 above.

      I was brought up on traditional statistics -- probabilities as hypothetical limits on very large samples and tests of significance. He is a more trad approach to modeling the structure of software:


      1. Giulio Concas & Michele Marchesi & Sandro Pinna & Nicola Serra
      2. Power-laws in a large Object-Oriented Software System
      3. IEEE Trans Software Engineering V33n10(Oct 2007)pp687-708
      5. Measured metrics on three large OO development tools to determine distributions of properties. Found patterns: most metrics have a log-normal or Pareto distribution.
      6. Quoted theories for these distributions.
      7. Noted that for these distributions extreme values are more likely than the normal/chi-square/t family of distributions. The mean value is not a good estimated of position.
      8. Basic process: number of entities have a numeric property. Entities are picked at random and the chosen entities property is increased. How many entities will have a given range of properties?
      9. If the each entity has the same chance and the same change is made the resulting distribution is binomial.
      10. If the size of the increase depends on the value of the property the distribution is log-normal.
      11. (Yule process): If the increase is fixed but the chance if the entity being chosen depends on the property value then the distribution is Pareto.
      12. (log-normal): p(x) = if(x<0, 0, (1/sqrt(2*π))*exp(-(ln(x)-μ)**2/(2*σ**2))).
      13. Example metrics: #methods/class, #all instance variables/class, #LOC/class, class out-degree (see note below).
      14. (Pareto): p(x) = if(x<xmin, 0, (α*(x/xmin)**(-α)/xmin)).
      15. Example Metrics: #Inst vars/class, #subclasses, inst variable names, method names and calls, LOC/method, class in-degree.
      16. Refers to H Simon Biometrica V42 pp425-440 1955 and Newman Cont Physics V46 pp323-351 2005.
      17. Notes that the class outdegree is correlated with the class LOC and so outdegree/LOC has a Gamma distribution.

      2008-01-01 Tue Jan 1 08:01 Starting the new yesr -- 2008

      The first item of business is to archive last years blog entries into [ blog007.html ] and then write a short piece introducing the purpose, audience, and format of this blog in the coming year.

      This blog is an irregular listing of things I've read on the topic of software development mainly in hte magazines and journals of the two main proffessional societies: IEEE and ACM. The original idea was to index the most practical theories, and the the most reliable experiences. I'm writing this for people studying computer science and engineering -- students in college, faculty, practitioners, etc.. The idea is to take the significant publications and describe and comment on them... and place them in a bibliography...

      Warning -- my selection of items to record is biased by nearly 40 years of programming and an addiction to symbolic logic and algebra.

      Meanwhile I'm interleaving a more personal record of events and comments on my life as a computer science faculty.... with cancer.

      My teaching is blogged separately for each class. Similarly my admin responsibillities -- the public ones -- have their own websites [ 25th/ ] [ seminar/ ] with the latest entries linked to my home page.

      At this time I don't provide an RSS feed -- if you want to see what is new on my web site -- look at the index page [ http://cse.csusb.edu/dick/ ] where the last entries are listed and linked.

      New years resolution -- reduce swearing more and start blogging more regularly.

      Looking forward to -- getting the celebration of the CSDepts 25th behind me, taking a sabatical to develop the software that will open up this blog and my other pages to people who read it. In particular, putting my [ maths/ ] language on to the web so you can use it to generate web pages with mathematical and logical content.

      Thought of the day -- hindsight is 20-20 and depressing.

      Previous Blogs

      (Blog to December 2007): [ blog007.html ]
      (Blog December 2006): [ blog006.html ]
      (Blog December 2005): [ blog005.html ]
      (Blog December 2004): [ blog004.html ]
      (Blog December 2003): [ blog003.html ]
      (Blog July 2003): [ blog002.html ]
      (Blog June 2003 and before): [ blog001.html ]


      [ blog.html ]

      Glossary and Links

    19. above::=using the above statements....

    20. bibliography::= See http://cse.csusb.edu/dick/newbib.html, (source [ newbib.mth ] ) a large collection of publications on software development. a place to search for data on my site. Now recovered from damage done in the latter half of 2003.

    21. dick::=indicates my own opinion in and of a bibliographic item.

    22. given::=the data and input into a proof, construction or other thinking.
    23. goal::=the current conclusion, target or unknown of the thinking, construction, or proof.

    24. Haiku::poem="A 19 syllable Japanese poem that captures one moment but implies the universal", All Haiku are supposed to indicate the season of the year and Japanese has many words and phrase that are used for these purposes. Most Haiku also have a caesura (pause) that is counted as a single syllable. Writing Haiku in English is like trying to clap with one hand.

    25. languages::= See http://cse.csusb.edu/dick/samples/languages.html, information on computer languages.
    26. latest::= See http://csci.csusb.edu/dick/blog.html,

    27. MATHS::= See http://csci.csusb.edu/dick/maths/, a language for semiformal documentation including ontologies, logics, conceptual models, specifications, and algorithms that I also use for weblogs, essays, lecture notes, etc. etc.

    28. methods::= See http://cse.csusb.edu/dick/samples/methods.html, links and definitions about software development methods and processes, plus some jokes. Also see [ methods.glossary.html ] instead.
    29. monograph::= See http://cse.csusb.edu/dick/monograph, a study of software development methods 1940-1990 attempting to show how simple mathematics can avoid common errors.

    30. papers::= See http://cse.csusb.edu/dick/papers, pre-publication drafts, local seminars, unpublished essays, etc..
    31. people::= See http://cse.csusb.edu/dick/samples/people.html,

    32. prostate::gland=`a walnut sized gland found in human males that has cells that have a tendency to turn cancerous as the male gets older`, see PSA. [ http://www.healthopedia.com/prostate-cancer/ ] (not checked for accuracy, includes adverts).

    33. PSA::blood test=Prostate Specific Antigen, the cells in the prostate generate a particular chemical in the blood and this test measures how much. High values (40+) show rapidly growing cancer. From my experience -- values like 5, 6, and 7 are a cause for concern .. but it all depends on age and whether heart disease or some other problem will get you first. To get a score of zero (undetectable <0.01) the cells must be gone or not growing.

    34. samples::= See http://cse.csusb.edu/dick/samples/, samples of documents prepared using MATHS.
    35. se::= See http://cse.csusb.edu/dick/samples/se.html, links to things about software engineering and software development.
    36. source::= See http://cse.csusb.edu/dick/blog.mth, I use my own MATHS language to write these blogs.

    37. standards::= See http://cse.csusb.edu/dick/samples/standards.html,
    38. STANDARD::= See http://cse.csusb.edu/dick/maths/math_11_STANDARD.html, my personal standard definitions for MATHS.
    39. subjects::= See http://cse.csusb.edu/dick/samples/subjects.html,

    40. tools::= See http://cse.csusb.edu/dick/samples/tools.html,

    41. vita::= See http://cse.csusb.edu/dick/VITAble.html, [ short.vita ] (plain text).

    42. XBNF::=eXtreme Bachus Naur Form, a metalanguage based on EBNF that can handle some forms of context dependency in an intuitive way, as part of the MATHS language.

    43. Z::= See http://cse.csusb.edu/dick/samples/z.html, specification language.

    . . . . . . . . . ( end of section RJBottings Research Web Log 2008) <<Contents | End>>

  1. CR::="Computer Reviews", [ http://www.reviews.com/ ] and [ browse_reviewers.cfm?reviewer_id=115728 ]