Special featured topic for 2006: Pseudo Object-Oriented Programming

We're seeing more and more examples of distorted understandings of what OOP is about, and we're seeing them not only in actual software development projects, but also in textbooks and journals. Many project failures can be attributed to this phenomenon, and object technology itself is being unfairly discredited in some organizations.

• Pseudo Classes and Quasi-Classes Confuse Object-Oriented programming. A 1998 look at an all-too-common bad-design pattern.
• Pseudo Object-Oriented Programming Considered Harmful -- a look at a distressing trend and misguided practice. From ACM SIGPLAN Notices April, 2002
• NEW in February, 2006-- Popular Trade Journals Promote Pseudo-Objects

General

• Conventions for related entity, name, and identifier classes -- further clarification of some often misunderstood distinctions.

• Data Item Taxonomy (1 page): A clarification of an essential distinction in object-oriented class design.

• Point-Extent Pattern for Dimensioned Numeric Classes, ACM SIGPLAN Notices, November, 1997.
  An essential technique in oveloading numeric operators

C/C++ specific

• NEW in July, 2006: Thoughts on some Proposed C Coding Standards -- IEEE publication misses the point.
• Coping with C character strings -- A long-standing issue keeps reappearing. Is it fair to blame the language for bugs in software products?
• Objects before strings -- Many instances of character-strings really ought to be objects.
• Choosing a string class -- Is std::string always appropriate?
• Assign-to-self Overkill (1 page): A comment on a common misunderstanding in C++ courses and textbooks.
• A Mild Dissent from a Growing Practice-- An inquiry into the growing concern with the sequence of sections in a class.
• Why Can't Authors Get Operator Overloading Right? -- An inquiry into a surprisingly common pitfall.
• Outgrowing Macrophobia -- The preprocessor can greatly simplify program organization and help enforce standards.

Java specific

• Java's Casts of Thousands Observations about a serious obstacle to maintaining large Java programs

• The Dark Side of Java
Early reactions to Java as a development language and as a teaching language
• Conventions for arithmetic operations in Java
How best to circumvent a Java shortcoming
• Self-documenting Code Unrealized in JavaDoc

Articles about programming practices and techniques

• Atrocious Programming Thrives -- Outrageously bad coding examples keep coming, and you'd be surprised at the sources.
• The #1 Flaw in Extreme Programming (XP) -- Can XP and packaged applications co-exist?
• Agile methods and torpid programmers -- A strong objection to some new terminology.
• Publications Sabotage Readable Code -- Are professional and trade journals undermining good practice?
• Straight Talk on Unit Testing -- Clearing up some bizarre misunerstandings
• The #2 Flaw in Extreme Programming (XP) -- Does XP undermine reuse?
• Case Construct Widely Misused to Implement a Table. A comment on a puzzling growing practice among students and some authors.
• "It's Easier for Programmers to Talk to Each Other than to Document" -- Extremists discourage another good practice.
• Program Quality—How can we recognize a good piece of software?

Articles about other programming languages and tools

• Reminiscences of Fortran—Thoughts upon the passing of John Backus.
• COBOL Techniques Quiz and Forum -- "Distinguishing between good and bad programming standards"
• Some Doubts about XML—Are developers being pressured to use an unsuitable tool?
• The Case for Large Languages, presented at STA 5 (Structured Techniques Association), May, 1988
  Comment on the above in the context of what's happened in the past 15 years.
• Has the King Returned?, ACM SIGPLAN Notices, April, 1993.
  A comment on the significance of IBM's new (1993) PL/I products. (Since that time, further relases, including Windows versions, have overcome some of the cited drawbacks.)

Articles

• Implicit Data Dictionaries Are Dangerous -- Some fad methodologies undermine essential rigor.
• NEWin November, 2006: Who Cares What It Does as Long as It Looks Slick?—Comments on peculiar trend.
• Systems Analysis Methodology Slipping Backwards -- Recent "breakthroughs" return to techniques that failed in the 1960s.
• What Ever Happened to Systems Analysts? -- Who should gather, organize, and document requirements for new applications?
• Analysis and Design Considered Harmful -- Pairing different disciplines violates life-cycle principles.
• Requirements Crisis: the Next Generation -- The lessons we thought organizations had learned in the 1970s are now forgotten.
• Legacy Systems of the Past, Present, and Future" -- Many new applications are no better than the old ones.
• Requirements are not discrete -- nor are they "non-functional" -- The "requirements crisis" keeps getting worse.

An Important Resource for the Systems Analyst

• Requirements Deliverables Guidelines
  1. Specifying System Output Requirements -- Fad methodologies overlook logical starting point for user requirements.
  2. Defining Data Items -- Another vitally important and often overlooked component
  3. Specifying System Inputs (transactions) -- Can use cases provide equivalent rigor in specification?
  4. Preparing Dataflow Diagrams -- Are dataflow diagrams obsolete? If so, what replaces them?
  5. Defining processes, business rules, and algorithms
     . . . (more to come) . . .
• Requirements Shortcuts for Packaged Application Software Product Solutions -- How far do we have to take user requirements specification when we're pretty sure we're going to buy packaged application software?