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


    RJBottings Web Log 2009

      See [ Invitation to Contribute ] (below) to share your observations and readings on software development.

      2010-02-23 Tue Feb 23 20:12 Why

      Software developers tend to focus on the "how" of a piece of software. It takes discipline to first specify the "what" the software does, rather than "how" it does it. Rarely does the reason for the software -- the "why" -- obtrude on the difficult and engrossing task of creating the "how". Here are two examples of people proposing the importance of "why", First David Grier (Grier09a) describing a sales pitch that falls disastrously flat because the seller did not show any interest in what the customer needed. This article also quote a couple of patterns -- Patterson and Shewhart that we all need to use.

      In another version of "why" the case is made for a higher level description of services in terms of commitment ( SinghChopraDesai09) than usual. This is a popularized advert for an idea that dates back to [DesaiEtal05] and is detailed with examples of use [DesaiChopraSingh09]


      1. David Alan Grier
      2. Bad alignment
      3. IEEE Computer Magazine V42n11(Nov 2009)pp-
      4. =ESSAY STAKEHOLDERS REQUIREMENTS MARKETING PEOPLE Patterson Shewhart Cs372 aaccreditation
      5. Patterson::=identify need; propose solution; demonstrate; close.
      6. Shewhart::=(plan; do;check; analyse ).repeat.


      1. Munindar P Singh & Amit K Chopra & Nirmit Desai
      2. Commitment-based Service-Oriented Architecture
      3. IEEE Computer Magazine V42n11(Nov 2009)pp72-79
      5. CSOA::="commitment service oriented architecture".
      6. Higher level than previous service descriptions.
      7. Commitments express business meanings. Debtor, crediitor, in context. Commitments can be manipulated.
      8. Patterns: Commit, Compensate, Delegate retaining responsibility, Escalate, Delegate and Transfer responsibility, revert offer, ...
      9. Also see [DesaiEtal05] and [DesaiChopraSingh09]

      2009-12-17 Thu Dec 17 18:34 So-called formal methods and testing

      This will probably be the last posting to this blog until the new year so Happy Holidays to all my readers.

      The early work on "formal methods" was a direct help with my Ph. D. Project -- an early language and system for doing engineering drawings. Using ideas in Tony Hoare's 1969 paper [Hoare69] Plus Robert Floyd's [Floyd67a] proof techniques for flowcharts, I was able to produce low level routines and data structures that always worked. The bugs appeared in the unproven code written in a high level language. This experience made me think that invariant assertions were a useful tool. So I tracked the development by Bertand Meyer of Design by Contract with the concepts of pre- and post- conditions. Any way here is Tony Hoare looking back at his 1969 seminal paper and Meyer Et Al looking at the latest application of contracts -- to programs that test themselves.


      1. C A Hoare
      2. retrospective: an axiomatic basis for computer programming
      3. Commun ACM V52n10(Oct 2009)pp30-32 [ 1562764.1562779 ]
      5. Looking back at [Hoare69] 40 years later. Compare [Hoare01]
      6. Expected to retire before research was complete and industry adopted methods.
      7. Surprised to find "assert" in C/C++.
      8. Didn't expect the new logics/mathematics that have been developed.
      9. Tests test the programmer not the program.
      10. Hackers have got industry interested in verification -- finally.
      11. Academic and industrial research should complement each other. One goes for the big ideals and the other for low hanging fruit.


      1. Bertrand Meyer & Arno Fiva & Ilinca Ciupa & Andreas Leitner & Yi Wei & Emanuel Stapf
      2. Programs that test themselves
      3. IEEE Computer Magazine V42n9(Sep 2009)pp46-55
      5. Contacts define unit tests...

      2009-12-15 Tue Dec 15 17:58 Back but Exhausted

      I got back to San Bernardino..... got the finals squared away and then had a family crisis involving an emergency room and a long long wait.... So you will have to do with the posting from Monday below.

      2009-12-14 Mon Dec 14 11:06 Language of the month -- MATLAB

      The Australian newspaper -- "ComputerWorld Australia" is continuing its survey of languages and the latest is MATLAB by Cleve Moler:


      1. Kathryn Edwards
      2. The A-Z of Programming Languages: MATLAB
      3. Computerworld Australia (Dec 09 2009) [ -z_programming_languages_matlab ]
      5. Surprise success of a tool develop for students... favourite feature
        1. It’s the mathematics. The thing that I enjoy as a mathematician is finding out how mathematics underlies so many different disciplines. We didn't intend to do automobiles, anti-lock brakes or human genome or pricing of derivatives in the finance market. We never set out to do any of that originaly, but mathematics is common to all of these. I really enjoy talking about how these different fields are unified by the underlying mathematics.

      2009-12-08 Tue Dec 8 14:39 Notions -- notations -- Halting Problem

      I won't be able to follow the usual schedule this week. We have final examinations and my sinus/nose is going crazy today. I am then visiting another campus until Friday. So I this posting is going to go into more detail than usual. It will also be about my own hobby of mathematical notations suitable for discussing computation.

      I have been working on improving mathematical notation for a long time -- in particular back to using a Frieden Flexowriter to write my notes on "Languages and Automata". So I was intrigued by an article in a recent edition of Wired [Bird09] advertising a new notation that claims to express "the Halting Problem". As far as I can see the formula in the new notation would be written like this in my MATHS language

    1. I;do(R);K ==> lift(f) | lift(g),

      and I can not see how it expresses the claimed meaning -- even if I knew the meaning of lift above. I chased the source back to Saini09. The intent is clear: We have a set of States(S?)

    2. S: Sets.
    3. I : @ S, the initial states of a machine/system/automaton,
    4. K : @ S, the halting states,
    5. R : @(S, S), the relation between successive states.


    6. I; R^n; K

      expresses that the system halts(enters K) in n steps if started in I.


    7. for some n: Nat0 ( some (I; R^n; K) )

      is true if the system halts. Note: lots of details need working here: we need notions not notations.

      Now this model is pleasantly general. For example is S=Int, I={1}, K={10}, and R = (+1) then we have a simple counter that halts after 9 steps. But if K={-1} then the system never halts. Neither does a system with S=Rat, I={1}, K={0}, and R=(/2).

      Here is a system --- related to the Hailstone sequence [ maths/logic_41_HomogenRelations.html#Enigma ] that may or may not halt. N=Net{n:Nat}, S=$ N, I=$ N with n=n0, K=$ N with n=1,

    8. R = ( 2*n' = n | 2*n' = 3*n+1 ).

      Indeed it is even simple to set up a Turing Machine with a finite state (q:Q), a head (h:A), and two stacks for the strings [ maths/math_61_String_Theories.html#MW ] to the left and the right (l,r:#A). The operations on the tape are then modeled most simply by

    9. M(1):=( l'=h?l and r=h'?r'),
    10. M(-1):=( r'=h?r and l=h'?l'), and
    11. W(a):=( h'=a ).

      You can prove that M(-1);M(1) = Id = M(1);M(-1) using the techniques [ maths/math_14_Dynamics.html#Calculations ] in my MATHS web site.

      The quintuples are a set in A><Q><A><Q><{1,-1} of course. I'll leave you to work out the details for defining the predicate that represents the fact that a particular TM stops on a particular input.... it is classic text book stuff. I like Minsky's way of doing it [Minsky68] to any later treatment...

      Anyway -- here are the articles that piqued my interest...


      1. Angela Saini
      2. A Good Sign
      3. Science 24 July 2009)p391 DOI: 10.1126/science.325_391
      5. Dr. Byron Cook (QMC & MS Cambridge) [ http://research.microsoft.com/en-us/people/bycook/ ]
      6. new notation for relational calculus


      1. Cameron Bird
      2. Wired (Dec 2009) [ st_goodsigns ]
      4. Dr. Byron Cook (QMC & MS Cambridge) [ http://research.microsoft.com/en-us/people/bycook/ ] new notation for relational calculus

      2009-12-03 Thu Dec 3 20:43 Distributed teamwork

      Here we have a set of readings on the structure and behavior of teams -- can agile practices work without co-location? What promotes trust between distributed team members? Can you promote self-management in a team? Do all open-source projects (distributed, self-managed, and quite agile) all develop an "onion" structure?


      1. Dinesh Batra
      2. Modified agile practices for outsourced software projects
      3. Commun ACM V52n9(Sep 2009)online [ 1562164.1562200 ]
      5. You have to modify agile methods when the team is not co-located.


      1. Ban Al-Ani & David Redmiles
      2. Trust in distributed teams: support through continuous coordination
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp35-40
      4. =SURVEY TEAMS TRUST =ADVERT Palantir Ariadne World View Workspace Activity Viewer
      5. Finds that leadership and time promote trust but diversity, size, and project type have a negative effect.
      6. Argues that tools that make other peoples work visible to the team should promote trust.


      1. Nils Brede Moe & Torgeir Dingsoyr & Tore Dyba
      2. Overcoming barriers to self-management in software teams
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp20-26
      5. Letting a team manage itself leads to efficiency ... But ...
      6. Avoid specialisms, get generalists, encourage working together,and collocate the team.
      7. Assign people to only one team at a time.
      8. Build trust and commitment by avoiding unneeded control, under resourcing, etc.


      1. Hakan Erdogmas
      2. A process that is not
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp4-7
      5. An example of an unusually open project. No onion....
      6. Tiki::= See http://tikiwiki.org/

      2009-12-03 Thu Dec 3 12:21 CSE Openhouse

      To look at my department and some high school students.... [ openhouse2009 ] (I'm the guy with a pumpkin full of candy...).

      2009-12-01 Tue Dec 1 20:43 Robert Glass looking back

      I will admit to getting irritated with Robert Glass and so missing an article back in 2001 that has just got republished. It has something to say about everything that interests me in Software Development. He has also just retired from the final pages of the IEEE Software magazine.


      1. Robert L Glass
      2. Goodbye
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp96+95
      5. Estimates are done by the wrong people and too early. No process to adjust estimates as process generates data. No agreeed method for estimates.
      6. Local loyalties lead to wasted controversy about software development.
      7. One size does not fit all. New methods need evaluation to match their best application.


      1. Robert L Glass
      2. Frequently Forgotten Fundamental Facts about Software Engineering
      3. IEEECS Career Watch Newsletter (1 Dec 2009) [ fa035?utm_source=bronto&utm_medium=email&utm_term=Forgotten+Facts+About+Software+Engineering ] reprint of IEEE Software magazine V18n3(May/Jun 2001)pp112+110-111

      2009-11-26 Thu Nov 26 16:18 ERP customization and Architectural Knowledge

      It is good to see publications of conclusions based on observing real developers do a real task. In this case it is adapting a generic "Enterprise Resource Program" to particular customers. And one of the challenges to people doing this is understanding the program they are working with.

      This also give evidence against one of the big lies that many teach in Computer Science. Many texts, papers, and teachers assume that development is always about starting a new program from scratch. In practice, nearly all software development is working with an existing system -- making changes within an existing framework -- rather than "green field" trail blazing...


      1. Yvonne Dittrich & Sebastien Vaucouleur & Stephen Giff
      2. ERP customization as software engineering: knowledge sharing and cooperation
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp41-47
      5. Understanding the ERP is the main challenge. Communication. Apprenticeship. Studying code.
      6. Need more than user documentation to customize ERP.
      7. Separate new code from old code.
      8. A feature can effect tables , forms, code, etc. Crosscutting:.aspects?! Multilevel.
      9. (dick)|-more like maintenance than green field development.

      2009-11-25 Wed Nov 25 16:51 APIs need architectural knowledge

      I am posting this one day early.


      It appears that one of the key reasons practitioners find certain APIs difficult to use is the lack of information explaining why the function calls are the way they are.


      1. Martin P Robillard
      2. What makes APIs hard to learn? Answers from developers
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp27-34
      5. 50% documentation, 36% structure of API, 17% background, 15% technical environment, 15% process.
      6. Need architectural knowledge -- Need to have answers to why the API is the way it is.
      7. Better examples.
      8. Document possible and significant sequences of calls. See life history documentation and JSD!
      9. Magic gets in people's way!

      2009-11-24 Tue Nov 24 15:16 Architectural Knowledge

      I tripped over a rich stream of thought about the meaning of `architactural knowledge`. It looks like we are developing a lot of ideas that may or may not pay off. Here are three papers by people in a particular school of thought...


      1. Remco C de Boer & Rik Farenhorst
      2. In search of 'Architectural Knowledge`
      3. ICSE 2008, 3rd I workshop on Sharing and reusing architectural knowledge (2008) pp71-78 [ 1370062.1370080 ]
      5. Number of relevant papers increasing exponentially.
      6. Out of 115 papers, 14 give a clear definition. 7 in 2007 alone.
      7. Abstract
          The software architecture community puts more and more emphasis on 'architectural knowledge'. However, there appears to be no commonly accepted definition of what architectural knowledge entails, which makes it a fuzzy concept. In order to obtain a better understanding of how different authors view 'architectural knowledge', we have conducted a systematic review to examine how architectural knowledge is defined and how the different definitions in use are related. From this review it became clear that many authors do not provide a concrete definition of what they think architectural knowledge entails. What is more intriguing, though, is that those who do give a definition seem to agree that architectural knowledge spans from problem domain through decision making to solution; an agreement that is not obvious from the definitions themselves, but which is only brought to light after careful systematic comparison of the different studies.


      1. Remco C de Boer & Hans van Vliet
      2. On the similarity between requirements and architecture
      3. Journal of Systems and Software V82n3(Mar 2009)pp544-550
      5. Abstract
          Many would agree that there is a relationship between requirements engineering and software architecture. However, there have always been different opinions about the exact nature of this relationship. Nevertheless, all arguments have been based on one overarching notion: that of requirements as problem description and software architecture as the structure of a software system that solves that problem, with components and connectors as the main elements.

          Recent developments in the software architecture field show a change in how software architecture is perceived. There is a shift from viewing architecture as only structure to a broader view of ‘architectural knowledge’ that emphasizes the treatment of architectural design decisions as first-class entities. From this emerging perspective we argue that there is no fundamental distinction between architectural decisions and architecturally significant requirements. This new view on the intrinsic relation between architecture and requirements allows us to identify areas in which closer cooperation between the architecture and requirements engineering communities would bring advantages for both.


      1. Rik Farenhorst & Hans van Vliet
      2. Experiences with a Wiki to Support Architectural Knowledge Sharing
      3. 3rd Workshop on Wikis for Software Engineering (Sep 2008) .See http://farenhorst.eu/publications/Farenhorst-vanVliet-Wikis4SE2008-CRC.pdf (download November 24th 209).
      5. How to make it easy for a team to store, retrieve and develop architectural decisions and their rationales using a Wiki.
      6. Knowledge = Decisions + Design.
      7. Concern=Net{Description, #Alternative, Ranking Criteria, O(Decision)}
      8. Decision=Net{Id, Status, #Relationship, Rationale}.
      9. Do start small.
      10. Do allow and stimulate all types of knowledge.
      11. Do strive for integration.
      12. Don't impose too much structure.
      13. Don't restrict access

      2009-11-19 Thu Nov 19 19:00 An old and powerful linguistic idea rediscovered

      Here are a couple of independent papers both showing how to exploit a particular syntactic/semantic trick that I exploited in the 1980's when design an ASCII-based language for logic and discrete mathematics called PINAPL. In time it became the language (MATHS) I use for this blog and a large web sites. I found it in "A Programming Language" [ samples/languages.html#APL ] in the 1960's and 70's. In essence, normal arithmetic operators can be used (in various syntactic forms) to operate on vectors, lists, sets, and functions. The result is nearly a powerful generalization of normal algebra.


      1. Daniel E Cooke & J Nelson Rushton
      2. Taking Parnas's Principles to the Next Level: Declarative Design
      3. IEEE Computer Magazine V42n9(Sep 2009)pp56-63
      5. Rediscovers APL and Lucid.
      6. (dick)|-almost like executable MATHS. For example, Σ( 1/((0..n)!) ) in MATHS looks like this
          sum(1/fact( [0,...,N]))
        in SequenceL.
      7. Compare [Holmes09]


      1. Neville Holmes
      2. Truth and Breadth, Clarity and Depth in Algebra
      3. IEEE Computer Magazine V42n11(Nov 2009)pp108+106-107
      5. Use APL/MATHS style operators to express complicated calculations in exact arithmetic.
      6. Compare [CookeRushton09]

      2009-11-18 Wed Nov 18 15:25 Thanks for the typos

      Dr. Christopher Landauer is enrolled in the elite list of people who have sent me lists of errors to correct. This has helped me fix a dozen typographical mistakes in [ samples/ada.syntax.html ] my syntx of the Ada Programming language.

      2009-11-17 Tue Nov 17 17:57 Still Waiting for the Engineering of software

      Mary Shaw was invited to look backwards and write an update of here 1990 article on how professional engineering might arise with software. Interesting history and some speculation about the future.


      1. Mary Shaw (CMU)
      2. Continuing prospects for an Engineering Discipline of Software
      3. IEEE Software magazine V26n6(Nov/Dec 2009)pp64-67
      5. Review of [ShawM90] "Prospects for an Engineering Discipline of software"
      6. History of programming practices by decade originally 1960-1990 now extended to 2010.
      7. Three new trends: abstract architecture (1990+-5), Democratization on the Internet (2000+-5), Vanishing system boundaries.
      8. Notes conflict between high-ceremony (CMM) vs agile and open-source processes.
      9. Production and Craft ~~> Commercial, Commercial and Science ~~> Engineering.
      10. Need for documented for routine ways to solve precedented problems. Being satisfied by open documents on the web.
      11. More specialisms are emerging.

      2009-11-16 Mon Nov 16 13:01 Bad comments are found in bad code

      Here [ if-comments-are-ugly-code-ugly ] is a nice blog-item by Esther Schindler (November 15th 2009). It is something I believe.... but I find it difficult to practice, as you know if you read my blog regularly.

      2009-11-12 Thu Nov 12 20:19 More on Agile and formal or mathematical methods

      The latest issue of IEEE Computer Volume 42 Number 2 has a couple of letters and an article that argue against BlackEtAl09 (next below) and their attempt to mix formal methods with agile processes. William Adams on page 6 has a letter restating the traditional theory that agile methods don't work on big projects and formal methods are needed instead including a dose of waterfall planning. It is not clear what methods he considers to be formal. His real world has fixed requirements and budgets.... He is rebutted by the original authors who quote some large, real projects that used agile methods with success.

      On page 7 Harry Gilbert claims to be a competetn programmer (and author of "Practical Pascal") who does not do mathematics and so is blocked from computer science. Modern CS curricullum's have less mathematical BA degrees... But more disturbing is Neville Holmes's rationale for defining a non-algebraic tool for doing exact calculations because there is a decline in mathematical skills. He proposes a functional scheme called the `formulator' that I will report on later...

      Meanwhile I am worrying about the possible futures with less mathematics in it.

      2009-11-10 Tue Nov 10 19:32 Mixing agile with other methods

      Real programmers don't like documentation but it does have value, see Selic09 below. Mathematics is a shorthand. It could reduce the amount of upfront documentation. Perhaps [BlackEtAl09] it can be used in an agile way. This led me (years ago) to invent an accronym:
    12. AMAS::="Agile Mathematics Applied in Software development". Also this second reference has some links to some tools and methods.


      1. Sue Black & Paul P Boca & Jonathan P Bowen & Jason Gorman & Mike Hinchey
      2. Formal versus agile: Survival of the Fittest
      3. IEEE Computer Magazine V42n9(Sep 2009)pp37-45
      5. SEEFM2003::acronym="First South East Europe Workshop on formal methods", [ SEEFM03 ]
      6. XFM::="eXtreme Formal Modeling", [ 1109118.1109120 ]
      7. XFun::= See http://delab.csd.auth.gr/~bci1/SEEFM03/seefm03_03.pdf (PDF), Unified Process with X-Machines verified by model checking.
      8. KeY::method= See http://i12www.iti.uni-karlsruhe.de/~key/keysymposium07/slides/haehnle-agile.pdf
      9. Extend TDD by including static-analysis and theorem-proving tools to extend coverage. Example 97% of assertions checked automatically in SPARKAda toolset.
      10. How do formal requirements handle creep?
      11. Machine checked refactoring?
      12. Parallelism: FDR and Coverity [ http://www.coverity.com/ ]
      13. Speed and availability of tools: Rodin [ http://rodin.cs.ncl.ac.uk/ ]
      14. and Deploy [ http://www.deploy-project.eu/ ] projects. Praxis [ http://www.praxis-his.com/ ] has SPARK toolset as open source.
      15. Formal methods lite -- use math at the right times in a project.
      16. Argues that the total cost (effort) for a project is less with up front work getting requirements etc. right.
      17. Agility is not about speed but maneuverability. Producing the highest quality in each iteration/increment. Compared to RAD.
      18. Controlling the technical debt.
      19. No real conflict... given some mutual understanding.


      1. Bran Selic
      2. Agile documentation anyone?
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp11-12
      5. Documentation has no value to the producer but can be valuable to others.
      6. Code does not provide Rationales and Architectual specifications.
      7. Documentation must be closer to the user's domain than the code is.

      2009-11-10 Tue Nov 10 12:27 Quick addition

      Added some thoughts [Maiden90b] on the certification of requirements engineers and updated, as a result [CurtisKrasnerIscoe88] and [Paech08] as well. Maiden endorses the "one size does not fit all" philosophy and the importance of domain knowledge to a project.

      2009-11-06 Fri Nov 6 11:45 A couple of quick ones

      The Communications of ACM has a souple of good survey articles in its September issue. The first is a comparison of distributed vs centralized version control systems -- see [OSullivan09] in my bibliography. The second is a history and status report on the P=NP problem. See [Fortnow09] for citations etc.

      2009-11-05 Thu Nov 5 19:51 A Traditional Formal Method

      The following paper summarizes a lot of the thinking from the 1970s thru to the 1990s. Abrial09 points out the role of formality when determining requirements but ignores the common need to discover requirements by implementing software.


      1. Jean-Raymond Abrial
      2. Faultless Systems: Yes we can
      3. IEEE Computer Magazine V42n9(Sep 2009)pp30-36
      5. assumes waterfall is necessary.
      6. process=requirements; model; code.
      7. requirements are a mixture of informal explanations and form definitions and proofs etc.
      8. Use coupled discrete state transition systems. And animation. Prove invariants.
      9. Need tools to prove thousands of changing propositions.
      10. Validate the problem as a system in an environment not just the software.
      11. Problem with not enough discrete mathematics in education.
      12. Problem with technology transfer.
      13. Link [ http://www.event-b.org ]

      2009-11-05 Thu Nov 5 14:09 Chance of Extra Credit

      [ seminar/20091112BrokenCirclesStudios.txt ] (November 12th 10-11:50 JB360).

      2009-11-03 Tue Nov 3 20:16 Formal Methods and Requirements

      This is the first of a series of postings on what have been called "Formal Methods" which I interpret to mean techniques that apply mathematics and logic in the development of software. The first (JaspanEtAl09) reports on a discussion of formal methods and whether the myths still hold. This reviews an article from 1990. Oddly it does not refer to either [BowenHinchey95b] which added seven more myths to the original list or to [BowenHinchey06] which stated 10 commandments. But it noted that formal methods have expanded beyond proving that a specification is met by a program. They now are commonly used in requirements engineering. Which takes me to the next two papers that report experiences with formal methods for requirements. The first (DesaiChopraSingh09) describes in excruciating detail the Amoeba method applied to two large (if artificial) projects. Amoeba helps work out requirements for connecting disparate actors together. The other (NuseibehHaleyFoster09) describes the development of a secure Air Traffic Control system despite possible malice and malfeasance.


      1. Ciera Jaspan & Michael Keeling & Larry Maccherone & Gabriel L. Zenarosa & Mary Shaw
      2. Software mythbusters explore formal methods
      3. IEEE Software Magazine V26n6(Nov/Dec 2009)pp60-63
      5. Reference a list [Hall90] of seven myths
      6. Formal methods are richer than in 1990.
      7. They are now used in requirements to get precision and understanding. They are embedded in tools and environments reducing the need for mathematical maturity.
      8. They enable communication and evolution and so support agility.
      9. An FSM model for understanding lead to better code.
      10. Must match the method to the problem cost-effectively.
      11. Formal methods are being domesticated.


      1. Nirmilt Desai & Amit K Chopra & Munindar P Singh
      2. Amoeba: A methodology for modeling and evolving cross-organizational business processes
      3. ACM Transactions on Software Engineering and Methodology V19n2(Oct 2009)pp6.1-45
      5. Amoeba::Method= iterate( roles and interactions; contractual relationships -> Commitments; message meanings->create and manipulate commitments; Constraints; compose protocols -> process model).
      6. Uses the idea of business protocols as modules. These have messages and resulting changes in the commitments between components. For example CC(VENDOR, BUYER, pay(price), ship(goods)) would result from a VENDOR sending a quotation(price, goods) message to a BUYER.
      7. Theory [DesaiEtal05]


      1. Bashar Nuseibeh & Charles B Haley & Craig Foster
      2. Securing the Skies: In Requirements we Trust
      3. IEEE Computer Magazine V42n9(Sep 2009)pp64-72
      5. Advice: Exploit the experts. Exploit nonexperts. Scope the problems. Iterate to mitigate. Formalize but also argue informally.
      6. Used [Jackson01] for architectural models. Used Toulmin to structure arguments and rebuttals.
      7. Security requirements derived from protecting assets and challenging assumptions exposed by form proofs.
      8. Outer arguments on cover hidden assumptions, inner arguments rebut assumptions and lead to mitigation strategies or revisions of requirements.

      2009-10-29 Thu Oct 29 19:40 Sociology trumps technology in solving problems


      1. Brian Whitworth & Tong Liu
      2. Channel E-Mail: A Sociotechnical response to spam
      3. IEEE Computer Magazine V42n7(Jul 2009)pp63-71
      5. Shows that some problems are not solvable by technology alone. Sociology plays a part in a real solution.

      2009-10-27 Tue Oct 27 19:55 Modeling tasks and Integration Requirements

      It is windy here in San Bernardino again. lights are flickering....

      Meanwhile, here are a couple of proposed techniques to use when developing software. First, Rich09, shows how to develop user interfaces by first modeling the tasks the users need to carry out. Then Bolloju09 gives a tested (in a graduate course) notation and method for specifying how different systems must behave and be connected to achieve an integrated system.


      1. Charles Rich
      2. Building Task-Based User Interfaces with ANSI/CEA-2018
      3. IEEE Computer Magazine V42n8(Aug 2009)pp20-27
      5. First model the task.
      6. Use an engine to guide the user.
      7. Questions asked by user during a task. What next? How do I? When should I? Why did you do that? What is needed? What is output? Did it work?
      8. Answers encoded into XML+JavaScript.
      9. Tools aid the writing of the XML and in it's interpretation.
      10. Property files.
      11. No reference to scenarios or use-cases!


      1. Narasimha Bolloju
      2. Conceptual Modeling of Systems Integration Requirements
      3. IEEE Software Magazine V25n6(Sep/Oct 2000)pp66-74
      5. Graph: Nodes represent subsystems and transformations. Arcs labelled with conditions and messages.
      6. Transformations: BATCH and SPLIT, AGGREGATE and DISTRIBUTE, X(translation).
      7. Uses <....> to indicate refined subsystem.
      8. Tested an 78 graduate students who found it usable.

      2009-10-21 Wed Oct 21 15:22 UML 3.0 or 2.4

      Jordi Cabot has posted the good news on the UML Forum [ http://groups.google.com/group/umlforum/ ] that the OMG is not going for UML 3.0 just yet. instead they may try to simplify the language. Jordi has this link [ reflections-on-the-omg-meeting-in-san-antonio.aspx ] for details on Steve Cook's WebLog.

      2009-10-20 Tue Oct 20 20:13 The Now looks like the Past

      It looks like we still have bugs in radiation machines [ http://www.wired.com/threatlevel/2009/10/gamma/ ] (Wired Oct 2009). We also still have a wide range of practices and their consequent qualities (CusumanoEtAl09). Finally we still don't evaluate projects and process improvements in terms of financial costs and benefits (Solingen09).


      1. Michael A Cusumano & Alan MacCormack & Chris F Kemerer & William Crandall
      2. Critical Decisions in Software Development: Updating the State of the Practice
      3. IEEE Software Magazine V25n6(Sep/Oct 2000)pp84-87
      5. Revisits [CusumanoMaccormackKemererCrandall03] showing a wide range of processes and qualities.
      6. One size does not fit all.
      7. Must choose a process to fit the situation.
      8. Distributed development gives rise to a more modular structure and needs special learning to pay off.
      9. A rigid process can give higher quality but at risk of loosing innovative products.


      1. Rini van Soligen
      2. A Follow-Up Reflection on Software Process Improvement ROI
      3. IEEE Software Magazine V25n6(Sep/Oct 2000)pp77-79
      5. refers to [Solingen04]
      6. Hardly any published work on the monetary value of improvements.
      7. Need to think in economic terms about projects.
      8. Money should win management commitment.
      9. Should adopt Six Sigma. No evidence.

      2009-10-19 Mon Oct 19 15:14 Bonus -- Programmers at work

      Jeff Atwood [ 001305.html ] is reccommending a couple of books which are well inside the scope of this blog. He also mentions a thord. I'd love to have time to read them and inwardly digest them before blogging them here. But I don't think I will have time for the next 10 months or so. Here are the citations with an invitation to send me your comments.


      1. Peter Seibel
      2. Coders at Work
      3. Apress 2009 ISBN 1430219483 [ 1430219483 ]
      5. Please send me your comments [ contribute.html ] to see them here.


      1. Susan Lammers
      2. Programmers at Work: Interviews With 19 Programmers Who Shaped the Computer Industry
      3. Tempus Books 1989 ISBN 1556152116 [ 1556152116 ]
      5. Parts online at [ http://programmersatwork.wordpress.com/ ]
      6. Please send me your comments [ contribute.html ] to see them here.


      1. Federico Biancuzzi & Shane Warden
      2. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
      3. O'Reilly Media 2009 ISBN 0596515170
      5. Please send me your comments [ contribute.html ] to see them here.

      2009-10-15 Thu Oct 15 20:51 Spending Money

      A couple of pieces on economics -- firstly on what people are spending IT money on and the other on why we pay what we do for things [Ariely09]


      1. Hoon S Cha & David E Pingry & Matt E Thatcher
      2. What Determines IT Spending Priorities
      3. Commun ACM V52n8(Aug 2009)pp105-110 [ 1536616.1536644 ] (Virtual Extension)
      5. Abstract
        1. "Based on survey results from 1,495 business leaders we have derived some important insights into how factors such as industry type, firm size, state location, and past IT performance affect a firm's allocation of IT expenditures across business functions. Specifically, the survey data shows that the highest IT spending priorities of the respondents are in the areas of administration and production and distribution while the lowest priorities are in the areas of R&D and security."

      2009-10-14 Wed Oct 14 10:52 Power cuts vs Grades

      It was raining in San Bernardino yesterday. This is a rare event. Indeed I am convinced that people in Southern California do not understand rain and tend to ignore it -- driving, designing roofs, etc. ... Hence my favorite movie "Singing in the Rain".

      Whatever... the power became flakey. A brief cut 9am yesterday knocked out out our DSL box and so my wife learned the dark art of rebooting it until it worked. When I got home.... I spent half an hour checking the network out, and another 30 minutes downloading and installing Microsofts mega-pack of updates.... and posted the entry below.

      I was just deciding whether to grade or to watch a DVD when the power went out. Total darkness..... Emergency lighting turned on (well 80% of it). The Elctricity company robot was told about it. Candles were found. Friends and nieghbors met and shared data.... And we collapsed into bed with no grading done.

      The power was back at 11:45 and I checked things out. I decided to not reboot the LAN until I knew the power was stable.... back to sleep.

      Got all systems operational this morning again.

      ANd that is why grades are not posted yet.

      2009-10-13 Tue Oct 13 20:05 Codefest

      First we have an article (Spinellis09b) listing all the things you can do to increase job security by producing incomprehensible code. Then Kode Vicious [ Neville-Neil09a ] explains how an organization can recover from sacking somebody who does this. The same prescription (code reviews) can stop the problem in the first case. Then we have (BrandtEtAl09) who present a case (exploratory prototyping)where badly written code is the norm. Finally, under the heading of why code anyway we have a book (MellorBalcer02) about making the UML into a complete and executable language. So who needs code? And who said that a picture was worth a thousand words?


      1. Diomedis Spinellis
      2. Job security
      3. IEEE Software Magazine V25n6(Sep/Oct 2009)pp14-15
      5. Excellent survey of things not to do if you want bad code.


      1. George V Neville-Neil (Kode Vicious)
      2. Kode reviews 101
      3. Commun ACM V52n10(Oct 2009)pp28-29 [ 1562746.1562778 ]
      5. How to learn about others code.
      6. Must be prepared for. Piece of the code assigned to each for study.
      7. Do not schedule after just lunch.
      8. Provide coffee+food
      9. Keep the focus. Do much more than nitpicking the spelling and syntax.
      10. Take notes. And afterwards distribute.
      11. Follow up.
      12. Use a tool to track code reviews and followup work. Example Rietveld.


      1. Joel Brandt & Philip J Guo & Joel Lewenstein & Scott R Klemmer & Mira Dontcheva
      2. Opportunistic Programming: Writing code to prototype, ideat, and discover
      3. IEEE Software Magazine V25n6(Sep/Oct 2000)pp18-24
      5. Principles for rapid prototyping
        1. Glue together existing high-level components.
        2. Add functionality via Copy-paste from the web.
        3. Iterate rapidly.
        4. Consider code to be impermanent.
        5. Expect and prepare for debugging.
        6. Use many languages.
        7. Don't expect good code.
        8. Need different version control.


      1. Stephen J Mellor & Marc J Balcer
      2. Executable UML: A Foundation for Model-driven Architecture (2nd Edition)
      3. Addison Wesley 2002 ISBN 0-201-74804-5 [ 0201748045 ]
      5. Updates the ShlaerMellor Methods to use the UML. [ShlaerMellor88] [ShlaerMellor89] [ShlaerMellor92] [ShlaerMellor97] to use the UML.
      6. Comments wanted [click here [socket symbol] if you can fill this hole]

      2009-10-12 Mon Oct 12 15:01 Contribution on Pompeii

      My name is Katie, I am a history major and was doing some research on Pompeii when I came across your page. I noticed that on [ Pompeii in info4 ] you link to http://jefferson.village.virginia.edu/pompeii which seems to be broken. If you are interested in a replacement, I found a site that has some great information and resources on Pompeii and its destruction that would make a nice addition to your page: [ destruction-of-pompeii.html ] http://www.travelinsurancereview.net/Travel-Facts/destruction-of-pompeii.html

      2009-10-11 Sun Oct 11 09:33 Good Concert Last Night

      The 81st season of the San Bernardino Symphony [ symphony.html ] started last night with an excellent evening of entertainment.

      2009-10-08 Thu Oct 8 20:47 Hard problems and practical solutions

      Apparently the existence of problems that (apparently) can not be solved in polynomial time, even though the solutions can be checked in polynomial time is attracting some attention due to the following survey. Following it is an example of this kind of problem and the best practical algorithms to solve it.


      1. Lance Fortnow
      2. The status of the P versus NP problem.
      3. Commun ACM V52n9(Sep 2009)pp78-86 [ 1562164.1562186 ]
      5. "What we would gain from P = NP will make the whole Internet look like a footnote in history."
      6. "Since all the NP-complete optimization problems become easy, everything will be much more efficient. Transportation of all forms will be scheduled optimally to move people and goods around quicker and cheaper. Manufacturers can improve their production to increase speed and create less waste."
      7. probably P<>NP. But no proof yet.
      8. Quantum computers probably won't do it.
      9. For practice see [MalikZhang09]


      1. Sharad Malik & Lintao Zhang
      2. Boolean Satisfiabiliy -- From Theoretical Hardness to Practical Success
      3. Commun ACM V52n8(Aug 2009)pp76-82 [ 1536616.1536637 ]
      5. Theory calculates the worst case performance.
      6. SAT solvers rely on the typical case (in a given domain) is not the worst case.
      7. The Davis Putnam Logeman Loveland algorithm with optimizations gives a usable tool.
      8. See [Fortnow09] for the theory.

      2009-10-06 Tue Oct 6 19:56 Empirical research in Agile methods

      As noted previously, agile processes are not a new idea but they are growing in popularity. Here is a survey of the published literature that provides scientific evidence of the good and bad properties of these methods. For more information search my bibliography for the tag "AGILE".


      1. Tore Dyba & Torgeir Dingspoyr
      2. What do we know about agile software development
      3. IEEE Software Magazine V25n6(Sep/Oct 2009)pp6-9
      5. Agile processes can improve customer satisfaction, productivity and job satisfaction.
      6. They can be difficult to introduce into a large organization.
      7. Being the onsite customer is stressful and hard to sustain.
      8. A Team needs a strong focus on both the interpersonal and the team goals.
      9. Skill and experience helps.
      10. May not be the best approach for large projects.
      11. Need more research.

      2009-10-06 Tue Oct 6 10:48 Bonus Blog

      Frank P. the web master of Web Talk [ http://www.webtlk.com/ ] contributed his own blog as a back link ... good for news about hardware and software. It is permanently embedded at [ samples/people.html#Blogs ]

      2009-10-01 Thu Oct 1 20:17 Better bookmarks for Eclipse

      The following describes an extension of Eclipse bookmarks and its testing on some live projects.


      1. Margaret-Anne Storey & Jody Ryall & Janice Singer & Dei Myers & Li-Te Cheng & Michael Muller
      2. How Software developers use tagging to support reminding and refinding
      3. IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp470-483
      5. Notes that Eclipse user don't use the bookmark feature very often.
      6. Provided a light weight plugin to Eclipse to organize the markup of code (in comments) into an easy to access hierarchy.
      7. Some evidence that this approach is better than book marking at setting reminders and finding things later.

      2009-09-29 Tue Sep 29 20:14 About Code Quality

      First evidence that the quality of Open Source code is improving, then a tool that helps you improve the quality of code by refactoring.


      1. Chris Kanaracus
      2. Study Shows improvements in quality of open source code
      3. Info world (Sep 23 2009) [ study-shows-improvements-in-quality-open-source-code-950 ]
      5. "In survey commissioned by Department of Homeland Security, Samba, tor, OpenPAM, and Ruby granted top-level status for resolving defects"
      6. Data collected at [ about.html ]


      1. Nikolaos Tsantalis & Alexander Chatzigeorgiou
      2. Identification of move method refactoring opportunities
      3. IEEE Trans Software Engineering V35n3(May/Jun 2009)pp347-367
      5. JDeodorant::= See http://www.jdeodorant.org/ , 2007.

      2009-09-28 Mon Sep 28 13:01 Small Change in weekly schedule

      I've decided to plan an earlier lunch. See [ plan.html ] for the new schedule.

      2009-09-24 Thu Sep 24 19:18 For the weird languages file

      Here are three references to weird languages: Boogie, Spec#, and Scratch -- all described or demoed on the web. To be more precise Boogie is a tool, Spec# is a specification language, and Scratch is a integrated Development environment for children to use on the "One Lap Top Per Child" system. Scratch also demonstrates an application of the Open Source principle of shared code -- even if the code has a heavy graphic component.


      1. Microsoft Research
      2. Boogie -- The World's Best Program Verification System
      3. Web site Aug 27th 2009 [ http://boogie.codeplex.com/ ]
      5. "Boogie is a program verification system that produces verification conditions for programs written in an intermediate languagec (also named Boogie). The intermediate language is easy to target from source languages such as Spec#, C#, or even C."


      1. Microsoft Research
      2. Spec#
      3. Web site Aug 28th 2009 [ specsharp ]
      5. "Spec# is a formal language for API contracts (influenced by JML, AsmL, and Eiffel), which extends C# with constructs for non-null types, preconditions, postconditions, and object invariants. Spec# comes with a sound programming methodology that permits specification and reasoning about object invariants even in the presence of callbacks and multi-threading. Spec# is a research vehicle that has been used to explore specifications and the dynamic/static tools that make use of them."


      1. MIT One Lap Top Per Child
      2. Web site [ http://scratch.mit.edu/ ]

      2009-09-24 Thu Sep 24 10:32 Bonus -- Online magazine on methods and tools


      1. Martinig and Associates
      2. Methods and Tools
      3. Web page [ http://www.methodsandtools.com/ ]

      2009-09-22 Tue Sep 22 18:55 Prehistoric agility

      This continues the series of early (rediscovered) publications describing or advocating what are now called agile processes. This Schorr77 didn't have much impact because it was in IEEE Computing magazines "Open Channel" section which would publish anything from anyone (example me).


      1. Peter Schorer
      2. The Open Channel
      3. IEEE Computer magazine V10n8(Aug 1977)pp70-71 doi:10.1109/C-M.1977.217827
      5. Early description of an agile process.
      6. A Question to ask in interaction design: What other information does a user need to know to use the new system?

      2009-09-17 Thu Sep 17 20:11 Bugs Faults Defects and Failures

      Lets talk about bugs. Now, informally we use bug to indicate bad behavior and the cause of that behavior. So, First, a more precise terminology. A failure is a misbehavior in some software. A fault is the thing inside the software that is wrong. Another term for this is defect. The defect density is the number of defects in a piece of code divided by the size of the code. Now, when we look at the record of the development or maintenance of software we can not see the faults all we have a record of, is the fixes -- the changes made to attempt to fix the problem behavior. Hatton09 present some empirical data and a theory that says the defect density increases as the logarithm of the size. This means that the number of faults/defects in a piece of code of size n (lines of code) will have a number of defects proportional to
    13. n* log(n)

      HamilPopstojanova09 provide data that normally a single failure needs fixes in several places.

      Finally, Schrock09, shows how to instrument Ajax code so that you can diagnose the bugs that emerge with a parallel system. How else to debug a complex asynchronous system with minimal support from the platform like in AJAX?


      1. Les Hatton
      2. Power-law distributions of component size in general software systems
      3. IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp566-572
      5. Theory and data show that defect density(defects/line) in a stable software system is proportional to the logarithm of the number of lines of code in that module.
      6. However see [Zhang08] that claims a Weibull distribution is better.


      1. Maggie Hamil & Katerina Goseva-Popstojanova
      2. Common trends in fault and failure data
      3. IEEE Trans Software Engineering V35n4(Jul/Aug 2009)pp484-496
      5. One failure is fixed by changes in more than one file 60% of the time. More than 2 files, 30% of the time.
      6. Pareto principle: 20% of the files contain nearly 80% of the fixes in GCC. 47% of the files have 100% of the fixes.
      7. NASA groups files into configuration items. 90% of failures lead to fixes within one item.
      8. main reasons: 30% requirements, 25..30% coding, 15% data, ...
      9. interactions cause problems.


      1. Eric Schrock
      2. Debugging AJAX in Production
      3. Commun ACM V52n5(May 2009)pp57-60 [ 1506409.1506423 ]
      5. Write wrapper function that puts a try block arround calls!
      6. Generate stack traces!
      7. Etc.

      2009-09-10 Thu Sep 10 17:53 Keeping systems simple by trusting people

      It appears that Craig's List works despite breaking a lot of rules that seem to be true. For example -- trusting people to make contributions with little oversight. Quite different to Shirky's theory. Very like the difference between "Theory X" and "Theory Y" as held by managers.


      1. Gary Wolf
      2. Why Craigslist is such a mess
      3. Wired V17n9(Aug 22 2009) [ ff_craigslist ]
      5. Part of a set of articles on Craigslist [ http://www.craigslist.org ] that trace the design of a web-based system to the culture and vision of the enterprise that develops it.
      6. Interviews with the founder Craig Newmark and CEO/Chief Programmer Jim Buckmaster about Craigslist.
      7. See also "The Craigslist Credo: Unbrand, Demonetize, Uncompete" [ craigslist-credo-unbrand ] and "Extreme Makeover: Craigslist Edition" [ ff_craigslist_makeover ]
      8. Quote
          The axioms of this worldview are easy to state. "People are good and trustworthy and generally just concerned with getting through the day," Newmark says. If most people are good and their needs are simple, all you have to do to serve them well is build a minimal infrastructure allowing them to get together and work things out for themselves. Any additional features are almost certainly superfluous and could even be damaging.

      9. Compare [Shirky03] which assumes their are vandals who will wreck a web site.

      2009-09-08 Tue Sep 8 19:36 On the Importance of distance

      Before I get to the topic of the day (how distance doesn't matter any more) here is a word from my sponsor The following student project presentations will take place in JB 359 on Wednesday, Sept 9.
      1. 2:30 -- My Work on Mythic -- John Heim
      2. 3:00 -- Mythic -- Scott Young
      3. 3:30 -- Java Web Programming -- Eyob Zelke
      4. 4:00 -- Joomla Website -- Atip Siripat
      5. 4:30 -- Central Content Management System -- Raul Tabares

      Details in [ seminar/ ]

      This afternoon I attended the Ph. D. thesis defense of one of our alumni -- Allan Knight. He set it up using "GotoMeeting"/"GotoWebinar" and so I didn't have to leave home (in San Bernardino) to go to Santa Barbara where the presentation took place. The whole thing went as planned. Details below in Knight09. Which leads me to another example of the distance not being an obstacle.


      1. Christian Bird & Nachiappan Nagappan & Premkumar Devanbu & Harald Gall & Brendan Murphy
      2. Does Distributed Development Affect Software quality? An Empirical Case study of windows Vista
      3. Commun ACM V52n8(Aug 2009)pp- [ 1536616.1536639 ]
      5. Little evidence that having a team spread over two continents gives worse code than being in the same building.
      6. Size of team does have an effect.
      7. (dick)|-They did not check to see if the distributed team compensated for distance be special processes or tools.


      1. Allan Knight
      2. Facilitating the integration and impact measurement of technologies and media that augment learning environments
      3. Thesis Defense CSci UCSB(Sep 8th 2009)
      5. New devices, social media, and connectivity.
      6. Turning up in classrooms. Opportunities or distractions in the classroom?
      7. Stakeholders: teachers + students + researchers.
      8. |-We can create computer systems that facilitate integration of the new into the learning as well as support research.
      9. Four projects: DeCAF(event streams/producers/consumers), AutoCap(captioned audio), DataCafe(research data), PAIRwise(Plagiarism)
      10. Lessons learned:
      11. (DataCafe): relational database didn't scale. Flatter files fast enough. Interface difficult to use.
      12. (PAIRwise): Evolved in purpose and implementation. Installation simplified. Initial version fragile.

      2009-09-04 Fri Sep 4 07:11 location location location

      I've just updated the next entry on the importance of locating data in the right place when speed is important.

      2009-09-03 Thu Sep 3 17:11 On the Persistence of Memory Performance Issues

      This blog is about linking things that I've known about for decades to the latest and newest publications.

      One persistent issue is how fast you can get access to data in a computer system and the Physical Design of Databases. Back in the late 1970's I taught the SSADM method in England ( [DownsClareCoe8792] [Hares90] [RobinsonBerrisford94] ) and we had a specific step to fit the logical design (normalized and relational) to (1) the quirks of the database management system and then to make sure that the system was fast enough. You might think that these issues would go away as disks became larger and faster. But no! In [PechuraShoefler83] we have a paper that gives formulas for calculating the times it takes to read and write data to disk -- prime rule: sequential access is still faster than random access. I used their formulas, in [Botting88] to disprove some classic Big-O results taught in data structures classes. For example, the time read all the data in a large disk file is not O(n) but O(n^2) for large values of n! In 1993, Jim Bentley [Bentley93] demonstrated the power and technique of do-it-yourself caches. Then we have, in 2001, [Armstrong01] on optimizing data warehouses -- and making the same points. By 2004, [Alsaadi04] used UML to denormalize data to speed up a program. Last year [KunkleCooperman08] demonstrated solving Rubik's Cube using a cluster of disks to simulate a very large Random Access Memory, and concluded that you still had to avoid random access by using sorts and caching.

      For 30 years the same lesson: the physical location of data is a vital component for determining performance. All that has changed is the size of the data set that is needed to slow down the software to the point of the users/stakeholders complaining.

      In the August 2009 issue of the Communcations of the ACM we have the same ideas -- resulting from experience with large data:


      1. Adam Jacobs
      2. The pathologies of big data
      3. Commun ACM V52n8(Aug 2009)pp36-44 [ 1536616.1536632 ]
      5. "It is easier to get data into a large database than get it out."
      6. "To achieve acceptable performance[...] one must be willling to consider abandoning the purely relational database model."
      7. "As dataset sizes grow, it becomes increasiingly important to exploit the efficiency of sequential acces[...]"
      8. Problems with arbitrary limits.
      9. Discusses distributed data bases.
      10. Tradeoffs between fast access and duplicated data.

      2009-09-02 Wed Sep 2 09:38 Two Reviews published -- CORBA and Montanari

      I write reviews for "Computer Reviews" (CR below). Two have been published in hard copy. They have these two [DeganoEtAl08] [Henning08] items in my bibliography.

      2009-09-01 Tue Sep 1 19:17 More on Google MapReduce

      Here is a more formal description on the MapReduce architecture... which let me update the MATHS definition in the item linked below:


      1. Ralf Lammel
      2. Google's MapReduce programming Model -- revisited
      3. Science of Computer Programming V70n1(Jan 2008)pp1-30 CR 0908-0758 doi:10.1016/j.scico.2007.07.001
      5. See first [DeanGhemawat08]

      2009-08-27 Thu Aug 27 18:50 Plans plus Cliches

      I've spent the last week or so working up my plans for the coming quarter..... including a 10% reduction in pay and work. I guess that it will be best if I shift the posting of items to this blog to Tuesday and Thursday evenings. To start this new schedule: here is a light piece listing some management cliches and some possible ripostes:


      1. Phillip G Armour
      2. the business of software: the cliche defence
      3. Commun ACM V52n7(Jul 2009)pp34-36 [ 1538788.1538802 ]
      5. Do it right the first time. But.... Quote: "much of the business of software involves the discovery of what we are supposed to be doing".
      6. Work smarter not harder.
      7. Quality is the most important thing. But.... Which quality?
      8. Our customers are the most important thing. But.... Which customers? What about future extensions and the people who work on them?
      9. Our people are the most important thing. But... are they supported?

      2009-08-26 Wed Aug 26 08:13 Business Links plus Respect in Software Development

      First a note about my earliest web pages. They were set up, using HTML, using the "Information superhighway" as a metaphor. They have a true miscellany of links. The were used in my department's CSci127 course in the 1990s. A representative of LexisNexis has asked me to add links to some of their services to businesses. This [ info4.html#LexisNexis ] is the result.

      I am thinking it may be time to recode all of the "info" pages on this site to use the same MATHS language as this page. But I need to think about this change, and where the resulting sample should end up. As always let me know what you think.

      And now for something completely different.... Actually there is a link. My work on "info4" is not very scientific, and it is not engineering. It is more a craft than anything else. Here is a contribution on the long running discussion of whether programming is a form of engineering. More important is the importance of respect as a driver of the qualities of software development


      1. Neville Holmes
      2. Agility and respect
      3. IEEE Computer Magazine V42n7(Jul 2009)pp100+98-99
      5. Programming is a talent. Engineers should respect it. Programmming is a separate trade to engineering.
      6. Development should focus on providing services to the enterprise not on projects.
      7. A computer professional must be more than an expert on the technology.
      8. Respect users by empowering them rather than programming them.
      9. Also see keynote at ASWEC2009 [ http://eprints.edu.au/ ]
      10. (dick)|-Many programmers are craftspeople.
      11. (dick)|-CASE tools did not change this, will model-driven tools?

      2009-08-24 Mon Aug 24 10:30 How to be sure you have a good architecture -- Review it

      Continuing the serires of Software Quality Control techniques, here we have a study of the use of a well known technique -- technical reviews -- as applied to high level design decisions that attempt to tackle requirements.


      1. Muhammad Ali Babar & Ian Gorton
      2. Software Architecture Review: The State of Practice
      3. IEEE Computer Magazine V42n7(Jul 2009)pp27-32
      5. Excellent summary of ways of ensuring design quality and addressing architectural concerns -- not all of them popular.
      6. Common techniques: Scenarios, Experience, and prototyping. Less common: check lists, metrics, simulation, questionaires, mathematics
      7. Documenting architectures: modeling notations, views, features, assumptions and constraints, ...
      8. Inputs: (commonest first) requirements, descriptions, business drivers, standards, ...
      9. Stakeholders -- various

      2009-08-21 Fri Aug 21 08:21 A little lite mathematics

      How do we get highly reliable software? One approach to improving reliability is to use mathematics and logic in the design and review. There are a couple of examples posted previously -- a compiler and a kernel for an operating system. Here are a couple of books on mathematics that should be worth reading.

      I've read Stewart06 and wish that I had read it 40 years ago when I was a young mathematician. Some of the chapters present a different view of proof to the one I have documented on this site ( [ maths/logic_20_Proofs100.html ] [ maths/logic_25_Proofs.html ] ). He argues that mathematical proof are stories. In this site I've documented something close to Lamport's [Lamport95] idea of a proof. My hope is that using hypertext we can get the benefits of both concepts. One can be given a high-level story describing why something is true and embed in it links to the detailed steps that link make up the formal (and checkable) proof.

      The other book (StepanovMcJones08 below) was on the math-thinking mailing list and looks very interesting. It connects the kind of algebraic properties that I've documented in this site to the construction of C++ code. I've ordered it and hope to post a detailed opinion later.... meanwhile if you have read it, I would love to know what you think so I can post it here and in my bibliography.


      1. Ian Stewart
      2. Letters to a Young Mathematician
      3. Basic Books Cambridge MA 2006 ISBN 0-465-08231=9
      5. Suggests that mathematical proofs (not formal ones) are stories.
      6. Good examples. Few formulas. Good advice. School...college...grad...faculty.


      1. Alexander Stepanov and Paul McJones
      2. Elements of Programming
      3. Addison-Wesley Professional 2009 ISBN 0-321-63537-X [ book.html ]

      5. Please send me any comment: [click here [socket symbol] if you can fill this hole]

      2009-08-19 Wed Aug 19 14:53 Empirical Software Engineering

      How can we get reliable information about a topic? There are a family of approaches that are called Empirical which look to data gthered about the subject -- experiments, experiences, observations, statistical analysis, etc. Empirical methods are closely associated with scientific methods. Sometimes you will meet people who talk about the scientific method -- but if you check the history you will find several varieties. The Wikipedia article [ Scientific_method ] on the history of the scientific method provides a very good survey of empirical methods. People are applying the to understanding software development.

      I have been tagging the entries in my bibliography of software engineering -- nearly 5,000 of them now. Here is a list of the tags from the most empirical (reliable) to the least:

      1. =EXPERIMENT -- an artificial set up designed to evaluate a specific set of hypothesis -- may not apply to real projects
      2. =EXPERIENCE -- collected for real software development projects -- may be biased and/or unrepeatable
      3. =OBSERVATION -- the researcher observes real projects -- may be biased and/or unrepeatable
      4. =EMPIRICAL -- mixtures of the above

      5. =SURVEY -- reports on the literature
      6. =DEMO -- exhibits a working piece of software and the techniques and methods used to develop it
      7. =POLL -- data collected from people, opinions, probably biased, ...

      8. =THEORY -- Defines terms, postulates assumptions and proves results.
      9. =ESSAY -- a balanced review of a topic or belief, but little in the way of data
      10. =ANECDOTE -- writer appears to believe it but can't prove it

      11. ...
      12. =ADVERT -- no proof or data, just arguments in favor of something, including papers about theses that quote results proven in the thesis.
      13. =POLEMIC -- strong arguments designed to make the author feel better.... but no data.

      The first four are empirical. Mark Doenhoefer's column (below) has a comprehensive survey of web sites relevant to the empirical study of software development.


      1. Mark Doernhoefer
      2. Surfing the net for software Engineering notes -- Empirical Software Engineering
      3. ACM SIGSOFT Software Engineering Notes V34n3(Jul 2009)pp4-16 [ 1543405.1543409 ] (PDF)
      5. Links to Journals, Groups, Courses, Conferences all concerned with gathering data and fitting theories to software development.

      2009-08-17 Mon Aug 17 15:47 Inspections find defects

      A recent experiment and observation of software inspections -- where a group gathers to review code and look for particular problems in the code -- confirms an observation made in 2002 [Votta02] that given modern software development tools most of the discovered defect decrease the quality of code without damaging the functionallity.


      1. Mika V Mantyla & Casper Lassenius
      2. What types of Defects are Really Discovered in Code Reviews
      3. IEEE Trans Software Engineering V35n3(May/Jun 2009)pp430-448
      5. Experiment done on students. Backed up with obsrvations of a company.
      6. Inspections done after code has been run.
      7. Most (60%) of discovered defects do not effect the functioning of software but might make the code harder to understand or change.

      2009-08-14 Fri Aug 14 10:36 Program Proving is alive

      Previously, I noted the existence of a proved compiler for a large subset of C. Now comes news -- from Dr. Dobbs Update - 08/13/09 - Yes, 100% Verifiable Bug-Free Code Is Possible. Jonathon Erickson reports that OK Labs [ http://www.ok-labs.com/ ] have completed the verification of the corrrectness, reliability, and security of their microkernel. SOmething I did on a much smaller and simpler system nearly 40 years ago....

      2009-08-12 Wed Aug 12 07:35 Mathematical Diversion republished in Book

      Brian Hayes writes an excellent series of articles in "The American Scientist". Some of these have been republished in a book. This encourages me to add the article on the common forms of data encoding to this bibliography.


      1. Brian Hayes
      2. Group theory in the bedroom, and other mathematical diversions
      3. Hill and Wang NY NY 2008 ISBN 0-8090-5219-9
      5. Reprints
          The Easiest Hard Problem [HayesB02]
        1. Naming Names [HayesB05]
        2. and other good articles


      1. Brian Hayes
      2. Naming Names
      3. American Scientist V93 (Jan/Feb 2005) and republished in [HayesB08]
        1. Internet account IDs
        2. NY Stock Exchange Ticker Symbols -- up to 3 Uppercase letters -- 26+26**2+26**3 possible
        3. Universal Product Codes -- bar codes -- ( UPC )-- 12-digit until January 2005, and then 13-digits.
        4. Global Traded Item Numbers (GTIN)
        5. European Article Numbers (EAN)
        6. Biological Species -- Two Latin-like words
        7. The Chemical Elements -- One uppercase letter + option lower case letter. (I had to program these while working for ICI in the 1960's)
        8. Organic Chemicals -- Complex coding.
        9. Internet Assigned Number Authority IANA names for countries -- two ASCII letters
        10. Radio Call Signs -- 3..4 Capital letters -- KVCR, KFROG, ...
        11. Telephone numbers -- 10 digits (in the USA).
        12. Social Security Numbers -- 9 digits in the USA
        13. Airport codes (IATA) -- Three letters.
        14. Names of Horses -- 2..18 characters ( letters plus space, period, and apostrophe).

      2009-08-10 Mon Aug 10 10:55 Finnegans Wake

      It is said that the party for the dead Finnegan was so good that the corpse got up to join in. Here we have a couple of technologies/techniques -- Program Proving and COBOL -- that have been pronounced dead many times, and yet keep showing signs of life.


      1. Jeff Atwood
      2. COBOL: Everywhere and Nowhere
      3. Coding Horror (Aug 9 2009) [ 001294.html ]


      1. Xavier Leroy
      2. Formal Verification of a realistic compiler
      4. Commun ACM V52n7(Jul 2009)pp107-115
      5. Shows that a useful subset of C can be compiled in real and efficient assembler code by a compiler that has been proven correct -- with the proofs checked by tools.

      2009-08-07 Fri Aug 7 15:39 Jackson Structured Programming and Structures Design

      In the previous but one posting [ Maibaum09 ] I mentioned JSP (a form of Data Directed Design or DDD) and JSD(a form of Dynamic Analysis and Design or DAD) that dates back 3 decades. Bo Sanden has has just published a personalized history of these methods which explains these constructive methods. My own thoughts can be found in [ monograph/ ] [ samples/methods.html#JSP ] [ samples/methods.html#JSD ] on this web site. Bo Sanden suggests that multithread programs need each thread to track a realistic entity with a State Machine model.... something that slots straight into the UML as a active object.


      1. Bo Sanden
      2. Inspired software design early Jackson methods to thread architectures
      3. SIGSOFT Softw. Eng. Notes V34n4 (Jul. 2009), pp1-6 [ 1543405.1543423 ]
      5. cf ELM in [Sanden03]
      6. Students found JSP too difficult.
      7. However, making each thread implement/follow a single entity's life history -- expressed as state diagram is OK with students.

      2009-08-05 Wed Aug 5 11:21 Open Source and Crowd Source

      The last 10 years have had a lot of studeis made of the open source techniwue -- a technique dating back to software distributed in the early part of the 20th century. It is clearly a viable technique to develop some kinds of software. The later technology of crowd sourcing -- examples: wikipedia and YouTube -- has also been studied more recently -- tho' again the development of FAQ listings on UseNet (AKA Google Groups) is an early incarnation. So first I will list some significant papers and books on the topic and then a proposal for setting up an effective open/crowd sourced project. This summarizes best practices into a a process with principles and implications.


        [Grier06b] (history)

        1998 [Keuffel98] 1999 [O'Reilly99] [Raymond99b]

        2000 [MockusFieldingHerbsleb00] 2001 [FellerFitzgeraldHoek01] 2002 [DempseyWeissJoneGreenberg02] [MockusFieldingHerbsleb02] 2003 [Glass03b] [Shirky03] 2004 [Fitzgerald04] [Lussier04] [ThomasHunt04b] 2005 [Dinh-TrongBieman05] [Weber05] 2006 [DamianiEtal06] 2007 [Nov07] [Aberdour07] [DuenasEtAl07] [PetrenkoEtAl07] 2008 [Campbell-Kelly08] [CapraFrancalanciMerio08] [Huberman08] [Laplante08] [Shirky08] 2009 [Lawton09]


      1. Rick Kazman & Hong-Mei Chen
      2. the metropolis model -- a new logic for development of crowsourced systems
      3. Commun ACM V52n7(Jul 2009)pp76-84 [ 1538788.1538808 ]
      5. CBSS::="community-based service systems", following
        1. not producing goods for consumption. Not centralized.
        2. open teams.
        3. Mashability -- reuse.
        4. conflicting, unknowable requirements -- discover by doing, emergent. Continuous evolution.
        5. Focus on operations. Start with a working system and aim for no downtime.
        6. Sufficient correctness. Perpetual Beta.
        7. Unstable resources -- many parallel prosumers.
        8. prosumer::= produce & consumer.
        9. Emergent behavior. Nondeterministic.

        (End of Net)

      6. metropolis_model::onion=kernel+periphery+masses.
      7. principles:
        1. crowd management>project management.
        2. promotion through ranks, attracting developers, meritocracy.
        3. split kernel services from peripheral services.
        4. pernipheral work is done by crowdsourcing, kernel by higher ranked developers.
        5. ubiquitous operations even as it evolves.

      8. implications: no phases, align business to crowd, not control but lead, tutorials and examples, usability. Requirements come from the periphery, forums help but can be shortcircuited. Architecture vital core. Small modular kernel. Tools for Testing, bug reporting and tracking. Flexible delivery. High availability.

      2009-08-03 Mon Aug 3 10:13 Engineering and Formal Methods

      Engineering often has a scientific research part -- figuring out how the real world works, and testing out untried technology/algorithms. But standard engineering relies on cookbooks recipes and formulas for designs and qualities. Maibaum09 (below) reports that those methods that are labelled "formal" have not produced any cookbooks. However he does not note the "cookbook" methods that evolved from theory before the "formal methods movement" started -- DAta Directed Methods, Compiler design, Data base design, etc.. He also omits to mention the theoretical obstacles to developing tools and calculations and those tools that are on the market or being taught -- model checking -- for example.

      However he refers to a book that seems highly relevant (Vincenti90). He could also refer to Henry Petrosky's corpus on what engineers do, and how they fail.


      1. Tom Maibaum
      2. formal methods versus engineering
      3. ACM Inroads & SIGCSE Bulletin V41n2(Jun 2009)pp6-12

      5. Quotes Vincenti90 and MAJackson
      6. Engineers need standard cookbook methods and calculations suited to specific kinds of problems.
      7. Fails to mention DDD(JSP, compilers, database, JSD, SSADM etc), Model checking ( SMV Alloy etc.)
      8. Does not discuss the intractability and/or unsolvability of the problem of calculating consequences of requirements.
      9. Implies that given pre/post conditions the code can be generated automatically -- but actually the engineer needs to supply internal invariants, structures, and non-functional requirements to determine the best design for code.
      10. More on the scientific basis for software negineering [ JuristoMoreno02]


      1. Walter G Vincenti
      2. What Engineers know and how they know it
      3. Johns Hopkins UP 1990
      5. notes [click here [socket symbol] Vincenti90 if you can fill this hole]

      2009-07-31 Fri Jul 31 08:17 Life and death of software engineering

      Another view of software engineering -- as a controled, measurable, and pre-planned process -- bites the dust (DeMarco09). Here we have a pundit retreating, in public, from a fragile process and a glad response. Independently, people at the Simula lab have explored the predictability of software development -- 4 independent outsourced implementations of the same set of requirements -- with varying results. Evidence that we do not have a controlled process.

      My belief One size does not fit all -- only some projects are engineering projects -- there exist niches where "engineering" is not the ideal way to develop something. And many projects are best developed incrementally, growing the functionality while maintaining the quality.


      1. Tom DeMarco
      2. software engineering: an idea whose time has come and gone
      3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp96+95 =ESSAY PROCESS CONTROL METRIC ESTMATING PLANNING 1982 book tried to control too much.
      4. Only marginal projects need tight control.
      5. Better to ask for incremental growth to better and better systems until time runs out.


      1. Jeff Atwood
      2. software engineering dead?
      3. coding horror blog (jul 18 2007) [ 001288.html ]
      5. surprised by [DeMarco09]
      6. Quote
          And yet, it's also a release. It's as if a crushing weight has been lifted from my chest. I can publicly acknowledge what I've slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.


      1. Bente C D Anda & Dag I K Sjoberg & Audris Mockus
      2. variability and reproducibility in software engineering: a study of four companies that developed the same system
      3. IEEE Trans Software Engineering V35n3(May/Jun 2009)pp407-429
      5. Sent out call for bids -- 34 responses, 4 selected -- to develop a web application in Scandinavia. Prices range from 2k Euros to 70k Euros!
      6. Many variables, no trustworthy hypotheses to test. Exploration.
      7. Concluded that only the usability was similar between 4 competing projects. The reliability, time to produce, size, and maintainability all varied between companies. There was evidence of a trade off between price and quality.

      2009-07-29 Wed Jul 29 09:26 Economics killed web consulting

      Continuing the "postmortem" series of example of software development failing and the non-technical reasons for the failure....


      1. Joel Spolsky
      2. The Day my Industry Died
      3. Inc. (Jul 1st 2009) [ joel-spolsky-the-day-my-industry-died.html?partner=fogcreek ]
      5. The growth and death of web consulting 1990-2001

      2009-07-27 Mon Jul 27 08:58 Techniques for improving Requirements

      First a clarification -- Interaction Design should not be considered as part of designing the structure, architecture, or code of software. When programmers design interactions they design for control freaks and geeks. See Alan Cooper's writing. Instead the design of the interaction between humans and actors is best treated as specifying requirements that the code will have to meet. Setting a challenge for the programmer/designer to meet. The reading for today points to two techniques that clarify these requirements: The analogy and the "black-hat session".

      The theme of the last four of five items has been how focussing on the technology rather than the real world and existing systems can cause problems. Today's item gives examples of techniques to uncover these problems early.

      Note most of my development work -- for example this web site -- has done it wrong by searching for the sweet spot where technology meets usability.


      1. Jeff Patton & Leah Buley
      2. Leah Buley: toward collaborative, pragmatic user-experience work
      3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp93-94
      5. Clarify your design principles: If this was a animal/place/food/... what would it be. Generates non-functional requirements, and clarifies the vision for a project. Provides guidance when designing interactions.
      6. Use black-hat sessions to collect criticisms.

      2009-07-22 Wed Jul 22 13:48 Postmortem -- A Technique that avoided requirements

      Here is another example of the kind of technical thinking that can make sure that the stakeholders' requirements are not met. The article is funny. It is a joke. It satirizes a bad practice. But it does record a technology that I loved -- stencils and flow-charts.


      1. Colin Codephirst (alias) & Nail Maiden (ed)
      2. Where have all the stencils gone?
      3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp
      5. Technique was easy and fun to use, impressed the stakeholders, and contributed little to understanding the problem.
      6. Compare [Codephirst07]

      2009-07-20 Mon Jul 20 17:12 Continuing the postmortem -- Domain specific worst practices

      Previously we had a description of a case study where an unexpected combination of circumstances coast a company a lot of money. It is a pity that is easy to prove that finding such combinations is time consuming... or even impossible. Given a sufficiently complex set of formal requirements we know that there will be properties that can not be proved or disproved.... but which will be true -- Goedel's Theorem. And finding such "antics" is at leat NP complete in simple cases, and uncomputable in general. I teach more abour analysing rules in my classes: CS372, CS556, and CS656.

      Even so, it is a pity that developers do not spend more time thinking outside the computer. And here is another paper that points in this direction.

      Part of the IEEE Software Magazine V26n4(Jul/Aug 2009) special issue on domain specific languages and modeling. Some of the articles and papers are more about what goes on inside the software -- the Solution Domain rather than the users, stakeholders, etc that are in the Problem Domain (outside the software). One paper observes that most domain models are not based on the reality and the existing systems but on the existing or planned software.

      So here are some recommendations based on experience.


      1. Steven Kelly & Risto Pohjonen
      2. Worst practices for domain-specific modeling
      3. IEEE Software Magazine V26n4(Jul/Aug 2009)pp22-29 =EXPERIENCES 76 CASES DOMAIN MODELS LANGUAGES GRAPHICS DSL DSM
      4. DSL::="Domain Specific Language".
      5. DSM::="Domain Specific Model".
      6. Everyone's first language is unlikely to be a masterpiece.
      7. Involve stakeholders.
      8. Understand the domain. Think about how people will use the language and/or model.
      9. Suspect outside sources for concepts. Eg UML/3GL/code/library/tools.
      10. Iterate. Nothing is perfect.
      11. Balance specific and general concepts.
      12. Don't Focus too strongly on one feature of the domain.
      13. Choose a good notation: Symbols need to be visually different and not ugly.
      14. Select graphic notation for relations between concepts with care.
      15. Plan for reuse.
      16. Understand the clients process.
      17. Plan to train people. It is not obvous.
      18. Plan to change after it is in use.

      2009-07-15 Wed Jul 15 11:07 The costs of ignoring the real situation

      This continues my summer series on technological prowess not being enough. The following case study shows how complex requirements can contain mis-features.


      1. Tesuo Tamai
      2. Social impact of information system failures
      3. IEEE Computer Magazine V42n6(Jun 2009)pp58-65
      5. RISKS 12th Dec 2005 [ 24.12.html ]
      6. Example of software leading to costly errors that followed the requirements.
      7. Example of the unexpected and expensive consequences of obscure cases in complex business rules.
      8. Example of human behavior -- user and maintainers -- defeating requirements.
      9. Example for MAJackson's analysis [Jackson06] in terms of domains outside the software under design should lead to better requirements and results.

      2009-07-13 Mon Jul 13 15:10 More on technology and the real world

      These two articles are from ACM Queue. The first describes a less successful project and the second explains the failure as a focus on technology rather than the needs of the stakeholders.


      1. Jeff Norwalk
      2. Featured Case Study: Making the Move to AJAX
      3. ACM Queue V7n1(Mar 2009) [ detail.cfm?id=1515744 ]
      5. Beta release did not work well enough -- did not fit the user and underperformed.
      6. Always try a full load test.
      7. Always try a user interface test.
      8. Also see [Christy09]


      1. Peter Christy
      2. Commentary: A Trip without a Roadmap
      3. ACM Queue V7n1(Mar 2009) [ detail.cfm?id=1515746 ]
      5. Review of [Norwalk09]
      6. No user requirements -- straight to technological solution. Performance an afterthought.
      7. Quote
          A good start is to not imagine what users want or need, but instead to talk with them about it. Try to walk in their shoes and understand how your software might help make their lives better (or not, as in this case). If you don't have time to do that yourself, then you should at least work with good product marketing people and listen to what they have to say.

      2009-07-10 Fri Jul 10 10:09 Who killed Technology

      One persistent theme in software development is the mismatch betwen the technology that the developer knows and loves vs the culture+systems+users within which the the technology is deployed. So here is the first example of a cool technology not acheiving its stated objectives because of political and economic forces. I plan a whole series on this topic....


      1. Kenneth L Kraemer & Jason Dedrick & Prakul Sharma
      2. One Laptop Per Child: Vision vs. Reality
      3. Commun ACM V52n6(June 2009)pp66-73 [ 151646.1516063 ]
      5. OLPC::acronym="One Laptop Per Child".
      6. Project attempted to change the worlds educational system by giving cheap robust laptops to all children.
      7. Teachers don't accept the new learning plan.
      8. Lack of political will and diffusion of goals -- computers are abandoned in classrooms with no training....
      9. Inspired existing companies to develop rival netbook Computers.
      10. Good technical solution fails to meet objectives because of cultural mismatch.

      2009-07-08 Wed Jul 8 12:26 Open Source as another optional process


      1. George Lawton
      2. the changing face of open source
      3. IEEE computer magazine V42n5(May 2000)pp14-17
      5. open source is no longer a movement, but another development process option.

      2009-07-06 Mon Jul 6 20:07 Term Transformars and semantics

      I'm in the process of reviewing MorrisBunkenburgTyrrell09 (below) when I tripped over another paper on "term Transformers" with a completely different approach and goal. Pity.


      2. Term Transformers: A New Approach to State
      3. ACM Trans. Program. Lang. Syst. V31n4 (May 2009)a16:1-42 [ 1516507.1516511 ]
      5. phase::=command "|>" term.
      6. In the text \righttriangle is used for my "|>" above.
      7. Example:
      8. x:=x+1 |> x^2 = (x+1)^2.
      9. Uses a lambda calculus based language of commands and terms to establish mathematical bona vides.


      1. William M. Farmer and Martin v. Mohrenschildt
      2. Transformers for Symbolic Computation and Formal Deduction
      3. Presented at a Workshop on the Role of Automated Deduction in Mathematics, CADE-17, Carnegie Mellon University, Pittsburgh, Pennsylvania, June 2000 [ transformers.pdf ]
      5. STTM::="von-Neumann-Bernays-Goedel set theory". This has terms and formulas. Terms may be undefined, but formulas are always defined and are either true or false.
      6. Transformers are total functions which may or may not preserve meaning or logistic properties like being (provably) true or false.

      2009-07-04 Sat Jul 4 07:50 How to design Application Programmer Interface -- API


      1. Michi Henning
      2. API Design matters
      3. Commun ACM V52n5(May 2009)pp46-56 [ 1506409.1506424 ]
      5. Bad is easier than good but has large long term unlimitted costs.
        1. Provide sufficient functionality to the caller/client/user.
        2. Smaller is better.
        3. Understand the context.
        4. General interfaces shouldn't set policy but specific ones should.
        5. Design from the caller's/client's point of view and for their convenience not yours.
        6. Don't pass the buck to the caller/user/client.
        7. Document before you implement.
        8. Ergonomics!

      6. Need to change education and career paths.
      7. (dick)|-no discussion of design by contract. Does it give better interfaces?

      2009-07-01 Wed Jul 1 10:34 Patterns for Implementers

      As noted in the previous but one item [ blog009.html#Difference Engine ] it is a lot easier and less risky to work within a range of known, tested, and standardized set of solutions to understood problems. Notice these don't have to be the best solution. What is important is that the solutions have been used, several times, successfully in the past. These are nowadays called Patterns of course. This usage of the word "pattern" goes back to [Alexander79] which describes tested solutions that resolve conflicting forces architecture.

      Again note that an untested solution to a problem is not a pattern. It is untested and so risky. It takes several applications of the solution before it becomes a pattern. It may or may not evolve into a component in a library, or a feature in a language, but it still is preferable to an untested solution in practical software development. For example, ideas like stacks and queues where used again and again until they started to appear in libraries like C++'s STL. Another set of patterns, that once grabbed the limelight, is the "Gang of Four" (GoF) [Gammaetal94] object oriented patterns. I cover GoF and GRASP patterns using Larman's text [Larman02] in my CSCI375 class with [ cs375/patterns.html ] as a simplified guide or cheatsheet.

      So, using tested patterns is precisely what successful engineers try to do. Indeed I inherited two books from my father of standard mechanical solutions to problems. With "Spons'" you don't have to reinvent the log cabin or a device to convert rotation into sliding motion.

      So, we need to expand the collection of patterns available to software developers. And then teach beginners to use them creatively.

      The following attempts to help. It is on Safari so most computer professionals can get it online. It is not the easiest book to read... it starts with the big theory and then develops a lot of details. Let us hope that some of these are helpful enough to become standards.


      1. Kent Beck
      2. Implementation Patterns
      3. Addison-Wesley Pro, Boston MA, 2006 ISBN 0321413091 CR 0903-0209 Safari [ 9780321413093 ]
      4. =THEORY PATTERNS Class State Behavior Collections Frameworks Performance TECHNICAL CODE = EXPERIENCE JUnit HotDraw
      5. Lots of detailed advice on object-oriented coding.

      Request for input on Adrenaline Junkies and Template Zombies

      Anybody able to contribute some notes on [DeMarcoHruschkaEtAl08] ?

      2009-06-30 Tue Jun 30 11:12 Model The Process

      I was disapointed in the following paper. It appears to provides evidence for a hypothesis that I beleive: that software developer's must understand the system into which their software will fit. In fact it merely advertizes a method for analysing, simulating, and designing business processes. To my mind this is a part of the problem space that already has many competing methods. The advocated techniques may or may not be better -- we have no data. Further I think that a lot of errors in software development happen because the developers did not look beyond the current process into the "real world".


      1. Joseph Barjis
      2. The importance of business process modeling in software systems design
      3. Science of Computer Programming V71n1(Mar 2008)pp73-87 [ science $CR 0906-0558 ]
      4. =ADVERT METHOD THEORY MODEL DEMO LANGUAGE-ACTION PETRI GRAPHIC ANALYSIS REQUIREMENTS SCENARIOS Keywords: Requirements specifications; Model checking; Business process modeling; Business process simulation;
      5. DEMO::="Design & Engineering Methodology for Organizations", [ http://www.demo.nl/ ]
      6. Special colored Petri nets show logic. Can be simulated to show clients what is possible.
      7. Analyze business processes in terms of the language-action cycle as expressed as Transactions between parts.
      8. Transaction::=Order; Execution; Result.
      9. Order is a transition from initiator to executor. It sets up a contract for the executor to carry out.
      10. Result is a transition from executor to initiator. It completes the contract.
      11. Execution is executed by the executor and can initiate further transactions with others.

      2009-06-29 Mon Jun 29 13:53 Now for Something Difference

      Here is a nice example of an engineering project that shows all the symptoms of a software project, and yet, clearly, involved no software. The design of the second Difference Engine was completed by Babbage in the 1800s, and was implemented [Swade00] in the 1900s. It is, possibly, the biggest example of BDUF ever attempted. The results are interesting.

    14. BDUF::="Big Design Up Front", pejorative term usually contrasted with various iterative risk-driven processes ( such as RUP -- The Rationale Unified Process, [BoehmTurner03] etc. ). Iterative processes avoid designing the whole system before starting any testable code. Roughly, their process is:
    15. Analyze a risky little piece of the problem; Design a little solution; Test it; Integrate it; Refactor; repeat.

      Some have argued that a sufficiently rigorous ("formal") design and a stable set of requirements allows BDUF to succeed. In the case of Difference Engine 2 the requirements were stable and expressed mathematically. The design was expressed in a special rigorous language (Babbage's Mechanical Notation [ bab-t-385.jpg ] and engineering drawings).

      No face-to-face communication. But the formal language did not provide answers to many questions. A graphic notation (compare UML!) did not help. The questions had to be answered by testing. We thus prove that BDUF doesn't work in a advantageous case.

      More, the Difference Engine 2 project shows that it is not software per se that is the difficulty but the use of untested technology. This demonstrates the risks of novel technology as in [Petroski85] "To Design is Human". There are other hardware projects where the initial design fails and has to be tested into a working project. See " The Soul of a New Machine " by Tracy Kidder [ The_Soul_of_a_New_Machine ] on the Wikipedia.


      1. Doron Swade
      2. The Difference Engine -- Charles Babbage and the quest to build the first computer
      3. Viking Penguin NY NY 2000 ISBN 0-670-91020-1
      5. The ultimate big design up front on a bleeding edge project. Design completed 100 years before implementation started.
      6. Result: Lots of debugging and redesign. Unit testing saved time. Assembly and test lost time.
      7. Impossible marketing deadline -- almost death march -- not met.
      8. Critical need of standard components and interfaces -- Whitworth bolts, nuts, and screws for example.

      2009-06-23 Tue Jun 23 11:10 Websites on Reliability

      Mark's column in SIGSEN is always interesting and provides interesting links. Here is the latest crop -- taken from the PDF.


      1. Mark Doernhoefer
      2. Surfing the net for software Engineering notes -- Software and System Reliability
      3. ACM SIGSOFT Software Engineering Notes V34n3(May 209)pp6-15 [ 1527202.1527204 ] (PDF)
      5. Handbook [ http://www.cse.cuhk.edu.hk/~lyu/book/reliability/ ]
      6. The Reliability Information Analysis Center [ http://www.theriac.org/ ]
      7. The Data and Analysis Center for Software [ https://www.thedacs.com/databases/url/key/2/ ]
      8. Relex Reliability Dictionary [ ReliabilityDictionary.asp ]
      9. Weibull.com [ http://www.weibull.com ]
      10. NASA Software Assurance Technology Center [ http://satc.gsfc.nasa.gov ]
      11. IEEE Reliability Society [ index.jsp?&pName=relsoc_home ]
      12. City University Centre for Software Reliability [ http://www.csr.city.ac.uk ]
      13. Reliability Engineering Tools [ tools.htm ]
      14. ...
      15. IEEE Transactions on Software Engineering(1993) [ toc.cfm?id=173802&type=issue&coll=GUIDE&dl=GUIDE&CFID=29760540&CFTOKEN=27889279 ]
      16. Dependable Embedded Systems [ http://www.ece.cmu.edu/~koopman/des_s99/sw_reliability/ ]
      17. ...
      18. Reliability Calculators [ AvailabilityTranslator.htm ] [ reliability_calculator ]

      2009-06-23 Tue Jun 23 09:16 Server fixed again

      I'm just finishing up grading and testing the newly rebuilt server that I use for preparing web pages etc.

      Also wondering about the publication schedule for this blog in the summer.

      2009-06-22 Mon Jun 22 13:08 Servers fail again

      My usual workstation (and other in csci.csusb.edu) are less than finctional after a crash last week.... luckily I've been able to port my tools to the faculty web server and so this is being written on a strange machine.

      More later.

      2009-06-19 Fri Jun 19 16:40 Students present work

      I spent the whole day taking notes of student presentations. See 2009/09/19 in [ seminar/ ]

      2009-06-17 Wed Jun 17 12:18 Errors and Defects

      Here is a perennial question -- where do you look for bugs in a large modular project? Should you look at the big complex modules or the small ones? I got involved in this controversy back in 1985 (BasiliPerricone84 below). The evidence conflicts ith ones intuition that defects occur most in large complex modules. Since then I've noted five other papers in my bibliography (list below)... and here is a new contribution -- KoruZhangEmamLiu09.


    1. Victor R Basili & Barry T Perricone
    2. Software Errors and Complexity: An Empirical Investigation
    3. Commun ACM V27n1(Jan 1984)pp42-42 + Correspondence V28n3(Mar 1985)pp322-323 (with Richard J Botting, H Dieter Rombach & Richard W Selby)
    5. New application means requirements change during the project.
    6. New modules have different kinds of errors than changed modules.
    7. Module size did not account for error proneness.
    8. Intuition clashes with data.


    1. A Guneg Koru & Dongsong Zhang & Khaled El Emam & Hongfang Liu
    2. An Investigation into the Functional Form of the size-defect relationship for software modules
    3. IEEE Trans Sofware Engineering V35n2(Mar/Apr 2009)p293-304
    5. Problems with conventional analysis -- deleted modules, size changes, ...
    6. Proposes and fits Cox proportional hazards models to CVS data from Mozilla, Cn3d, JBoss, and Eclipse
    7. Discovers more changes are made to small modules than might be expected.

    2009-06-12 Fri Jun 12 15:25 Cards

    One of my favorite tools has been old fashioned cardboard cards. All my class notes in my last undergraduate year are on cards. Burroughs explained an earlystack based compiler using cards as an analogy. I use playing cards to demonstrate sorting and searching algorithms. My first data base was a bibliography that was (and is) on 3><5 cards. Psychologists (eg Kelly) have used them with success to tease out the way we think and feel about a set of subjects. And of course I've read about and like the XP technique of writing User Stories on cards and sorting them in different ways in the Planning game. So with great pleasure we have the following:


    1. Neil Maiden
    2. Card Sorts to Acquire Requirements
    3. IEEE Computer Magazine V26n3(May/Jun 2009)p85-86
    5. Compares advantages and disadvantages for using a very old technology to represent and manipulate requirements.
    6. Compare the XP Planning Game.

    2009-06-12 Fri Jun 12 15:25 A Graphic is worth a thousand words

    Diomidis has shared some of his favorite tools...


    1. Diomidis Spinellis
    2. Drawing Tools
    3. IEEE Computer Magazine V26n3(May/Jun 2009)p12-13
    4. =EXPERIENCE GRAPHIC TOOLS dot Graphviz pic neato twopi circo gnuplot groff GMT mapping Google UMLGraph SVG PDF PNG ImageMagic
    5. "We don't seem to benefit from drawings in the way other engineers do".
    6. Describes experiences with half a dozen tools that produce graphics from commands/texts/data.
    7. Graphviz::= See http://www.graphviz.org/
    8. groff::= See http://www.gnu.org.software/groff/
    9. gnuplot::= See http://www.gnuplot.info/
    10. GMT::= See http://gmt.soest.hawaii.edu/
    11. UMLGraph::= See http://www.umlgraph.org/
    12. ImageMagic::= See http://www.imagemagic.org/
    13. Ghostscript::= See http://pages.cs.wisc.edu/~ghost/
    14. Inkscape::= See http://www.inkscape.org

    2009-06-10 Wed Jun 10 13:34 Better Embedded Programming

    People are always proposing new/old ways of fixing software processes. Here is a selection for fixing processes for developing embedded software: Incorporate executable models in the process, use static tools to check code, use software improvement techniques and CMMI, use a more agile process, use more formal techniques, use UML and MDD, ...

    As a child I often looked at the "Pick and Mix" counter for sweets in Woolworths -- I guess you should pick and mix from these moderately perennial proposals.

    Details follow:


    1. Hesham Shokry & Mike Hinchey
    2. Model-based verification of embedded software
    3. IEEE Computer Magazine V42n4(Apr 2009)p53-59
    5. Describes a complex sequence of phases which use a mathematical model to test successive versions of the system.
    6. process=MIL; SIL; PIL; HIL.
    7. MIL::phase="Model-in-the-Loop", Basic simulation of models response to stimuli with model generating code for SIL.
    8. SIL::phase="Software-in-the-Loop", Test executable code from MIL vs test results in MIL on a PC.
    9. PIL::phase="Processor-in-the-Loop", Test executable code from MIL vs test results on the processor.
    10. HIL::phase="Hardware-in-the-Loop", Test on actual hardware.


    1. Ben Chelf & Christof Ebert
    2. Ensuring the integrity of embedded software with static code analysis
    3. IEEE Software Magazine V26n3(May/Jun 2009)p96-99
    5. p97 Links to resources in sidebar.
    6. Six_detectable_defect_classes:= division by zero + memory leak + null pointer dereference + uninitialized variable + buffer overflow or underflow +inappropriate cast.


    1. Ronald Kirk Kandt
    2. Experiences in Improving flight software development processes
    3. IEEE Software Magazine V26n3(May/Jun 2009)p58-64
    5. Very little quantitative evidence of benefits of the improvement process.
    6. Improvements had a wide impact.


    1. Michael Smith & James Miller & Lily Huang & Albert Tran
    2. A More Agile Approach to Embedded System Development
    3. IEEE Software Magazine V26n3(May/Jun 2009)p50-57
    4. =CASESTUDIES 4 XP TDD TESTING Embedded-Unit XPI E-Race
    5. Stages:= Vision; Prototyping; initial_production; full_production.
    6. Run a parallel system to monitor for race hazards.


    1. Junbeom Yoo & Eunkyoung Jee & Sungdeok Cha
    2. Formal Modeling and Verification of safety-critical software
    3. IEEE Software Magazine V26n3(May/Jun 2009)p42-49
    5. Connect model checking tools to a graphic interface -- use color!
    6. Generate code from models.
    7. FTA::="Fault Tree Analysis".
    8. Reduce the gap between "raw data" and "Domain Knowledge".


    1. Jesus Martinez & Pedro Merino & Alberto Salmeron & Francisco Malpartida
    2. UML-based Model-Driven Development for HSDPA
    3. IEEE Software Magazine V26n3(May/Jun 2009)p26-33
    5. HSPDA::="High-Speed Downlink Packet Access".
    6. Using executable and compilable models made it easier.

    2009-06-08 Mon Jun 8 07:50 Reading about invented languages

    I finished "In the Land of Invented Languages" overnight on Saturday. It is going to be a busy day today and so I will edit the bibliographic entry [Okrent09] directly rather than expatiate here....

    But briefly: (1) required reading for all language designers. (2) humans are incredibly inventive, but inventing a new "natural" language is not a productive use of your time. (3) read it!

    2009-06-05 Fri Jun 5 12:44 Undetected Errors

    I can't resist noting The_Kirsch_Principle and its history.


    1. Russell A Kirsch
    2. An undetected Error (letter)
    3. IEEE Computer Magazine V42n4(Apr 2009)p53-59
    5. SEAC work 24/7 for four years with an undetected error! Discovered when moved.
    6. Video [ videosearch?q=seac+history ]
    7. The_Kirsch_Principle::="All computers are always, in some, sense 'broken'".

    2009-06-03 Wed Jun 3 11:19 More invented Languages

    My wife heard this [ invented-languages ] last night on NPR (On Point) and I replayed it this morning. If you are interested in languages then you should enjoy it. It is hype for Okrent09 below. But fascinating and knowledgable discussion.

    And gives me an excuse to indulge my liking for artificial languages.

    For a previous entry on this topic see [ blog008.html#Holmes08 ] and the controversy in 1978 in "Computer World".

    Okrent claims to have found 900 hundred artificial languages -- and they have all failed. If Okrent is right then you need speakers for the language before the language exists. It is quite clear that languages evolve -- and that this is healthy.


    1. Arika Okrent
    2. In the Land of Invented Languages: Esperanto Rock Stars, Klingon Poets, Loglan Lovers, and the Mad Dreamers Who Tried to Build A Perfect Language
    3. Random House Publishing Group Pub. Date: May 2009 ISBN-13: 9780385527880 352pp
    5. Benjamin Whorf's Hypothesis
    6. More when I've read it [click here [socket symbol] if you can fill this hole]

    While researching the previous entry I found a new diagramatic technique based on Bliss + Loglan [ belltrinity.html ] which in turn lead me to people [ gbgwiki ] working on the "Glass Bead Game" imagined by Herman Hesse( [ Hesse43 ] below ). Another topic which has been part of my life for nearly half a decade. The Glass Bead Game captures the essence of academic life - the search for connections and ideas -- and the ritual presentations.

    The Glass Bead Game


    1. Herman Hesse
    2. The Glass Bead Game (Magister Ludi)
    3. Publishers: Several. Try any good library or book store [ 080501246X ] (Amazon.com)
    5. For history, summary and clues see [ The_Glass_Bead_Game ] (Wikipedia)

    Apparently people have been trying to instantiate the game ...


    1. Ron Hale-Evans
    2. Kennexions GBG Home Page
    3. Link [ http://kennexions.ludism.org/ ] TBA
    4. Also see
    5. Ludism::= See http://ludism.org/ , the philosophical study of games
    6. =IDEAS Glass Bead Game Wiki Kennexions Bliss Loglan

    Bliss Symbols


    1. Charles K Bliss
    2. Semantography ( Blissymbolics) 2nd Edn
    3. Semantography ( Blissymbolics), Sydney Australia 1942 [ http://www.semantography.com/ ]
    5. Dictionary of symbols [ http://www.semantography.com/4/ ]

    Other resources: [ http://www.blissymbolics.org/ ] (introduction to symbols) [ http://www.blissymbolics.us/animations/ ] (Animations of the derivations of some symbols) [ bliss-rules.pdf ] (Rules) [ http://www.blissymbolics.us/ ] (USA) [ http://www.crockford.com/blissym/ ] (introduction and fonts) [ lesson1.pdf ] (first lesson in Bliss) [ blissymbolics.htm ] (Intro -- one page of simplest symbols)

    What I would like is an online dictionary/thesaurus.

    I guess that is enough indulgence for today.

    2009-06-01 Mon Jun 1 13:19 More Details on the Safety of Hybrid Systems

    Now I have studied the technical report PlatzerClarke08 below I must revise my comments in the previous blog entry. I thought it would describe the discovery of a hole in a standard way of avoiding collisions between aircraft. It fact it gives an example showing the absence of errors. I've yet to find a source for the original report. I'll probably find it one day.... but meanwhile I small hype.


    1. Andre Platzer & Edmund M Clarke
    2. Computing Differential Invariants of Hybrid Systems as Fixed Points
    3. CMU CS Technical Report [ CMU-CS-08-103.pdf ] (PDF)
    5. Gives a way to compute whether formula describing important properties are true for all time or not.
    6. [α]φ = all states reachable thru Hybrid program α satisfy φ.
    7. Formulas assembled out of terms (expression ~ expression) for relation "~".
    8. Directional derivative of a term t wrt to vector equation D : x_dot = θ, ∇[t] = ∇ t.θ.
    9. Differential Invariant of a formula F depends on ∇[D]F is the conjunction of ∇ t.θ over all terms t in F.

    2009-06-01 Mon Jun 1 06:29 Fun introduction to Intractability

    I can't resist posting this [ 001270.html ] bit of the "Coding Horror" blog that gives a fun introduction and example (from xkcd comic) to "P=NP".

    2009-05-30 Sat May 30 07:13 The Joy of Upgrades -- Scripts dead

    The Contact/MailMe and Contribute scripts no longer work. Please use regular EMail to rbotting at my CSUSB address instead.

    2009-05-29 Fri May 29 13:05 Dependable and Safe Systems

    First I found an interesting article [ 090420121333.htm ] in the Science Daily web site. It reported on Edmund M. Clarke and Andre Platzer's work on verifying the Safety Of Computer-controlled Devices (ScienceDaily 23 April 2009. 28 May 2009). This is based on a press release [ april20_cyberphysicalsystems.shtml ] that I chased back to a CMU technical report [ CMU-CS-08-103.pdf ] (PDF) on proving the safety of systems that have both digital and analog components -- for example an air traffic control system. The motion of the planes (hopefully) is analog, and much of the modern control system is digital.

    Their technique found a case where the normal recommended flight path to avoid another aircraft, if followed by both planes, leads to a collision. Not a safe system. To achieve this (and some other impressive results the authors compute differential invariants which are an extension of Floyd's Invariant Assertion used in software.... and indeed the definition of transitive closure in Principia Mathematica.

    I need time to study the report in detail before I can record it in my bibliography.

    Meanwhile, Daniel Jackson has written a long but well reasoned proposal for a newish way of thinking about the quality of systems. In particular, he argues that if you are going to rely on a system then you need to have some reason for trusting it. He suggests a way [ Dependability Cases ] to record and develop dependable systems.


    1. Daniel Jackson
    2. A Direct Path to Dependable Software
    3. Commun ACM V52n4(Apr 2009)pp78-88 [ 1498765.1498787 ] [ publications.html ]
    5. Based on a study done for NRC lead to Dependability Cases.
    6. Lots of examples of RISKS and how they occurred and how the effect reasoning about the dependability od a system.
    7. A dependability case provides evidence, in the form of claims, that certain critical properties will hold.
    8. The analysis of the critical properties and the claims that support them starts on day one of a project, and guides architectural decisions. Well chosen architecture -- modular, decoupled, simple -- makes it cheaper to establish a dependability case.
    9. Dependability cases should develop "hand-in-hand" with the product. The developers chose techniques and technology to support the claims.
    10. Critical properties should be close to the user/client/real world.
    11. All claims depend on assumptions about the client's world: an air traffic control system can not stop a pilot deliberately crashing into another aeroplane.
    12. Claims connect the developing system, via assumptions, to the critical properties.
    13. A dependability case must be auditable, complete, and sound.
    14. A rigorous process can help establish a dependability case -- but need not be burdensome.
    15. A risk-averse and meticulous culture will help.
    16. Need robust platforms and tools -- language design.
    17. The correctness of code is not the weakest link in the chain -- only 3% of the time...
    18. Testing and analysis contribute as well.
    19. Credible tools -- example of a broken proof: binary search when bounds > largest integer!
    20. See also [JacksonD06] [Jackson01] [Jackson04] (Outer vs inner requirements)

    2009-05-27 Wed May 27 17:18 Changing tools and systems -- makefiles

    One of the things one learns in practice is to "make haste, slowly" (festina lente), to not rush your clients into a large change. To evolve changes incrementally rather than big-bang. Another rule is to prefer bottom-up user-advised growth to top-down management mandated change.

    The following article makes this point. But not in a client's domain. Kode Vicious is discussing making changes to a developer's tools.

    I have often regretted that much that we know about developing software for our clients is not applied to developing our tools as well.


    1. George V Neville-Neal (Kode Vicious)
    2. System Changes and Side Effects
    3. Commun ACM V52n4(Apr 2009)pp25-26 [ 1498765.1498777 ]
    4. =EXPERIENCE TOOLS SYSTEMS CHANGE Make SCons Makefiles SConstruct debugging Python
    5. Problems occur with build tools when there are many interlinked description/dependency files.
    6. Debugging a collection of configuration/buildfiles/Makefiles is difficult.
    7. Changes have unexpected consequence that ripple thru the system... and the description of the system.
    8. Make changes because they give value.

    2009-05-26 Tue May 26 17:22 Memorial Day and Tao

    Yesterday was a holiday in the USA and so I didn't post a message.

    Meanwhile, I have added a "The Tao of Programming" link to my [ samples/methods.html ] page -- which has many HHOS descriptions of programming development methods and processes.

    By the way.... the web server in the CSE.csusb.edu domain are about to change. I will be moving the pages on this site over sometime soon. It should be transparent, but systems do exhibit antics....

    2009-05-22 Fri May 22 15:58 Computer languages

    Perhaps two publications on computer languages that don't advertise a particular language might form a trend. There was [ blog009.html#WhiteKochGehrkeDemers09 ] on using domain patterns to design games scripting languages, and now Shapiro09 that describes half-a-dozen debugging languages as examples of how langauges evolve.

    However, there is also Richardson09 and [ /blog009.html#Larson09 ] which continue the old tradition of selling a particular language...


    1. Michael Shapiro
    2. Purpose-Built Languages
    3. Commun ACM V52n4(Apr 2009)pp36-41 [ 1498765.1498781 ]
    5. Figure 1: little languages in Unix in the early 1980s


    1. Chris Richardson
    2. ORM in Dynamic Languages
    3. Commun ACM V52n4(Apr 2009)pp48-55 [ 1498765.1498783 ]
    5. Managing a Object-Relational-Mapping (ORM) using a dynamically typed language like Groovy.

    2009-05-20 Wed May 20 13:27 Musical standards

    Just read the following and added to my [ samples/standards.html ] page.


    1. Denis Baggi & Goffredo Haus
    2. IEEE 1599: Music encoding and interaction
    3. IEEE Computer Magazine V42n3pp84-87
    5. IEEE1599::DTD= See http://standards.ieee.org/downloads/1599/1599-208/
    6. Example: <clef type="G" staff_step="2" event_ref="c1"/>
    7. Previous report [Baggi05]

    2009-05-18 Mon May 18 12:52 Domain Specific Scripting Languages -- Games

    This may be the first time a computer professional has published a discussion of the design of a language without advertizing the language they have already designed. The key thought is a flash of blinding if obvious truth -- the users and usage of the language should strongly influence the design of language.


    1. Walker White & Christoph Koch & Johannes Gehrke & Alan Demers
    2. Better Scripts, Better Games
    3. Commun ACM V52n3(Mar 2009)pp42-47 [ 1467247.1467262 ]
    5. Notes the need for less technical designers to write scripts for games.
    6. Proposes designing languages that fit the well-known patterns -- used by users and by game-play programmers not software engineers.
    7. State_Effect::pattern="Behavior of object depends on current state and is summarized into an effect that is then applied to change the state", so, language separately declares state variables and effect variables and supports two phases: effect and update. During the effect phase the state variables do not change and the effect is not read. In the effect phase the effects are read only and the states are write only.
    8. simulation_loop::=following (
      1. for each timestep (
        1. for each object, compute object.effect' using object.state;
        2. for each object, update object.state' using object.effect;
    9. Restricted_iteration::pattern="to avoid infinite loops, all loops have finite limits", [Witty77a]
    10. Concurrency patterns -- example of the need for an atomic transaction: putting things in a container, if room.
    11. Game-Aware Runtimes: Language should provide the runtime system with clues on how to execute code, and monitor it for statistics.
    12. Does not advocate a particular language!

    2009-05-15 Fri May 15 13:08 System Engineering

    We've just had James H. Jones of ODDSCO [ http://www.optants.com ] and Optivus Proton Therapy present an seminar [ seminar/20090515JimJones.txt ] on System Engineering. For a short while you can find the slides he presented at [ seminar/20090515JimJones.pdf ] on this web site.

    I've also just finished reading an article noting how far short Software Engineering is from Engineering. It bewails the lack of training in System Thinking and System Engineering in COmputer Science. It ignored the reality that most software development is not engineering. Because engineering processes fit some niches well, but not others.


    1. Peter J Denning & Richaqrd D Riehle
    2. The Profession of IT: Is Software Engineering Engineering
    3. Commun ACM V52n3(Mar 2009)pp24-26 [ 1467247.1467257 ]
    5. Things we do worse than engineers do:
      1. The Principle of least surprise.
      2. Design metrics -- including design to tolerances.
      3. Separating design from implementation.
      4. Reconciling conflicting forces and constraints.
      5. Adapting to changing environments

    6. Roles (one person plays many roles in a team) --
    7. software { architect, engineer, programmer, manager } | O(systems engineer).
    8. Need for Systems Thinking: From the hardware.... to the user environment.
    9. Need for better tools, education, adoption of effective practices.

    2009-05-13 Wed May 13 13:33 Erlang the Language

    I have just updated [ samples/languages.html#Erlang ] my documentation on the Erlang concurrent functional language. This comes from studying Larson09 below.


    1. Jim Larson
    2. Erlang for Concurrent Programming
    3. Commun ACM V52n3(Mar 2009)pp48-56 [ 1467247.1467263 ]
    5. A naturally concurrent language used at Ericsson and elsewhere.
    6. Use pattern matching rather like Prolog! But also pattern matches incoming massages.
    7. Has anonimous functions.
    8. Typically a client makes a unique reference that it sends as part of a message to a parallel server. This identity is used by the server to call-back the client.
    9. Note: The obligatory examples are also at [ Erlang_(programming_language) ] (Wikipedia)
    10. See [ samples/langauges.html#Erlang ] for more information.
    11. OTP::="Open Telecom Platform".

    2009-05-11 Mon May 11 14:23 Proof Checking

    I have grave doubts about the usefulness of the following theory -- but I've been proved wrong before -- as when I decided that relational databases would never be important.

    My MATHS language is designed with a proofs in mind. I use a variation of Natural deduction that use block structure in the same way that modern programming languages do. I taught this back in the 1970's. I've written several pages [ maths/logic_20_Proofs100.html ] [ maths/logic_25_Proofs.html ] [ maths/logic_27_Tableaux.html ] [ maths/logic_10_PC_LPC.html ] [ maths/logic_11_Equality_etc.html ] on proofs.

    Key point -- it should not be difficult to write a PVS style tool [ maths/logic_20_Proofs100.html#Automation ] to check MATHS proofs, spot holes and errors, and report the correctness. However you do have to examine every step in the proof ... and in any interesting logic there proofs of any length can think of.

    Recent theoretical work hints at ways of writing proofs that take a constant time but offer on partial certainty. They will never reject a correct proof, but they may accept (occasionally) a fallacious proof.


    1. Mahu Sudan
    2. Probabilistic Checkable Proofs
    3. Commun ACM V52n3(Mar 2009)pp76-84 [ 1467247.1467267 ]
    5. Normal proof methods require you to check every step in the proof to be sure that the result is a theorem.
    6. PCP is a theoretical method for constructing proofs that can be checked with a degree of certainty quickly.
    7. Examples quoted are limited to the propositional calculus or the lower predicate calculus with a finite universe of discourse.

    2009-05-08 Fri May 8 12:05 Graphical notations for Software

    When I was first allowed to compile and run my code, first year of college (1963), and was taught about flow charts. I decided that what I wanted was a language that could encode flow charts directly. At the time I had not seen any visual displays.... so I invented a notation that expressed boxes and arrows directly. I've forgotten the details and never figured out how to compile it.

    My graduate work centered on simple graphics -- drawing curves mainly. But I saw executable graphics running in some American research places. As a junior faculty (1970's) I played with the idea of inputting and executing flowcharts just in time for the Structured Programming revolution to make flowcharting a "bad" idea.

    One of my students [Witty76] [Witty77a] [Witty77b] invented a very clever and simple notation for structured Dimensional Flowcharts which he proved by developing an operating system for a microfiche and microfilm output device, plus a language and tool that let him compile his Dimensional charts and output them to microfiche. Very impressive. The key idea was brilliant -- the vertical dimension was for sequences and the horizontal for parallelism (including conditional branches). Refinement was shown as a diagonal. It gave elegant support of structured programming and stepwise refinement.

    Dimensional Chart of a program

    Then I left my university and joined the British Civil Service to learn Jackson Structured Programming [ Jackson_Structured_Programming ] (JSP) which has a different, very hierarchical approach to drawing data and program structures. A key thought is that the structure of the program reflects the structure of the data and the "real world" that the data encodes.

    I then moved to the USA and explored combining Dimensional Charts with JSP. By 1985 there was a ton of graphical notations for programs [Raeder85] including the famous [ Nassi-Shneiderman ] diagrams -- [ Nassi-Schneiderman_diagrams ] (Wikipedia).

    I developed a technique I called "Temporal Mapping" that used Witty's Dimension's for sequence and selection. I used these with a bit JSP to develop my favorite tool for word wrapping long lines in a text file -- [ tools/br.d.html ] [ tools/br.d.in.jpeg ] [ tools/br.d.out.jpeg ] [ tools/br.c ] (K&R C source code).

    I've evolved temporal maps further into a languge TEMPO [ papers/rjb9Xx.TEMPO.html ] (figures in PostScript). However I decided that parallelism was a third dimension and decided to wait for a virtual reality system to explore that. I had also discovered how very constraining it is to cast every process into the four structures: sequence, selection, iteration, and parallelism.

    And round about then David Harel [ David_Harel ] sent me a copy of a technical report on statecharts ( [ Statechart#Harel_statechart ] ) and the rest is history (Harel09 below), as they say.


    1. David Harel
    2. Statecharts in the Making: A Personal Account
    3. Commun ACM V52n3(Mar 2009)pp67-75 [ 1467247.1467265 ]
    5. Originally an invited paper at the history of Programming Languages conference 207
    6. How work on Avionics (1983) lead to a notation where diagrams define the system's behavior.
    7. 1983 Problem: clients understood the system but the information was not well-organized: "I had to pend a lot of the time asking questions"(p69).
    8. Solution: "The pictures simply did a much better job of setting down on paper the systems' behavior[...]the mathematician in me found this difficult to accept".(p69)
    9. "when designing a graphic language, topology should be used whenever possible"(p70).
    10. "Executability was a basic[...] concern"(p70).
    11. 1984 Tools: Statemate -- GUI, executable, generate source code. Simulate circumstance -- similar to debugger.
    12. Woes of Publication -- many rejections -- some successes. Technical report [Harel86] Commun ACM [Harel88] IEEE Trans Se [Hareletal90] ACM TOSEM [HarelKahanna92] [HarelNaamad96] IEEE Computer Magazine [Harel01]
    13. Object-oriented StateCharts: [HarelGery97] [HarelKupferman02]
    14. On Semantics: very important, but finding the right semantics took time.
    15. Now used widely.
    16. Conclusions
      1. Lessons come from developing tools and real-world use.
      2. Development in the lion's den -- not academic.
      3. Getting a handle on the way clients think.
      4. Should have published a book faster.
      5. Should not have confused the problem of getting clear semantics with publicizing the chosen semantics.

    2009-05-06 Wed May 6 11:00 Paper confirms previous observations

    I learned about this paper by reading "Computer Reviews" CR. Then I found it in the ACM Digital Library. It is a very nice paper reporting on experiences implementing a workflow Management system for a bank. They used BPEL
  1. BPEL::= See http://csci.csusb.edu/dick/newb2006/FuBultanSu05.html Which I am suspicious of because it uses control flow rather than data flows to model complex non-sequential systems [ DesaiEtal05 in newb0329 ]

    What is nice about it is that the writers come to some very familiar conclusions.

    1. Exceptions are the rule. [KjaerMadsen95]
    2. 90% correct today is better than 100% later. A lesser tenet of [Gancarz95]
    3. Listen and work with your users. [Royce70] (one of hundreds tagged " USER " in my bibliography).
    4. Grow Software [Brooks95]
    5. Systems of Systems increase interdependence (Boehm's SISOS [Boehm08] ).

    It sounds that using a work flow management system to link legacy systems is very like using a UNIX shell script to drive UNIX power tools.


    1. Seen Brahe & Kjeld Schmidt
    2. The Story of a Working Workflow Management System
    3. ACM Proc GROUP'07 (Nov 2007) pp249-258 CR 0811-1106 ACM DOI [ 1316624.1316661 ]
    5. CSCW::="Computer Supported Cooperative Work".
    6. WFM::="Workflow Management".
    7. SOA::="Service Oriented Architecture".
    8. Early attempts to program office procedures failed because exceptions to the procedures were common. How to make the result adaptable? How to fit in with the continuing creation and adaption of procedures/workflows. How to integrate existing (legacy) systems.
    9. Integrate systems by using SOA... encapsulate legacy code as a service. Workflow as glue.
    10. (dick)|-Workflow sytems/languages seems to be like scripting.
    11. Develop a workflow system iteratively.
    12. Get the developers and the users closely involved.
    13. Business's analyst's can get it wrong!
    14. Development followed Babbage's model: craft; division of labor; stepwise automation; more or less complete automation.
    15. Need to avoid fragmented tasks. People prefer complete cases to individual tasks. First task in process should assign remaining tasks in the case to same person. "We do not want to be a factory". Not task-centric, but case-centric. "It does not feel right " not to know the context of tasks.
    16. Another early task in each workflow is to determine if the task is simple enough to be automated or needs human discretion and guidance.
    17. Describing exceptions if difficult and time consuming. Better to bounce them to a human... and think about how to automate in a later iteration.
    18. Automating more kinds of processes is an optimization. Tweaking and Twisting the automated processes.
    19. Nearly a 20% gain in speed. 80-90% automated.
    20. No need to re-enter data into each application.
    21. People like to monitor automated processes.
    22. Tell the users when the system is becoming unstable. Tell them about bugs. Tell them about performance problems.
    23. Workflows integrated legacy systems into exiting processes -- so the old system could not be replaced until the workflow was redesigned, tested, and running with the new service provider. Increased coupling and dependency between systems.
    24. Application niche is a very regular system -- unlike, say -- medicine.

    2009-05-05 Tue May 5 11:02 Server crashed on Monday

    The web server went down yesterday. I've restored as much of the web site as I can.... But some [Buttons] on these pages do not function. You can search OK. But you can not use the [Contact] button to send me a message. Neither can you send me formatted contributions.

    Meanwhile use EMail to my CSUSB address.

    2009-05-04 Mon May 4 16:11 Lost Information

    We just lost information on the web server.... it will take me a while to recover stuff from my back up system. This includes the tools and pages that let people make contributions. Plus the previous two archives for 2008 and 2009.

    2009-05-01 Fri May 1 13:28 John Brunner -- The Shockwave Rider

    In a linked data structure horrible things happen if a link is lost. On the web, a bad URL can lead to "404" and the resource can be lost. However, if someone does not link their work to previous work there are few obvious effects. Slowly, however the quality of discipline will fall as it looses its history. So one of the conscious aims of this blog and the consolidated bibliography behind it is to enable connections to be preserved. Here is an interesting case history: an idea in an SF story in the 70's is now a technology that thousands are sharing.

    Reading a couple of articles on Prediction Markets (Wikipedia [ Prediction_markets ] [ Goth09 ] below) and crowdsourcing (Wikipedia [ Crowdsourcing ] [ Hoffman09 ] below) in the latest Communications of the Association for Computing (ACM), reminded me of John Brunner's prescient SF novel, see [ Brunner75 ] below. This novel looked forward to a nationwide network with "worms"( as constructed by [ SchochHupp82 ] below) and "Delphi boards" here a collection of people make predictions about things they don't know and if enough of them take part.... the predictions (according to Brunner) cluster round the what happens. More the government (in the novel) uses a totalizer/stock market where you can bet on ideas -- so that the odds can be used to predict the future. Here are a couple of quotes from my copy of the novel to show what Brunner imagined back in 1974.


      It works, approximately, like this.

      First you corner a large -- if possible, a very large -- number of people who, while they've never formally studied the subject you're going to ask them about and hence are unlikely to recall the correct answer, are nonetheless plugged into the culture to which the question relates.

      Then you ask them, as it might be, to estimate how many people died in the great influenza epidemic which followed World War I, [...]

      Curiously, when you consolidate their replies they tend to cluster around the actual figure as recorded in almanacs[...]

      [...] Well if it works for the past, why can't it work for the future?


      Page 39 [...] he stood surveying the high-slung display, tracking the figures with the ease of much practice. He looked first at his favorite sector, social legislation, and was pleased to see he had two won bets to be collected shortly. [...]


    1. John Brunner
    2. The Shockwave Rider
    3. Harper & Row 1975 ISBN 0-060-10559-3
    5. Wikipedia [ The_Shockwave_Rider ]
    6. Review 1976 [ 1095302.1095305 ]


    1. John F Schoch & Jon A Hupp
    2. The "Worm" programs -- early experience with a distributed computation
    3. Commun ACM V25n3(Mar 1982)pp172-180 [ 358453.358455 ]
    5. Refers to [Brunner75] in a footnote and records the transition from a novelist's idea of a "Tape worm" to a practical technology.


    1. Greg Goth
    2. Betting on ideas
    3. Commun ACM V52n3(Mar 2009)pp13-15 [ 1467247.1467252 ]


    1. Leah Hoffmann
    2. Crowd Control
    3. Commun ACM V52n3(Mar 2009)pp16-17 [ 1467247.1467254 ]
    5. Many minds make lite work.... wide band delphi

    2009-04-30 Thu Apr 30 17:26 Programming has got better

    I have suffered most of the things in this article [ article.do?command=viewArticleBasic&articleId=9132061 ] (Computerworld article found on slashdot), or even worse ones.

    2009-04-29 Wed Apr 29 13:01 Microsoft Chases after the Verification Bandwaggon

    I had assumed that formal verification of programs was a fairly dead technique. I used it with success in the 1970s, and then watched it become fashionable in the 80's and then disappear into the sunset during the 90s. But now MicroSoft has developed a Language Spec# [ http://research.microsoft.com/en-us/projects/specsharp/ ] with compilers (Boogie) and other tools that fit [ samples/methods.html#design_by_contract ] into the Visual Studio environment and C#. I've checked out the PowerPoint presentation and it has all the examples that we used use when program proving was taught 20 years or more ago plus the later work by Bertrand Meyer. I'll have to watch this since I'd like to teach students to produce program that are guaranteed to work again.

    I had forgotten that one of the great practitioners of computing in the 1960s -- Tony Hoare -- was a persuasive advocate and inventor of formal methods. He spoke to the motion the "Algol 68 is not an Algol-like Language" in a sold out debate in London at the time. He is now with Microsoft.


    1. Len Shustek (Ed)
    2. An Interview with C. A. R. Hoare
    3. Commun ACM V52n3(Mar 2009)p38-41 [ 1467247.1467261 ]

    2009-04-27 Mon Apr 27 13:39 Complexity confronted

    Here are a couple of papers presenting solutions to the kind of complexity that happens when we move from sequential systems to non-sequential ones. Problems arising for coupling systems that run in parallel. One solution technique is to construct a special algebra that models the properties of interest -- these tend to be variations of [ maths/math_73_Process_algebra.html ] -- and show how they make the calculation of desirable properties feasible. Another approach is to create new formalisms and concepts that have the same effect. Here are the two recent papers that illustrate these approaches in wildly different areas.


    1. Chunyang Ye & S C Cheung & W K Chan & Chang Xu
    2. Atomicity Analysis of Service Composition across Organizations
    3. IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp2-28
    5. How to be sure that the combination of several independent processes, linked by services, are atomic -- they either happen or they have no effect -- despite not knowing all the private details and using exception handling.
    6. Distinguishes process that are "compensable" and "retriable".
    7. Defines a special process algebra for tracking and computing the atomicity of combined processes.
    8. Demonstration of supply chain and insurance examples.
    9. Experience shows more accuracy than previous attempts via projecting or abstraction.


    1. Pamela Zave & Eric Cheung
    2. Compositional Control of IP Media
    3. IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp46-66
    5. Usually the channels used to send media through a network are independent of the signalling channels.
    6. This makes it difficult to design protocols and systems that work correctly.
    7. Proposes a couple of abstractions that help: flowLink and holdSlot.

    2009-04-24 Fri Apr 24 13:57 Looking backward before leaping forward

    I have a student who is willing to work with me to improve this web site.

    As a starting point he needs to know something about its vision and structure.

    This blog is just the tip of the iceberg. A lot of my academic work is publically available on this web site. So first some notes on the vision -- a repository of information for students and faculty for my teaching and my research on software development and the MATHS language that came from that research.

    Here is the concept I used to set up my website, some years ago.

    Academic life has three components: Teaching, Professional Development (Research), and Administration.

    The implementation was by directory within the website. To help avoid the "Lost in Hyperspace" problem I thought to use background colors for the different components. I also provided "crumbs" indicating where you were.

    I choose a very pale yellow for teaching (this has become white over time), and a pale blue for research -- especially for MATHS. [ http://cse.csusb.edu/dick/maths/ ] Pages that could be useful for students (teaching) and were based on my research would be green [ http://cse.csusb.edu/dick/samples/ ] But I also used green for publications and presentations [ http://cse.csusb.edu/dick/papers/ ]

    I used pink for personal pages. But again these have beome paler and so white. I've never chosen a color for Admin.... most of it is personal and/or private in any case.

    One idea was too cumbersome ... as one got deeper into the web site I thought the background might become more intense.

    Other thoughts -- sticking to a solid subset of HTML and no fixed font sizes -- maximize the number of people who can use it.

    I also had this idea of a "StarTrek, the next generation" theme.

    One problem that completely blind-sided me was the length of pages. Most have too much content. Too much scrolling. Look too complex and off-putting.

    Now for some notes on the way I structure the web site.... and some of its content.

    I rely heavily on the UNIX/Linux file system to separate the different areas.

    Here is an annotated list of the main live directories. Several of them have subdirectories (shown...). I've organized them by function.

    1. Admin [ 25th ] Celebration of dept 25th anniversary [ seminar ]
    2. Research [ andor ] Work on And/Or tables [ maths ] [ monograph ] [ notes ] Notes on some bibliographic items placed in "newbib.html". [ papers ] [ publications ] [ samples ] Samples of the MATHS language -- languages, methods, etc
    3. Service [ bin ] [ c++std ] [ doc ] Documentation -- archive of newsgroup FAQ mainly [ examples ] C++ code [ src ] [ SRS ] Software Requirements specification [ tools ] Mainly scripts
    4. Teaching [ cs201 ] [ cs202 ] [ cs320 ] [ cs330 ] [ cs360 ] [ cs372 ] [ cs375 ] [ cs488 ] [ cs489 ] [ cs546 ] [ cs556 ] [ cs595 ] [ cs599 ] [ cs620 ]

    Each directory determines the standard header and format for HTML files in that directory.

    2009-04-22 Wed Apr 22 18:10 Architecture and Experience

    There has been a lot written about software architecture since Tom Gilb and others started to use the term in the late 1970's. I've always been a little suspicious of the subject -- from the definition of the term thru to the various theoretical approaches.

    The paper [ Matsson09 ] below, describes the area well and then goes on to describe a particuar, large scale and difficult project that attempted to use Model-driven Development with a specific architecture. The MDD part worked and ment that designs were easily mapped into code using tools. However there was no way to state and enforce the rules that the designs had to follow to fit the required architecture.


    1. Anders Mattsson & Bjorn Lundell & Brian Lings & Brian Fitzgerald
    2. Linking model-driven development and software architecture: A Case Study
    3. IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp83-93
    5. The abscence of a formal ay to record architectural rules lead to extra effort being involved

    2009-04-21 Tue Apr 21 13:56 Estimation

    Trying to estimate the amount of effort needed to complete a software development project is difficult -- if not possible. The whole idea is based on the concept that one knows what a project is before we complete. Whereas, in many projects their is an element of research to add to the development -- things are discovered as the project is worked on. I can well remember, on the 31st of August in 2002, outside the "Duke of Marlborough" pub, in London, searching for a book -- it wasn't in Foyles (an excellent source for technical and mathematical obscurities) or in Waterstones near London University, .... and my last chance was the Science Museum in Kensington ... 40 minutes away via the underground and a long tunnel. I realized that I should have made some phone calls first. And vowed that I would always, in future, make the first step in any plan, a step to reduce the uncertainties in the project. But -- Risk driven development is now a commonplace in newer processes like RUP (Rational Unified Process).

    However my experience in 1967-68 developing a program to analyze the statistics of mixed distribution -- Placebo Reaction Model -- should have told me what I needed to know. I tried to use Critical Path Methods but in the middle of the network was the equivalent of "Here a Miracle Happens". It all turned on whether I could solve a particular problem or not. Without an answer to this question there was no way to predict how long the programming would take. I recently checked back on this field and people are still trying to come up with solutions....

    Meanwhile, lots of research is taking place on estimating software projects. According to [ JorgensenBoehm09 ] most research is into formula that claim to predict the effort needed in terms of project data, even though most teams tend to use expert judgement instead. [ DemirersGencel09 ] discuss unified and improved methods for measuring the (expected) size of software -- Function Point Analysis. [ HeartyFentonMarquezNeil09 ] Advocate a Bayesian network to predict velocity in XP -- I've always liked the XP planning game because it is a ritualize negotiation between two experts, the programmer and the client, about what is the best mixture of features to implement later. [ Jorgensen09 ] writes about techniques for spotting over-optimistic bids for software development.

    So -- estimation -- in many forms is still a lively research topic, as well as something that all developers find themselves having to do.


    1. Magne Jorgensen & Barry Boehm
    2. Software Development Estimation: Formal methods or expert judgement
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp14-19


    1. Onur Demirors & Cigdem Gencel
    2. Conceptual Association of Functional Size Measurement Methods
    3. IEEE Software Magazine V26n3(May/Jun 2009)pp71-78


    1. Peter Hearty & Norman Fenton & David Marquez & Martin Neil
    2. Predicting Project Velocity in XP using a learning Dynamic Bayesian Network Model
    3. IEEE Trans Software Engineering V35n1(Jan/Feb 2009)pp124-137


    1. Magnes Jorgensen
    2. How to avoid selecting bids based on overoptimistic cost estimation
    3. IEEE Software Magazine V26n3(May/Jun 2009)pp75-84

    2009-04-17 Fri Apr 17 11:14 Something I would like time to try out

    Here is a report of how a software development company used open source methods and tools. Source forges sound very attractive. I've been tracking Open Source projects in the literature since 2000. For example [Ambler00j] reported on some source forge systems. You can search for "OPEN SOURCE" and find 20 or 30 citations.

    The evidence I'm seeing from those who have put an open source process with tool support is that they seem to provide teams with the benefits that individuals got from GUI tools and software IDEs. If there is a niche for "source forges" then it is in research projects rather than finished market-ready projects. And like most open source projects (in house or out sourced) the developers have to overlap with the users -- usage motivates the growth of features and the fixing of bugs.

    Perhaps my department should have our own internal source forge for developing student projects?

    I would like to spend time contributing to an open source project. But I don't seem to have time to do so. I'd also like to shift some my tools into an open source mode before I retire. I checked out [ http://sourceforge.net ] and searched for my particular interests in mathematics and logic. I found several projects ( HOL [ http://sourceforge.net/projects/hol/ ]

  2. and mathdevlanguage for example) which are on the system but effectively dead. There are several in the long tail of projects with one or two developers and even fewer users. Which is the rather sad state of my MATHS project.

    However developing traditional software through the early research phase seems to work well with an in-house source forge.


    1. Dirk Riehle & John Ellenberger & Tamir Menahem & Boris Mikhailovski & Yuri Natchetoi & Barak Naveh & Thomas Odenwald
    2. Open Collaboration within Corporations Using Software Forges
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp52-57
    5. Reports on the successful us of internal source forges in SAP, IBM, etc., to develop nsoftware -- mainly research projects.
    6. Principles: Egalitarian Meritocracy & Self-organization. Contrast with assigned work, status, and imposed process.
    7. A Source forge provides an easy way to discover projects that are going on and join them. It provides tools for collaboration with many different views of different artifacts. Each developers has a dash board displaying the status of the projects they are working on.
    8. Benefits: volunteers, motivation, better quality, broad expertise, Wins support and buy-in. Better researc-to-product transfer.

    2009-04-15 Wed Apr 15 11:53 Modelling parallel systems

    Over the last 4 decades we have developed several disciplines for analysing and design parallel systems. I've just seen a new text book on the topic. You can find out short formal descriptions of the algebras involved in my [ maths/math_73_Process_algebra.html ] page. The book uses a new language/algebra called μ_CRL.


    1. Wan Fokkink
    2. Modelling distributed systems
    3. Springer 2007 ISBN 978-3-540-73937-1 QA76.58 F65

    2009-04-14 Tue Apr 14 09:55 A Persistent Question -- does it work

    One persistent problem with software has been how you know that it is working. I was reminded of this while reading a paper on automating business processes (RobinsonjPurao09 below) and service oriented architecture.

    When I learned to program in the 1960s we did a lot of testing. We could also tag statements in our program to either provide debugging data or not provide it. In some platforms you could go to the console and push a button or flip a switch and a flood of data would come vomiting out of the tape printer or clattering onto the teletype. In less friendly form you would ask the operators to compile in the "traces" or "query prints" and then have to flip a virtual switch inside the code as the program run. I can recall an embarrassing run where I got the switch backwards. I thought it would start to print about 100 statements before the program crashed. But know, I got the logic twisted, and turned off the trace 100 statements before the bug. I had enough useless printout to keep me in scribbling paper for another 3 months... Looking back on that particular summer internship.... I'm surprised they offered me a job when I finished.

    Notice that the focus was on a temporary source of information on the internals of the code. When testing you could spend the extra CPU (and printer) time to see if all was well with the code as it ran. Once tested you would remove the tracing and run the program at full speed. Given the speed of CPUs in those days this made sense.

    During my graduate work I discovered Floyd's ideas [Floyd67a] about invariant assertions and discovered that given extra time I could prove that certain properties were always true. I didn't have to waste CPU time to monitor them. Since the hardware was delayed while I got on with programming I had time to insert all the needed "annotations" all thru the machine code that I produced and prove that once true they could never be false.... This part of the system never failed. But we are talking of about a days worth of thinking, algebra, and logic for each 50 instructions.

    Fast forward to the 1970's and C. The idea of tracing and invariant assertions merged in the C <assert.h> library. This is now the C++ <cassert> library. I didn't like it because it relies on run time monitoring rather than logic.... But something similar emerged for Ada. An extra language "Anna" was defined to record annotations -- invariant assertions:


    1. Bernd Krieg-Bruckner & David C Luckham
    2. ANNA: towards a language for annotating Ada programs
    3. Proceedings of the ACM-SIGPLAN symposium on Ada programming language 1980 pages 128-138 [ citation.cfm?id=948650 ]


    1. David C Luckham & Friedrich W von Henke & Bernd Krieg-Brukner & Alf Owe
    2. Anna, a language for annotating Ada programs: Reference manual
    3. Springer Verlag LNCS #260 1987 [ books?id=tybCNcTXmUkC ]
    5. "... applications include not only testing, debugging and formal verification of a finished program, but also specification of program parts during the earlier stages of requirements analysis and program design."
    Someone found a way to compile them as a parallel task that monitored the program as it ran. This apparently ound bugs -- I don't have a reference to my source, I think it was in SIGPLAN....

    Nowadays we have debuggers that provide many of the features I used in the 1960's onlu through a graphic interface. A lot easier. But I don't use them much. I find that a combination of logic and experience plus Test-Driven Development (with cassert) gets me to working C++ code pretty reliably. Work on the web relies on scripting languages and occasional self tests of my PHP pages.

    Now the same problem has emerged at a new level. When you have a solution assembled, dynamically, from distributed pieces supplied by different enterprises how can you be sure it works. What do you mean: "it works". Here is a recent paper with some proposals:


    1. William N Robinson & Sandeep Purao
    2. Specifications and Monitoring Interactions and commitments in Open Business Processes
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp72-79
    5. When many different components and/or actors provide services to each other ... with the network being dynamically configured, one must define the interactions precisely and monitor to see if they are being followed. For example, after a bill is sent to a customer, one expects to be paid...
    6. UML Sequence charts can show the protocols: patterns of messages.
    7. Add to this conditional commitments (CC) with four parts
      1. The actor who is committed to bring something about: customer.
      2. The actor who expects the the commitment: biller.
      3. The statement that becomes true: customer send payment.
      4. The conditions under which it becomes true: the biller billed the customer.

    8. Proposes a temporal logic extension to the OCL with clause like "after time until time...", "always....", "never ...", "eventually ...",
    9. By using existing logging service we can monitor the interactions and collect information on how well commitments are being kept.

    2009-04-13 Mon Apr 13 11:18 Eat the frog first

    Diomidis recalls a recent experience developing [ wpl ] and comes to a conclusion that I've slowly adopted:
  3. Tackle the risky bits early.


    1. Diomidis Spinellis
    2. Start with the most difficult part
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp70-71

    2009-04-10 Fri Apr 10 11:01 If this is the solution -- what was the problem

    One of the life's persistent question is what some software developers where thinking when the wrote the software. In many cases it is clear that they were thinking about the computer not the users. This was especially true back in the "bad old days" before Graphical User Interfaces. These days most software is designed to solve a problem for some class of user or other. We have a ton of techniques for working with our clients, finding out what they need (not necessarily what they say they want...), and coming up with solutions that work fairly well.

    We developed methodologies that tried to force programmers to look at real people and their problems write from the begginning. Systems Analysis is coeval with the first computers in the 1940s. The key belief of the discipline was that you should understand the system in which the problems are found before you try to fix them. And it had a theoretical basis in Bertalanfy's General System Theory.

    Systems Analysis became more rigorous with the structured methodologies of the 1970's: SSADM in the UK, Doug Ross's SADT, Gane & Sarson, etc. etc. All of these had to fight with the belief that you had to complete analysis (understanding the problem) before you wrote software. Seeing this only works where the problems are evolving slower than when the solutions can be installed... there was a tendency to abandon the analysis -- looking at the problems. Luckily Object-Oriented technology allows software to be highly modular so that a partial solution will remain pretty much untouched when later solutions are installed. Indeed there are strong arguments for going very directly from talking to the client to implemented code -- XP comes to mind.

    We have had many methods and technologies that sit between analysis and Design. In Computer Science they tend to be called a phrase with the word "Requirements". Thus we have the IEEE standards for "Software Requirements Specification" (SRS) which includes a format that covers all the basis [ SRS/ ] which my CSE department [ http://cse.csusb.edu/ ] modified to use in every student project at the 500 and above levels. My problem with this document is that is more focused on the solution than helping people solve problems.

    Here is recent discussion of alternate ways of recording what user's want.


    1. Catherine Riedeman & Regina Freitag
    2. Modeling Usage: Techniques and Tools
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp20-24
    5. Good survey of strengths, weaknesses, and tools for documenting how (and why) software will be used.
    6. Use_Scenario::=following,
      1. Combines the information documented in other techniques.
      2. Provides the user's problem and tasks as the context for their actions.
      3. A narrative table with 4 columns: Key task with subtasks, User Action, System Reaction, Usage Requirements and design hints.
      4. Can be embedded in systems like MS Visual Studio Team System 2008.
      5. Development process should include interaction design.
      6. Ref to W Dzida & R Freitag "Usability Testing -- the DATech Standard", in Software Quality... Ed M Wieczorek & D Meyerhoff 2001, pp 160-177

      (End of Net)

    Nowadays more and more systems are multimedia systems, and we have cheap tools for capturing mulitmedia information -- what users and clients are saying, what they are doing. The problem arizes in tracing back from the code to the reason for the code. So we have to integrate multimedia into text based tools.


    1. Olly Gotel & Stephen Morris
    2. More than Just "Lost in Translation"
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp7-9
    5. Need to elicit, record, analyze, and document requirements that include audiovisual records, videos, etc. These, in turn, have to be linked to design decisions and artifacts

    2009-04-08 Wed Apr 8 12:16 Busy times

    I was sick over the break and now have two large classes to teach.

    I will announce my schedule by the end of the week.... I hope.

    Meanwhile I've just noticed a new language -- Groovy [ http://groovy.codehaus.org/ ]

    There will some more on Groovy later since it is turning up in Comm ACM...

    2009-03-27 Fri Mar 27 14:44 Making Research Useful

    It is end of the Winter quarter at CSUSB, the students are leaving, the pigeons are nesting, and this blog will take a break until the evening of April the 6th.

    Meanwhile, here is an interesting suggestion: research should be evaluated, not just for accuracy and correct procedure, but also for its applicability. This would mean I would have more stuff to write about here -- it easy enough to find unsubstantiated recommendations for new tools and methods, and also easy to find rigorous research that doesn't mean much in practice. I try, in this blog, and its growing bibliography on results that are both reliable and practical.


    1. Robert L Glass
    2. Making research more relevant while not diminishing its rigor
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp96+95
    5. Michael Rosemann and Iris Vessey propose that teams doin research in some area should show their plans and their results to practitioners who carry out a reality check. They proposed this in "Toward Improving the Relevance of Information Systems Research to practice: the role of applicability checks" [MIS Quarterly (Mar 2008) pp1-22] and in the 2005 "European Conference on Information Systems".

    2009-03-25 Wed Mar 25 18:47 Reading and this Blog

    This blog came out of my need to save what Krutchen (below) calls "fieldstones". Pointers to things I have read and did not want to forget.

    My first bibliography was done for my Ph.D. and used small note cards, I still have it. I still remember the care I used to minimize the amount of typing, while still letting me to rapidly retrieve items on various topics. It was my first data base design.

    In the the early 1980s I started a bibliography on software development for a book on "Engineered Systems Software". I added references to my reading for another book -- a monograph [ monograph/ ] on software development methods. I moved this from a word processor file to a Macintosh Hypercard stack and added some search and data mining features that I've yet to duplicate in the current version. I wrote a script that dumped the bibliography to a file in my MATHS language... and so put it on this website with a simple search engine or two. It is 2.5Mbs now.

    As I enter new items into the bibliography, I report on them in this blog.

    So this little posting of mine includes a citation that will be copied into the bibliography:


    1. Phillippe Kruchten
    2. You are what you read
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp10-11
    5. Software development knowledge has a half-life of about 5 years -- 50% of today's knowledge will not needed in 5 years time.
    6. Value of reading -- not just Googling on the fly. Set aside time to read web, journals, and books of interest.
    7. Value of writing reviews.
    8. Need to take note and store the notes. Keep copies on hard-drive. Use file naming conventions.
    9. Track where important books have been loaned. Prominent Labels.

    2009-03-24 Tue Mar 24 08:40 Programmers code or design or both

    I just discovered the following contribution to the debate on what the propper function of a "programmer" is. Are they just "coders" converting some "Design" artifact into the source code for the software, or do programmers do design as they produce code. I wonder if there is any evidence one way or another works better.

    Personally -- programming includes coding and other important concerns....


    1. Daniel Read
    2. Software Design and Programmers
    3. developer.* March 20, 2003 [ read_designprog.html ]
    5. Notes that some see programmers as coders -- no design involved.
    6. Others argue that code always includes design decisions.
    7. Notes that agile methodists tend to think in terms of the design evolving or emerging from the code+test+refactor+test cycle.
    8. Also see [WhittakerAtkin02] that argues that software engineering texts do not mention code!

    2009-03-20 Fri Mar 20 14:51 Not a good week

    Sometimes it is the small things that foul you up -- both in real life and in software development. All programmers (well all but a very small number) have experience the effect of a missing sign in our code or the "off-by-one" error. This week my real life provided some examples.

    First to come to light was the fact that my iPod had lost all but too of its Contacts. The chain of causality was as follows:

    1. Apple has decided that if you don't synchronize a particular Address book then you want it deleted.
    2. I had changed the synchronization rules to only synchronise one address book with two items in it.
    3. I did that because synchronization was taking forever....
    4. Probably, this was when the iPod software was updated during synchronisation, silently, with no warning.

    Cure -- reset the synchronisation for Contacts and get all my phone numbers and EMail addresses back.

    Second, was discovering that my debit card had vanished. And here is the causal chain for that:

    1. It fell out of my wallet, probably while getting on a bus.
    2. The bus pass was in my wallet.
    3. And the plastic holder of the debit card was worn and torn, so that the card fell out easily.
    4. And I had not fixed it.

    So I've searched the areas by the bus stops, cancelled the card, repaired the wallet, and found an alternate place for the bus pass.

    By the way -- this follows the classic list of fixes needed for any problem:

    1. Band aid.
    2. Repair.
    3. Long term avoidance.

    Finally -- after cancelling the debit card, I discover, (going to synch my iPod) that I didn't have my special VDT/Computer glasses at home. But I expected to find them in the bag I use to go to class -- full of chalk, pens, pointers, etc. But they are not in my office. Or in any of the rooms where I taught yesterday, or on any of the routes I walked yesterday... Now I don't know how this happened but I think a prime suspect is the battered ICSE tote bag I used. So, I've just repacked everything from that bag into a red SIGCSE 2005 bag that can be zipped closed.

    Well -- typing this in bifocals is a pain.... so a bibliographic item will be posted on Monday, with luck.

    Thank you for listening.


    And then I swept an old OReilly UUCP mug of my desk smashing it....

    2009-03-19 Thu Mar 19 04:59 One size does not fit all

    I've collecting examples and evidence that there is no one methodology or process that handles all software development for 13 years now. If you search my bibliography for "one.size" you'll get a couple of dozen references. I think that [Royce70] in the 1970s was the first to make this claim.

    In 1995 I presented a faculty seminar here at CSUSB [Botting95b] (HTML at [ rjb95b.one.size.html ] ). I ended up with a model distinguishing 8 different cases depending on the number of competitors, the strength of the contract and the number of customers:

    [Box with 8 compartments]

    Here is a table desicribing the same idea

  4. Winning_devlopment_strategy::=following,
    Contract#CustomersFew SuppliersMany Suppliers
    loosefewUnique featuresLow cost+Quality
    loosemanyFirst to MarketNew features + Many releases
    tightfewProven CapableLow cost with fixed quality
    tightmanyFirst in takes riskHighest Quality

    (Close Table)

    So I'm pleased to see another article making the same case and making a new distinction between "development methodologies" and "engineering methodologies".


    1. Andrew Anguelo
    2. Software Methodology Wars (Viewpoint)
    3. IEEE Computer Society Career Watch Mailing list (Mar 2009) [ vp4 ]
    5. Quote
        Development is based on iterations of trial and error in the absence of knowledge and facts. It most often found in organizations that don't value their software technology as a critical business asset and treat it as a necessary evil or a cost of doing business. Business executives in these types of organizations operate very much like those during the dot-com boom days. Itbis based on iterations of trial and error in the absence of knowledge and facts. It no surprise that today's more popular development methodologies are based on principles that shun documentation, engineering thought patterns, and encourage the use of loosely conceived ideas in production environments under the guise of flexibility.


        Engineering methodologies are much more methodical than development methodologies. Consideration of past, present, and future, as well as adherence to standards and practices are all core principles of software engineering. Although not perfect, these methodologies facilitate the design of systems with intent and that embody the characteristics of reliability, maintainability, and scalability. Such results come at a price however.

      (End of Net)

    6. (dick)|-Ignores the claim that refactoring software can maintain the quality of software.

    2009-03-18 Wed Mar 18 19:21 How to use off-the-shelf components

    In the world of software development there are many theories -- and most of these theories are normative Theories -- they state that developers should do something. Notice the should this is setting a norm -- hence normative. Thus, for example:
    1. You should use top-down stepwise refinement.
    2. You should place each design decision inside its own module.
    3. You should only use the three D-structures.
    4. You should use data directed design, two versions, one in the 1970s and later in the 2000s.
    5. You should use a object-oriented software.
    6. ...

    Now it is much harder to come up with theories about what actually is. But here is an example which compares the use of "Off The Shelf" components in the classic normative theories vs what was actually done in some companies. Notice -- the research shows what is, and does not suggest what should be. These experimenters uncovered that previous "should"s do not match the real "is"s.


    1. Jinguin Li & Reidar Conradi & Odd Petter N Slyngstad & Christian Bunse & Marco Torchiano & Maurizio Morisio
    2. Development with Off-the-shelf Components: 10 Facts
    3. IEEE Software Magazine V26n2(Jan/Feb 2009)pp80-87
    5. Companies don't change their process because they are using OTS components... they just add special integration steps.
    6. Components are selected informally.
    7. Components are integrated into a system both early and late in the process.
    8. Estimates are base on personal experience.
    9. OTS components usually don't degrade system quality.
    10. OSS and closed proprietary OTS components are used the same way -- no rewriting the open source parts.
    11. Locating and debugging defects is substantial.
    12. The supplier is involved in more than bug fixing during maintenance.
    13. Clients are not usually involved in OTS selection.
    14. Knowledge about non-fucntional properties of OTS components must be managed.

    2009-03-16 Mon Mar 16 18:18 The Why of Software

    The following part of IEEE's latest Software magazine provides more evidence for the need to make design decisions in a rational way and to capture them for when the software is changed. The need is fairly obvious even if the means for meeting the need is not clear. Can we embed the reasonning behind a particular design into executable code as the Agile hope, or do we need complex tool and language based on logic and philosophy -- as tool vendors say. And what do you do when a large mass of monolythic code has accumulated so much technical debt that you have to impose an architecture on it? These articles touch on all of these and more.


    1. Uwe Zdun (Guest Editor)
    2. Capturing Design Knowledge (Special Section)
    3. IEEE Software Magazine V26n2(Mar/Apr 2009)pp25-49
    5. Argues that between the requirements and the software comes a number of design decisions and that the reasoning behind them may be lost.
    6. Also notes that software rots if it is not looked after well.
    7. Titles
      1. Capturing Design Knowledge
      2. Modularization of a large-scale business application -- A CAse study
      3. The Decision View's Role in Software Architecture Practice
      4. Software Architecture Design Reasoning: A case for improved Methodology Support

    2009-03-13 Fri Mar 13 15:31 It is Tool Time Online

    If you want to know about websites about software engineering tools and IDEs you can do better than the following


    1. Mark Doernhoefer
    2. Surfing the net for software engineering notes: Tool Time
    3. ACM SIGSOFT SEN V34n1(Jan 2009)pp7-16 [ 1457516.1457519 ]
    4. =SURVEY TOOLS Eclipse NetBeans MySQL PostGresSQL Apache Tomcat JBoss Caucho Resin ArgoUML C# .Net Subversion CVS FindBugs PMD Pentaho W3C VALIDATION LINK CHECKER

    2009-03-12 Thu Mar 12 06:03 This just in... Barabara Liskov wins Turing Prize

    The source of the Liskov Substitution Principle for OO design and languages has been selected by the Association for Computing Machinary's most prestidgeous prize for 2009.

    [ 7937010.stm ] (Thank you Alexander)!

    2009-03-12 Thu Mar 12 06:03 Samples/methods updated

    [ samples/methods.html#ALD ] [ samples/methods.html#iterate ]

    2009-03-11 Wed Mar 11 19:03 SMOP -- Small Matter of Programming

    I was planning to write about Michael Wing's quirky article showing how a simple C program can generate many thousands of K of working code for a data base application. Then I discovered that I didn't have a good example of the "Gang of Four" State Pattern , and that the Wikipedia seems to be stuck in a controversy of what it is. So when I got to work this morning I sketched out a State Chart for a combined light and heater I met some years ago in England... and by lunch time I had a UML Design Class Diagram [ cs375/StatePatternExample.html ] in Visio. Now, as part of teaching PSP last year I have a logging process running that collects statistics on all files that I compile or render into HTML etc. So I know that I started coding the test at 1:04pm with 15 lines, and finished with a 36 line test by 2:46pm. Meanwhile the actual code defining the classes (all in one file ready for the web....) [ cs375/State.cpp ] had grown from 29 lines at 1:06pm to 141 lines by the end of the session at 2:46pm. So that is roughly one line of tested code per minute. Then back to the drawing board to reverse engineer that discoveries back into the UML diagram I had started with. Basically I added classes to output some behavior when exercised in the test program.

    Conclusions: (1) Expressing the State pattern (at least this version) in C++ taught me much about what must be defined in a class before you can do certain things in it. It was like having my nose rubbed in the need to split the headers from the bodies -- all over again.

    (2) OOP is verbose.

    (3) perhaps lazy evaluation might be better in this case -- each State class is a Singleton. Note -- I have old code that creates a new State with each transition which causes a large memory leak. But that was a HHOS demonstration of concurrency -- four singers singing "Boom Ooh Yatata".... I may update it to a better code later.

    (4) Perhaps it is time to complete my dictionary [ cs375/patterns.html ] of patterns and principles.

    So -- yes Software development is all about code -- but drawing the design first made the coding into a SMOP -- Small Matter Of Programming.


    1. Michael Wing
    2. SE Means Programming
    3. ACM SIGSOFT Software Engineering Notes V34n1(Jan 2009)pp5-6 [ 1457516.1457518 ]
    5. CGWOP::=Code Generation without Parsing.
    6. Repetitive code should be generated by a program rather than written

    2009-03-09 Mon Mar 9 19:03 Power laws in Software

    I've been seeing a lot about power laws in networks for several years ago. Now we have a thoruough investigation of the statistics of connections between modules (classes, libraries, subprograms) accross a range of projects that demonstrates that these rules are pretty ubiquitous. This implies, in turn that 80-20 lawers will fit as well -- the working rule that 80% of the beer is drunk by 20 percent of the people is apparentlly confirmed by these results.


    1. Panagiotis Louridas & Diomedis Spinellis & Vasileos Vlachos
    2. Power Laws in Software
    3. ACM TOSEM Trans Software Eng & Methodology V18n1(Sep 2008)#2pp1-26 [ 1391984.1391986 ] published Sep 2008
    5. One piece of code has a number of references to other pieces of code...
    6. One piece of code is refered to or used by other pieces of code...
    7. Suppose we tabulated how many refrences were made to or by a module to another then we get close to a simple rule.
    8. In a power law
    9. P( X = x) = c * x**(-k) for some constant c and k>0.
    10. Or equivalently we have:
    11. P(X >= x) = c * x **(-(k+1)).
    12. Compare [ConcasEtAl07] (not mentioned).
    13. As a rule the distribution on references to a module has a smaller k and a better correlation.
    14. The distribution of the number of references made by a module to others do not fit as well and k is bigger.

    2009-03-06 Fri Mar 6 15:03 Network effects on Searching and marketting games

    Here are two articles describing trends in our increasingly online life. One describes how the network allows games to be published and marketted publishers or advertising agencies. The other describes the increasing power of one search engine and why this raises ethical questions. Both are about the right for anybody to get access to everybody. Very much the area carved out by Clay Shirky, See [Shirky03] and [Shirky08] for example.


    1. Chris Swain
    2. Who Needs a Publisher or a Retailer or a Marketeer
    3. IEEE Computer Magazine V42n2(Feb 2009)pp103-105
    4. =ESSAY OPEN MARKETS ECONOMICS iPhone apps Xbox Live Community Valve Software Steam
    5. Risks of your product disapearing in a flood of others... iPhone has 10k apps already. Hence many cheap and simple apps... complex apps may not get the exposure to make a profit.


    1. Abbe Mowshowitz & Nanda Kumar
    2. And Then THere were Three
    3. IEEE Computer Magazine V42n2(Feb 2009)pp108+106-107
    5. Can Google be sued for not showing a relevant page to people looking for it?

    2009-03-04 Wed Mar 4 18:03 History of Barcodes

    Another intriquing tour through technological history demonstrating the almost arbitrary, and totally unromantic ways that some technologies come to be and then are mainstreamed.


    1. David A Grier
    2. Scanning the Horizon
    3. IEEE Computer Magazine V42n2(Feb 2009)pp8-10

    2009-03-02 Mon Mar 2 20:03 Trying to envisage agile software development

    It is interesting how hard it is to learn iterative and evolutionary methods. No amount of examples and descriptions seem to help. So I thouhght for a while and came up with the analogy of eating a large cake

    [A cake]

    To get the real cake try the recipe at [ recipeDetail.asp?RecipeID=865 ] (I haven't tried it.....)

    Now in software cevelopment it is more like this

    [3layered cake = requirements+design+code with tests on top]

    Now some people just like to eat the top part: coding and testing and hoping that omitting the design and requirements analysis can be ignored.

    According to the dogmatic "waterfall" model we take it alyer by layer:

    [Layer by layer, bottom up]

    But the agile/iterative/evolutionary methods are more like we normally eat a cake: one slice at a time, each slice with a bit of requuirements, a bit of design, and a bit of coding.... to say nothing of a cherry on the top = tests.

    [Slice by slice]

    Now this doesn't prove anything.... but it may make the difference between the different approaches clear. Let me know what you think....

    2009-02-25 Wed Feb 25 20:02 TeX MathML MATHS -- Mathematics on the web

    This rant comes (1) from reading Brian Hayes article on the start of the art of displying mathematics on web pages -- summary: not good, (2) From getting a thesis in my Email for reading and comments -- in ΤΕΧ and rediscovering that I don't have access to a functional system for viewing such documents, and (3) my own attempts, for most of my career, to formulate a system for encoding logic and mathematics using ASCII.

    Using Donald Knuth's ΤΕΧ gives elegant and intelligent layouts for formula, equations, chapters, sections, subsections, contents lists, and so on. All very laudable in a world of paper and chalk board! But doesn't give me what I want:

    1. Hypertext links between: terms and definitions, labels and formulae, theorems and proofs, names of algebras and their descriptions,
    2. A checkable proof system.
    3. Access and linkages over the web.
    4. Reuse and inheritance of logical/algebraic systems

    Brian Hayes describes MathML and where that has got to. It is a verbose notation for formulae that is not honored by any "real" browsers. It does not provide the structures that I'm interested in for connecting formula into a narative: variables, axioms, theorems, etc. as far as I know so far.

    My own attempts (MATHS) are illustrated by the fact that I use the language for this blog It uses standard HTML but is defeated by certain browsers. For example, one of Maxwell's equations is written like this in ΤΕΧ:

          \nabla \times \mathbf{E} = -\frac{\partial \mathbf{B}} {\partial{t}}.
    (This is in Brian Hayes's paper). To render it for a browser I'd have to translate the ΤΕΧ into a graphic and place it as an image in this document, or include one of the server- or client-side tools Brian mentions. On the other hand, there is a lot to be said for writing papers in ΤΕΧ, going to the effort of installing a LaTeX based set of tools, and learning ΤΕΧ.

    In MATHS I write:

       \nabla >< E = - \partial B / \partial t.
    As you can see I stole the ΤΕΧ sysntax for encoding weird sysmbols.

    My "mth2html" tool, or my [ hole.html ] web tool will render it into standard HTML (even Nabla is an HTML entity!) so that it looks like this

  5. ∇ >< E = - ∂ B / ∂ t.

    Now on many browsers it will be instantly readable but not a beautiful (I'm told) as the rendered ΤΕΧ version. On the versions of MicroSoft Internet Explorer (and without some fonts?) the Nabla appears as a box.

    So basically, we have a long way to go before we have the system that I dreamed about when trying to record my Formal Languages and Automata notes in computer readable form during my graduate work in the late 1960's.


    1. Brian Hayes
    2. Writing Math on the Web
    3. American Scientist V97n2(Mar-Apr 2009)pp98-102
    4. =ARTICLE HTML ΤΕΧ TeX MathML JsMath FONTS techexplorer
    5. Problems with putting formulae onto web pages.
    6. Where to render the formula: author, server, or client?
    7. Client: Plugin(techexplorer), fonts, special script (JsMath). Rely on user having the plugins and fonts to work.
    8. Server example -- Wikipedia uses texvc, MathTeX, MimeTeX. All make graphic images. reliable and ugly.
    9. How to render: as a graphical image or using Fonts or Unicode?
    10. Failure of MathML to become mainstream.
    11. (dick)|-Failure of ΤΕΧ to express hypertext markup.
    12. (dick)|-No formal syntax and semantics for proofs and logic in ΤΕΧ or MathML
    13. (dick)|-Still like my MATHS language.

    2009-02-23 Mon Feb 23 19:02 Visiting Speakers Wednesday

    Date February 25th 2009 Time 12-2pm Location College of Education 110
      12-1pm Yair Censor is highly respected mathematician and a prolific researcher. Dr. Censor has published over 100 research articles in refereed scientific journals, conference proceedings and as book chapters. B He will be speaking on some recent work he has done on total variation (TV) algorithms entitled:

      Projection Methods: Perturbation Resilience and TV-Superiorization

      1-2pm Gabor Herman is an internationally renowned mathematician and computer scientist for his work in image processing. B He was a pioneer in computed tomography, and developer of the algebraic reconstruction technique (ART), as well as several other reconstruction algorithms. B His talk will be on:

      Finitely Convergent Sequential Algorithms and Their Applications to Intensity Modulated Radiation Therapy

    Note: I've updated [ [SaariluomaIsomki08} ] on HCI design.

    2009-02-18 Wed Feb 18 20:02 Busy Days

    It's a kind of triple witching hour/day. My university is in the throws of Spring Advising, I've chosen a form of teaching that involves answering a lot of questions on web sites, and I have had to prepare a review of the book cited below.

    And as I typed the above, something broke betwen my DSL and the remote login server on campus and killed the edit. Luckily I use an editor that has a recovery function.

    As to the book.... too much philosophy, and for details wait for my reviews in CR!


    1. P Saariluoma & H Isomki
    2. Future interaction design ii (1st ed.)
    3. Springer Publishing Company, Incorporated, 2008

    2009-02-16 Mon Feb 16 16:02 Defects of current software technology

    A well known authority -- he has appeared 14 times in my bibliography so far -- famous for distinguishing the orders of ignorance and knowledge -- has just published an article on the defects of current tools. I've been hoping and expecting to see a non-text based way of developing software since the end of my graduate work in 1971. And here is the fact that worries me -- nobody has ever succeeded in mainstreaming a soup-to-nuts tool for developing software. Many people have tried -- see some of the historical backfill in this blog -- but none have displaced source code. Why? Are programmers so locked to text that nothing else sells? Is it just that we don't have a good graphic representation for software? Perhaps we need to able to work within a 3D virtual world to model software properly? In fact it might be 2*n dimensional where n is the number of parallel parts?


    1. Phillip G Armour
    2. The Business of Software: The Ontology of Paper
    3. Commun ACM V52n1(Jan 2009)pp23-24 [ 1435417.1435427 ]
    5. Claims that the industrial revolution did not occur until steam engines were used to create steam engines. Claims that current software technology tends to reproduce the defects of paper-based artifacts.
    6. Describes the properties of paper artifacts: difficult to link artifacts, not executable, not easily verifiable, serial access, imposes a hierarchical structure, places information within a linear context, inherently single-tasking, ...
    7. Even hypertext does not relax these constraints.
    8. Claims that older systems fitted the paper model well.
    9. New systems need the external linkages and executability of software.

    2009-02-13 Fri Feb 13 09:02 Human Computer Interfaces and Psychology

    One of the purposes of this blog and bibliography is stop the way we continuously bury past experience -- even when published.

    I've been reading a book (more on that later) that claims that the time (2009) has come to apply scientific psychology to interaction design. It took a while to find the spirited discussion of this topic in the Communications of ACM back in 1982.... but here it is. I'm taking this opportunity to update the bibliographic item for the original article by Barry Dyer.


    1. A M McMahon
    2. Behavior Modification in Programming (Forum)
    3. Commun ACM V25N6(Jun 1982)pp400-401 [ 358523.358556 ]
    5. Doubts the morality of behaviorism in HCI as expressed in [Dwyer81]
      1. Using behavioral psychology in HCI is like an automobile engineer using a jointed wooden dummy.
      2. By using it people started to like my work.
      3. "Systems that are aversive to users are destined to fail, even if they are technically perfect."
      4. Common false assumptions: People are rational, Computer save work, users out to wreck the system, computer diagnostics spot the problem

      (Close But )

    2009-02-11 Wed Feb 11 20:02 Ethical Dilemmas

    Here is a nice essay on the ethical dilemmas that confront software developers. It also notes that many developers are not members of the two main professional software bodies: the ACM and the IEEE -- and so are not bound by their codes of ethics.

    There is something horribly familiar about their list of defective behavior patterns.


    1. Brian Berenbach & Manfred Broy
    2. Professional and Ethical Dilemmas in Software Engineering
    3. IEEE Computer Magazine V42n1(Jan 2008)pp74-80
    5. Named dilemmas
      1. Mission impossible
      2. Mea Culpa
      3. Rush Job
      4. Not My Problem
      5. Red lies
      6. Fictionware versus vaporware
      7. non-diligence
      8. Cancelled vacation
      9. Sweep it under the rug

    6. Proposes mitigation strategies.
    7. Failures of the ACM and IEEE Codes of Professional Behavior.
    8. Notes likely criminal behaviors: Negligent homicide, reckless endangerment, depraved indifference.
    9. Ethical dilemmas tend to be yoked, chained, or coupled.... and this magnifies the damage.

    2009-02-09 Mon Feb 9 18:02 Meetings

    Phillipe Kruchten's latest article in IEEE Software on meetings gives me a perfect excuse to revisit two of my favorite books and a recent acquisition on the same topic. Kruchten's article is based on Robert's Rules of Order... a book I have yet to read without falling asleep. However the rules of procedure for meetings is a fascinating study.

    When I was at college in the 1960's the Student Union rewrote its constitution and we spent many hours discussing "Standard Orders" -- the default procedures for meetings of the student union committees and of all its clubs and societies. The Philosophy Club for example always made use the Standing Order that let Standing Orders be suspended if enough people voted for this motion to open a free and unstructured discussion (typically in a pub). My first or second publication (in the Student paper) demonstrated that a simple automaton could track the state of a meeting under "Standing Orders" and noted the need for a set of stacks to handle points of order being made about points of order....

    But I cut my teeth on Parkinson's little essays on how organization grow and fail, and his advice on how to succeed. I've learned that satire and humor contains a lot of clues to the truth. And then last week I picked up Stephen Baker's description of why he hates meetings.

    I will not go into all the specialized types of meetings I have noted over the years. Perhaps another day.


    1. Philippe Kruchten
    2. When Robert Rules
    3. IEEE Software Magazine V26n1(Jan/Feb 2009)pp20-21
    5. Source [ Robert%27s_Rules_of_Order ] (Henry M Robert, 1837-1923)
    6. Principles
      1. Scope the meeting: agreed and prioritized objectives.
      2. Tackle one issue at a time. Focus on pro and con of one proposed idea.
      3. Get Closure on issues. An agreed conclusion. (1) evolves (2) Ratified.
      4. Be flexible. A way to modify a proposal.
      5. Know when to stop or defer a decision.
      6. Remember what was decided. Minutes or other artifacts.
      7. Know how to undo a decision. Rescind.
      8. Dealing with difficult situations. Need chair/facilitator. Points of order. Politeness, Address the topic not the people.


    1. C Northcote Parkinson
    2. Parkinson's Law or the Pursuit of Progress
    3. John Murray London England 1958
    5. |- (ParkinsonsLaw): Work expands to fill the available time.
    6. The time spent on an item in a committee is inversely proportional to the cost.
    7. When an enterprise moves into a custom-built head-office it is dead.
    8. Incompetence is determined by the age of retirement and starts 5 years before.
    9. The outcome of a meeting depends more on the seating than on the merits of the opposing views. Surround weak people with your own people....
    10. Also see [ParkinsonCN62]


    1. C Northcote Parkinson
    2. In-laws and Outlaws
    3. John Murray London England 1962 + Penguin 1965
    5. Demonstrates that it is best to get your superior to have your brilliant ideas.
    6. Shows how to take advantage of people being late and how to plan: Work backwards from the most important event, subtracting the durations as you go.
    7. How chairpeople get their will: Inanimism, Blahmanship, Browbeatnicism, Confusionism.
    8. How to try and handle the tsunami of paperwork as you get promoted.
    9. Do you have what it takes to be CEO? Can you sack a really nice person who is incompetent and still sleep at night?
    10. (ParkinsonsThirdLaw): Expansion means complexity and complexity means decay.


    1. Stephen Baker & Arnie Levin
    2. I hate Meetings
    3. Macmillan NY 1983 ISBN0-02-506370-7
    5. Good explanation why people hate meetings.
    6. Confirms purpose of meetings: too spread the blame/responsibility widely.
    7. Chapter 8: good field guide to problem people from the chair's point of view: Speech maker, Yawner, Bottom liner, Devil's advocate, Early leaver, late-comer.

    2009-02-06 Fri Feb 6 15:02 Open Source quality management and effort

    Nice bit of statistical analysis of open source projects.


    1. Eugenio Capra & Chiara Francalanci & Francesco Merio
    2. An Empirical study on the relationship among Software Design Quality, Development Effort, and Governance in Open Source Projects
    3. IEEE Trans Software Engineering (Nov/Dec 2008)pp765-782
    5. In open source there is a continuum of governance practices.
    6. Conclusion: Better quality code permits looser governance but that in turn takes effort to coordinate loosely governed people.
    7. (dick)|-results are unlikely to happen by chance but the causality may be reversed.

    2009-02-04 Wed Feb 4 18:02 Ontologies and the Tree of Porphyry

    I'm a little cynical about attempts to nail down semantics without reference to stuff outside the computer. So the Semantic Web will surprise me if it arrives. However, this article on the ontologies that have been and are been developed to provide meaning to web pages had an interesting discovery it. Briefly, I have used a tree-like structure as a theoretical semantics and/or ontology for 10 to 20 years -- purely out of belief we had expand formal logic in the direction of natural language.... Anyway this turns out to be ancient, dating back a thousand or so years -- the Tree of Porphyry.

    So here is the citation with links...


    1. Ian Horrocks
    2. Ontologies and the Semantic Web
    3. Commun ACM V51n12(Dec 2008)pp58-67 [ 1490360.1409377 ]
    5. Figure 2:the Tree of Porphyry [ Tree_of_Porphyry ] (Wikipedia) and [ Stuff in logic_8_Natural_Language ] (MATHS)
    6. RDF expresses labelled directed graphs: subject --(verb)--> Object. What we used to call semantic nets in the 1970s.

    2009-02-02 Mon Feb 2 20:02 Computer graduates and quality Requirements

    So after years of forcing computer science students to accept the ambiguous "specifications" that we use for programming exercises and do the best they can with them..... is it any surprise that they miss defects in real requirements?


    1. Jeffrey C Carver & Nachiappan Nagappan & Alan Page
    2. The impact of educational background on the effectiveness of Requirements Inspections: an empirical study
    3. IEEE Trans Software Engineering V34n6(Nov/Dec 2008)pp800-812
    5. Provides good evidence of a couple of useful facts:
      1. People who have written requirements are better at finding defects than people who have not written them.
      2. People with Computer or Software Engineering degrees are worse at find requirements defects than those who have other degrees.

    2009-01-30 Fri Jan 30 15:01 Correction to previous blog item

    OK.... I didn't mean to say that the people who taught me software development in the 1960's should have read a paper published in 1970.

    Let me say what I was thinking.... I was taught to program, using no method in a Stats class in 1964. Or more precisely, we wrote a simple program, compiled it, ran it, wiped out the compiler and reloaded it, retyped it, ran it, ..... and iterated from then on. In a Numerical Analysis class I learned flow charting. Then into an industrial period working for the Brittish National Physical Lab using Algol 60 to program a stats application and rocking a model boat (fun). No flow charting stencils -- I should have started a company.... I wrote one program and it took the whole 6 months... mainly debugging.

    In my second industrial period (summer 1964) I monitored the progress of my programs thru the classic: Analysis->Design->Code->Test-> Release SDLC and found that every one of them (with one exception) got stuck in the "Test" phase. I decided that it was because I did not spend enough time in the "analysis" and "design" steps.

    Now I don't recall being taught the SDLC above. I did write a report at the end of the period defining it as the standard way to develop software.

    Now, the key point: no online terminals, no PCs. A test run took a minimum of 24 hours... in a worst case several days or a week could go by before the operators could run a test for you. Production work had to come first.

    Hence it made a lot of sense in those days to put the efort up front to try and minimize the number of tests.

    Oh, for a time machine... Read on to the previous entry below.

    2009-01-28 Wed Jan 28 19:01 The Myth of the Waterfall Process

    I wish that the people who had taught me software development and the "waterfall process" had actually read the following paper. As it is I've only just found a facsimile on the web and spent a couple of weeks studying it. I'm upgrading my bibliography to match the description below. It looks as if all data, even bibliographies, must evolve. And that iteration is the best way to get an accurate result.


    1. Winston Royce
    2. Managing the development of large software systems
    3. Proc IEEE WESCON (1970) pp328-339 [ royce.waterfall.pdf ]
    5. This is the seminal paper on software processes. It has been widely quoted as proposing the "Waterfall Process" when it argues that such a process does not work and proposes alternatives.
    6. p.335: "In my experience,however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed."
      1. Complete Program Design before Analysis and Design begins.
      2. Documentation must be current and complete.
      3. Do the job twice if possible.
      4. Testing must be planned, controlled, and Monitored.
      5. Involve the Customer

    2009-01-26 Mon Jan 26 18:01 On the Evolution of software

    I've just read David Alan Grier noting evolutionary fervor everywhere -- [Grier08a] in the IEEE Computer Magazine (Dec 2008) plus an example [DenningEtAl08] (Communications of the ACM Dec 2008) of using evolutionary development in a large USA government department. Note: if you develop software for the USA federal government I think you need to know about LTE -- Limited Procurement Experiments! Both are recommended.

    Too say nothing of previously reported [ HamiltonHackler08 ] [ Gabriel08 ] [ Martin09 ] that also praise evolutionary/iterative processes.

    I was planning to write about switching from a Palm to an iPod... and that got me back to a paper I wrote on the evolution of software for a faculty workstation [Botting85c] but I decided to return to the PDA functions topic after rescuing two other papers from the 1980's demonstrating evolutionary/iterative processes. These were published in a west coast regional conference on educational computing. It seems to have died. The paper [Botting84b] demonstrates how I took a simple editor for my students [Botting85a] and made it easier to be used by repeatedly replacing error messages by guesses at what the user wanted to do. I've taken these two papers and scanned them in through OCR software and marked them up for my MATHS language and hence onto the web as [ papers/rjb84a.FRED.html ] (the Friendly editor) and [ papers/rjb84b.Generalization.html ] (Generalization - An Alternative to Error Messages).

    Enjoy. Comment....

    2009-01-23 Fri Jan 23 14:01 Speeding up your web site

    Here is an article worth reading if you have customers complaining about the speed of your web site


    1. Steve Souders
    2. High-Performance Web Sites
    3. Commun ACM V51n12(Dec 2008)pp36-41 [ 1490360.1409374 ]
    5. Describes (briefly) 10 rules
      1. Make fewer HTTP requests
      2. Use a network to deliver content
      3. Add an Expries header
      4. Gzip components
      5. Put stylesheets at the top
      6. Put scripts at the bottom
      7. Avoid CSS expressions
      8. Make Javascript and CSS external
      9. Reduce DNS lookup
      10. Minify JavaScript (remove whitespace...)
      11. Avoid redirects
      12. Remove duplicate scripts
      13. Configure ETags
      14. Make Ajax cacheable

    6. More in the author's recent book...

    2009-01-21 Wed Jan 21 19:01 Recent Writings on Writing

    I've recently been studying three different explorations of code writing. Jeff Atwood pointed out that coding is just writing. Peter Gabriel flies in the face of conventional wisdom at OOPSLA by suggesting that good design does not come from a single designer's vision, but from a dialog between at least two entities. Even a single programmer working alone will be interacting with the code. I spent the whole winter break studying Uncle Bob's latest book "Clean Code" which perfectly illustrates the dialog between the programmer and the code as it is refactored. I recommend them all if you work with code.


    1. Jeff Atwood
    2. Coding: It's just writing
    3. coding horror nov10th [ 001184.html ]


    1. Richard P Gabriel
    2. Designed as Designer
    3. OOPSLA 2008 & SIGPLAN Notices V43n10(Oct 2008)pp617-632
    5. Refs Brookes -- Conceptual Integrity comes from having a single designer.
    6. Gives examples of design emerging from collaboration and help.
    7. The importance of listening to what the product/design is saying.
    8. Design is at least a dialog between Designer and the Designed.
    9. Example: That dome in Florence, TS Elliot and E Pound, ...
    10. Did not mention Umberto Ecco's "Foucalt's Pendulem" arguing the importance of editors.... (dick).


    1. Robert C Martin
    2. Clean Code: A Handbook of agile software craftsmanship
    3. Pearson Education 2009 Boston MA ISBN 0-13-2350088-2
    5. Demands study but tends to change the way you look at code.
    6. All examples are Java 6 but it changed my C++ standards.
    7. Stresses the iterative and evolutionary nature of code -- enhancement and refactoring as the constant change.
    8. 90% is well known advice dating back 30 years.
    9. Some of it is startling
      1. Comments should be reduced in favor of more better named functions and variables.
      2. Objects and data structures are different: Objects hide data and provide functions, but data structures give access to data and have no other function!
      3. Writing tests is a good way to learn an API and pays for itself by proving documentation.
      4. Refactoring an SQL class leads to a functional decomposition of classes into subclasses.
      5. "Inversion of Control" and "Dependency Injection" -- dependencies are created at run time.
      6. Use Domain Specific Languages at the systems level.

    10. Good list of smells and heuristics in Chapter 17.
    11. Notes and recommend an interesting property of Java 5 "enum"s -- can specify functions that return different values for each value in the enum. Better than "switch".

    2009-01-14 Wed Jan 14 20:01 Top 25 most dangerous programming errors

    A short entry today, about dangerous mistakes that people make when developing web sites. It starts with a carefully done survey that ranks errors in terms of the risks involved, however this link [ top25 ] takes a long time to download. There is a lot of detailed information. But "Coding Horror" had an entry that summarizes these mistakes: [ 001210.html ] that is both quicker to download and easier to read.

    Recommended to anyone doing anything more complex than plain HTML on their web site.

    I'm planning some longer entries when the new term has settled down. One on the value of evolutionary and iterative processes. Another on the topic of writing software and coding style. There will also be something on speeding up web sites.

    So watch this place...

    2009-01-12 Mon Jan 12 18:01 Examples of User Hostile Systems

    I've just spent a painful couple of days picking up the online resources that come with a text book that I am using. I had to register on two different sites -- and of course I made sure not to use the same password. I had to supply superfluous information. Then both sites sent me confirmation EMail complete with their own password en clair ready for every hacker from here to Long Beach and back to the East Coast to sniff it. So I thought it wise to log in to the sites and change the passwords (and hope that they would not Email them...). You will have had similar experiences. So has today's featured author below. Well worth a read.


    1. Simone Santini
    2. Madrid's Brilliant Idea
    3. IEEE Computer Magazine V41n12(Dec 2008)pp128+126-127
    5. Gives an example how a combination of too much security, too many assumptions, and trying to stop you from leaving a web site leads to a system not being used at all.

    2009-01-11 Sun Jan 11 13:01 Another hiatus

    The dept web server has been down.... this is a test post to see if it is 100% up yet.

    Erick Behr has spotted a typographical error in my [ syllabus.html ] generic syllabus. I've fixed it but won't be able to publish the result until I can upload changes to the web server.

    2009-01-07 Wed Jan 7 19:01 Methodology remembered

    When I read HamiltonHackler08 below I was reminded of an over-hyped program development method I had seen in books and articles in the 1980's. The Apollo mission at NASA had discovered that most programming errors where incorrect interfaces between "modules". They developed a mathematical/logical model for systems which allowed functional decomposition and a tool for checking the correctness of the discussion. Functions were described in terms of their name and there inputs and outputs. For example, MUL might have two numbers X and Y as input and a single number PROD as an output. To solve a quadratic equation
  6. a*x^2 + b*x + c =0,

    one would have three inputs: a,b,c and two outputs: root1 , root2. Part of the computation finds the discriminant

  7. Δ := b^2 - 4*a*c.

    And so on into more and more detail.... down to multiplying a by c.

    This was for programs written in machine code.

    The tool would check that all the data for the calculation of Δ was available, and that Δ was available before it was used.

    After Apollo, in the 1980s the same ideas emerged into the commercial world as a tool USE.IT, marketted by "Higher Order Software" or "HOS". One very nice attribute of the tools was the use a graphics to display and input the decompositions and error reports.

    To a large extent the wide spread use of high level languages and static data flow analysis made the ideas redundant and, as far as I know, the tool is no longer with us.

    Note: This my own summary of the history based on articles, books, and advertising that I have kept in my office since 1984. If you differ use the [Contact] button above to submit a rebuttal that could well be published here.


    1. Margaret H Hamilton & William R Hackler
    2. Universal Systems Language: Lessons Learned from Apollo
    3. IEEE Computer Magazine V41n12(Dec 2008)pp34-43
    5. Apollo space mission 1961-1975.
    6. Functions and maps decomposed using three structures: Join, Include, Or. (=~= ";", "&", "|" in MATHS).
    7. Theories of correctness and tools to check such decomposition.
    8. Still blindsided by events. Reality had unexpected properties.
    9. The power of a global reset when an inconsistent state occurs.
    10. Asynchronous process and asynchronous software,
    11. (dick)|-further developed into language AXES, tool USE.IT and company HOS in the 1980's.

    2009-01-05 Mon Jan 5 19:01 Review Published and Software Quality Assurance

    First a boast... Computer Reviews (CR) has published my review of [SchattkowskyForster07] as review 0901-0062 in Volume50, Number 1 (Jan 2009)page 46.

    I've spent some time studying attempting to precis the following study of how research has impacted practice in the area of SQA. I'll let my summary speak for itself.


    1. Dieter Rombach & Marcus Ciolkowski & Ross Jeffrey &Oliver Laitenberger & Frank McGarry & Forest Shull
    2. Impact of Research on Practice in the field of Inspections, Reviews and Walkthroughs
    3. ACM SIGSOFT Software Engineering Notes V33n6(Nov 2008)pp26-35 [ http://www.acm.org/sigsoft/SEN/ ] [ 1449603.14496009 ]
    5. Measure impact by: # licenses, documented uses, evidence of effect on use.
    6. Defines terms. Refers back to QC in 1920 manufacturing, 1960s need for early detection of defects, Weinberg, Fagin, ...
    7. NIST 2000: estimates $22 billion could be save each year by best-practice defect detection.
    8. Wide range of practices and formality.
    9. Poll 2001-2002: regular but unsystematic reviews. Not enough early in cycle. People skip steps: preparation and detection. Companies do not make it part of a process evaluation and improvement process.
    10. Can we trace successful use back to research? Evidence in 1970s, pilots, in-house evidence, standardization.
    11. Some ideas with experimental evidence are not sustained -- PBR. Need: management support, technology champion, convince the developers.
    12. Need collaboration between practitioners and researchers, a charismatic champion, prior quantitative evidence (pilot) in-house.
    13. Human-based techniques may not work outside the lab.
    14. Sustained success: management support, evidence, repeatable analysis and measurements, accepted standard process, easy adaption to changing environment.
    15. Three factors: Adhering to process, systematic reading techniques, optimization.

    2009-01-03 Sat Jan 3 09:01 Happy New Year

    I've archived the previous entries on this blog.

    I plan to continue this blog as a mixture of personal observations on my life and software development with links to recently published URLs, articles, and papers. The goal is to document the soundest practices and the must useful theories.

    I've looked at my schedule [ plan.html ] for the coming quarter and I am not sure whether I will be able to stick to the MTWRF postings.

    So I will be making entries every Monday, Wednsday and Friday starting next week... plus some extra ones as and when the spirit moves me or circumstances conspire.

    I also plan another change that will make it easier to pickup the latest entry without having to download all the previous ones. I will be archiving entries into [ blog009.html ] on a regular basis... weekly or after each new posting...

    Invitation to Contribute

    If you have read something about software development that you think is worth reading you can share it and earn a small piece of fame merely by following this link [ hole.html ] and filling in the form. I will review and post it if it fits with the goals of this blog: The most practical theories and the most sound practices associated with software development.

    Previous Archived Blogs

    (Blog to December 2009): [ blog009.html ]
    (Blog to December 2008): [ blog008.html ]
    (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

  8. above::=using the above statements....

  9. 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.

  10. dick::=indicates my own opinion in and of a bibliographic item.

  11. given::=the data and input into a proof, construction or other thinking.
  12. goal::=the current conclusion, target or unknown of the thinking, construction, or proof.

  13. 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.

  14. languages::= See http://cse.csusb.edu/dick/samples/languages.html, information on computer languages.
  15. latest::= See http://csci.csusb.edu/dick/blog.html,

  16. 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.

  17. 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.
  18. 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.

  19. papers::= See http://cse.csusb.edu/dick/papers, pre-publication drafts, local seminars, unpublished essays, etc..
  20. people::= See http://cse.csusb.edu/dick/samples/people.html,

  21. 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).

  22. 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.

  23. samples::= See http://cse.csusb.edu/dick/samples/, samples of documents prepared using MATHS.
  24. se::= See http://cse.csusb.edu/dick/samples/se.html, links to things about software engineering and software development.
  25. source::= See http://cse.csusb.edu/dick/blog.mth, I use my own MATHS language to write these blogs.

  26. standards::= See http://cse.csusb.edu/dick/samples/standards.html,
  27. STANDARD::= See http://cse.csusb.edu/dick/maths/math_11_STANDARD.html, my personal standard definitions for MATHS.
  28. subjects::= See http://cse.csusb.edu/dick/samples/subjects.html,

  29. tools::= See http://cse.csusb.edu/dick/samples/tools.html,

  30. vita::= See http://cse.csusb.edu/dick/VITAble.html, [ short.vita ] (plain text).

  31. 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.

  32. Z::= See http://cse.csusb.edu/dick/samples/z.html, specification language.

. . . . . . . . . ( end of section RJBottings Research Web Log 2009) <<Contents | End>>

  • CR::="Computer Reviews", [ http://www.reviews.com/ ] and [ browse_reviewers.cfm?reviewer_id=115728 ]