Robert Martin provides us with a great demonstration of how to avoid bad programming in Ruby entitled “The Hungarian Abhorrence Principle”

The general rule can be summarized as:

When you are tempted to encode data structure in a variable name (e.g. Hungarian notation), you need to create an object that hides that structure and exposes behavior.

However, you should read the whole post for a concrete example and additional thoughts.

More generically - if you need to know the structure of your data type in order to work on it, it probably means you’re not using good encapsulation.

I probably do this several times a day, so it’s definitely something for me to be more aware of.

With apologies to Ambrose Bierce

Iteration

• A way to divide a large, impossible project into smaller, impossible chunks

Daily Meeting

• A means to receive inaccurate and untrustworthy information faster

Unit Testing

• The technique by which developers convince themselves that their bug-ridden software isn’t

Refactoring

• A practical example of the proverb “There’s never time to do it right, but there’s always time to do it over”

Burndown Chart

• A fancy graphic meant to distract the uncurious sponsors from the fact that your project is going to be late and over budget

Trust

• The art of smiling and nodding politely when you listen to a developer lying through their teeth about the status of their work.

Post-Mortem

• A technique by which the failure of a project is explained, without using words like ‘Trust’, ‘Refactoring’, ‘Unit Testing’, ‘Daily Meeting’ or ‘Iteration’

Pair-programming

• A way to force introverted, socially awkward software developers to work together in close proximity for hours on end.  See also: Hell

Scrum

• An agile development methodology famous for dogpiling on one person when the project is late

Extreme Programming

• An agile development methodology where team members who fail to deliver are forced to ride down steep mountainsides on uncomfortable, expensive bicycles

Sprint

• A form of iterative development that would work well if only every month was 30 days long

Backlog

• The list of things that everyone pretends are important, but will never get done

Emprical Process

• What you call something when you want to look professional, rather than shrugging and saying ‘How the hell should I know?’

User Stories

• The lies the end-users tell the  programmers so the programmers will leave them alone and let them get back to work

Continuous Integration

• Two falsehoods in series - “Continuous” should be “Regular” and “Integration” should be “Testing”

Regular Testing

• What any minimally competent software development organization should be doing, without trying to fancy it up with sophisticated names

Planning Game

• The art of making the critically important task of prioritizing work seem trite and child-like

Sustainable Pace

• A mechanism to ensure the developers will still be fresh when the marathon bug-fixing maelstrom occurs at the end of the project

Metaphor

• A way to describe the software project in layman’s terms, ensuring that the highly literal and technical software team will have no idea what they’re actually building

Big Design Up Front

• Also known as “Getting it right the first time”  (See: Refactoring)

Note to everyone who got offended by this -  If we can’t laugh at ourselves, others will.