17 rules to design high quality software

Extracted from the online version of "The Art of Unix Programming", by Eric Raymond:

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

A negative review automatically generated by the ICSERGen tool

The following review has been generated by the ICSERGen tool (by Crista Lopes) for the following paper:

Henrique Rocha; Marco Tulio Valente. How Annotations are Used in Java: An Empirical Study.  23rd International Conference on Software Engineering and Knowledge Engineering (SEKE), p. 426-431, 2011.

Have fun!

===================

The following review has been automatically generated by a program.
The goal is to make fun of certain reviews made by certain reviewers in certain conferences.
Do not use this in your real reviews.
Enjoy!

*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*

The major problem with this paper is that there is nothing new here. A lot of this has already been proposed before. Some examples that come to mind are: just to name a few.

The paper talks about "...textual search program to find annotation...", but I haven't seen any discussion on that (whether in the theoretical part of the paper nor in the validation part). It is just mentioned. For this kind of work, this is _relevant_ how an approach can deal with that.

Some of the well-known concepts have been just renamed: "system" is nothing else than "complex, interlacement, mesh"; "class" is "caste, estate, folk"; parts of the approach have not even gotten a name.

The paper uses the term "class." Class has been used in the context of AOP developed by Crista Lopes et al. The paper cannot use the same term and generate confusion (in many dimensions). A simple google search would have helped with the naming.

The techniques are explained at a rather shallow level. No details. So, for example, what's the precise definition of "annotation"? How is system related to annotation? The paper talks about method, but why is that important? The role of "code" in the approach is not clear. When the paper gets to a bit more detail on these things, it stops abruptly.

The paper does not provide enough details for the work to be reproducible.

The difference to Google annotation system facility is also not discussed.

I could not understand Fig 1; this kind of "visualization" is not effective (and also not intuitive).

10 Quotes from David Parnas

1. Software engineering vs computer science:

"Software engineering is often treated as a branch of computer science. This is akin to regarding chemical engineering as a branch of chemistry. We need both chemists and chemical engineers but they are very different. Chemists are scientists; chemical engineers are engineers. Software engineering and computer science have the same relationship"

2. Empirical software engineering (I):

"Assuming that what people do “naturally” must be the right way for people to do things, they (empirical researchers) often draw conclusions about how to do software development from a small number (for example, three) uncontrolled case studies. This results in many publications, but even a large collection of anecdotal reports isn’t enough to scientifically establish knowledge"

3. Empirical software engineering (II):

"I was taught that one of the cardinal rules of psychological research is "if you ask a subjet how he/she solves a problem, don't believe what they say". People often do not know how they solve problems, and asking them how they do it often changes the way they work."

4. Formal methods:

"It is common for researchers who do not achieve what they set out to achieve to blame the funding. Research in formal methods for software development has been very well funded. More money won’t help; more thinking will"

5. Software maintenance and evolution:

"A sign that the Software Engineering profession has matured will be that we lose our preoccupation with the jirst release and focus on the long term health of our products"

6. Advice for students:

"I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date"

7. Research evaluation:

"The widespread practice of counting publications without reading and judging them is fundamentally flawed for a number of reasons: (a) it encourages superficial research; (b) it encourages overly large groups; (c) it encourages repetition. (d) it encourages small, insignificant studies;  (e) it rewards publication of half-baked ideas"

8. Research advice:

"The most difficult and crucial step in research is identifying and defining the problem.  Successful researchers are usually those who have the insight to find a problem that is both  solvable and important"

9. The "Star Wars" missile-defense program proposed by Ronald Reagan in the 80s:

"I am not a modest man. I believe that I have as sound and broad an understanding of the problems of software engineering as anyone that I know. If you gave me the job of building the system, and all the resources that I wanted, I could not do it. I don’t expect the next 20 years of research to change that fact."

10. Modularity:

"To a man with a hammer, everything looks like a nail. To a Computer Scientist, everything looks like a language design problem. Languages and compilers are, in their opinion, the only way to drive an idea into practice.

My early work clearly treated modularisation as a design issue, not a language issue. A module was a work assignment, not a subroutine or other language element. Although some tools could make the job easier, no special tools were needed to use the principal, just discipline and skill.

When language designers caught on to the idea, they assumed that modules had to be subroutines, or collections of subroutines, and introduced unreasonable restrictions on the design. They also spread the false impression that the important thing was to learn the language; in truth, the important thing is to learn how to design and document.

We are still trying to undo the damage caused by the early treatment of modularity as a language issue and, sadly, we still try to do it by inventing languages and tools."

Three Software Engineering Papers You Should Read Over And Over Again

* No Silver Bullet: Essence and Accidents of Software Engineering. Frederick Brooks, 1986.

To remember that "building software will always be hard. There is inherently no silver bullet."

* On the Criteria to Decompose Systems Into Modules. David Parnas, 1972.
To remember that "modules should be considered to be a responsibility assignment rather than a subprogram."

* A Note on Distributing Computing. Jim Waldo et al., 1994.
To remember that "there are fundamental differences between the interactions of distributed objects and the interactions of non-distributed objects."

Questioning correlations is good statistical hygiene

John Paulos, A Mathematician Reads the Newspaper:

"A more elementary widespread confusion is that between correlation  and causation. Studies have shown repeatedly, for example, that children with longer arms reason better than those with shorter  arms, but there is no causal connection here. Children with longer arms reason better because they're older! Consider a headline that invites us to infer a causal connection: BOTTLED WATER LINKED TO HEALTHIER BABIES. Without further evidence, this invitation should be refused, since affluent parents are more likely both to drink bottled water and to have healthy children; they have the stability and wherewithal to offer good food, clothing, shelter, and amenities. Families that own cappuccino makers are more likely to have healthy babies for the same reason. Making a practice of questioning correlations  when reading about "links" between this practice and that condition is good statistical hygiene."

And the final recommendations:

"If statistics are presented, how were they obtained? How confident can we be of them? Were they derived from a random sample or from a collection of anecdotes? Does the correlation suggest a causal relationship, or is it merely a coincidence? And do we understand how the people and various pieces of an organization reported upon are connected? What is known about the dynamics of the whole system? Are they stable or do they seem sensitive to tiny perturbations? Are there other ways to tally any figures presented? Do such figures measure what they purport to measure? Is the precision  recounted meaningful?"

Friedrich Steimann's verdict on MDA/MDD

Friedrich Steimann's verdict on MDA/MDD/MDE/MD*: 

"Models have their greatest value for people who cannot program. Unfortunately, this is not because models are more expressive than programs (in the sense that they are capable of expressing complex things in a simple manner), but because they oversimplify. To make a useful program (i.e., one that meets its users’ expectations) from a model, the model must be so complicated that people who cannot program cannot understand it, and people who can program would rather write a program than draw the corresponding model. Even though (over)simplification can be useful sometimes, it is certainly not a sufficient basis for creating a satisfactory end product."

From: http://queue.acm.org/detail.cfm?id=1113336