What I learned about Cryptography

In preparing a presentation on cryptography for a graduate class, I was surprised by what I learned.

Cryptography has been used from ancient times through the Industrial Age to the modern day. It's been used for military, diplomatic, criminal, and commercial purposes.

In the simplest and oldest form, Greeks used strips of paper wrapped around sticks of a certain size called a scytale - rhymes with Italy.

Julius Caesar is one of the first known users of the simple letter substitution method. The modern day cousin is ROT13.

If he had anything confidential to say, he wrote it in cipher, that is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these, and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A, and so with the others.
—Suetonius, Life of Julius Caesar

Hiding messages (steganography) is as old as the ancients. An example would be a tattoo on a shaved head. The hair would grow back hiding the tattoo. A modern example is hiding text in the pixels of a digital image.

Charles Babbage is a name taught in every into to computer science class as a pioneer in computing machines. I never knew that he helped the English during the Crimean War by breaking cryptological codes.

Mary "Queen of Scots" was caught when one of her secret codes were broken.

The Voynich Manuscript may have been an elaborate hoax to defraud a king, who had a interest in mysteries like coded messages, out of a large amount of gold.

A mob boss used encrypted messages to give out orders to his lieutenants and was arrested when the police cracked his amateur code.

Cryptography is thousands of years old and is used all around us everyday.

Programmers - Poets or Mathematicians?

Programming software is much like writing a story. Any given story can be told in a near-infinite number of ways and those who practice the craft will spend just as much time, if not more, arguing over the style of a work, as if their subjective opinion can suddenly become objective fact. Usually this leads to a contest of "If you don't agree with me, I'll just keep talking until you see reason" or otherwise known as talking the subject to death.

I thought I'd shine some light on an example of this issue in programming. There is a never-ending debate in programming circles about the 'proper' way to write code that creates some true/false decision. Stackoverflow has a good example of this.

My personal pet peeve (petty but my teeth grind everytime I see it) is verbosely setting booleans, e.g.

bool isValid;
if (percentage >= 0 && percentage <= 100)
  isValid = true;
else
  isValid = false;

whats wrong with

bool isValid = percentage >= 0 && percentage <= 100;

It's soooooo much more succinct and easier on the eye

Even though the single line version isn't the most complex, different people read through code in different ways. A single expression can be easily parsed by people who have a math background or are experienced coders. That's not the point. The expanded version reads more like a sentence than a formula. It's easy to forget that there are plenty of coders without a background in math. It really comes back to the preferred style of the reader. Do they prefer reading expressions and formulae or something more like human speech.

Homer's The Illiad and The Oddessy are ancient works dedicated to expressions of speech. They were originally poems that were passed down in an oral tradition and meant to be sung instead of read.

Euclid's Elements is a work dedicated to expressions of logic. It covers objective proofs and unambiguous facts and is the beginning of the mathematical tradition, if you will, of rigorous scientific thinking.

The problem we face in software is code is a form of human expression, with all the imprecision that entails, attempting to communicate with the utterly logical CPU; programmers will be forever trying to translate "An Ode to the Machine" into the Pythagorean Theorem.

If Gulliver Were a Designer

The term 'Design' gets thrown around a lot in software developer circles. There are constant flamewars over favorite techniques and battles over what good design really entails. When those arguments start getting too ad hominem figure out whether the speaker is a Code Monkey before giving them much credence. Since I've already braved the waters, see "Have Design Will Travel" or "The Age of the Design Review", instead of safely avoiding the issue, I'm going to bravely (or foolishly) join the fray.

Realize that there is more than one type of 'Design'. Design in the large turns into architecture and is something that really only comes with experience. Designing at the lower levels, say at the individual class/object level is easier to cover. Today I'm writing about design in the small vs the large; Lilliput vs. Brobdingnag.

The issues with designing a class is the same regardless of platform or language. The key is whether an object should be autonomous or whether it is better for any given behavior to be spread out among objects with limited scope and distributed responsibility.

For each class the answer might be different. We end up with a spectrum along which we can place classes based upon the Density of Responsibility.

             (Level of responsibility for behavior)
        Autonomy - - - - - - - - - - -  - - Dependence
     High
 C      -   [god object]                [spaghetti]
 l      -
 a      -
 s      -                                
 s      -           
        -                  
 s      -
 i      -
 z      -
 e      -  [template]                   [framework]
      low

Let's say you favor letting the class perform all the behaviors itself, or as many as you can. Starting on the left side of this graph, when you make your class more autonomous, the size of the class will grow unless you continuously refactor it to make it more generic. This leads to a template. If no refactoring is done, the tendency is for the class to become more "god-like" because if there is some behavior it needs, it has a method for that - it can do anything and everything. The number of fields and methods grow and soon become both unmanageable and unavoidable. Since the class already does so much, coders would rather add to the monstrosity than try to piece it apart and cut the Gordian knot.

The right side of the graph has classes that depend on other classes to a large degree. If the dependency level is high but the individual class is small, that is a sign of a framework; each class doesn't do much and requires lots of dependent classes to accomplish some function. On the other hand, a highly-dependent class that also has a large amount of code is a sign that the class is full of spaghetti.

The key to this question is to determine where you feel more comfortable on the graph. In any event, individual classes will end up spread out on the graph unless some organizational principle is applied, which is how you can achieve the results of Template or Framework.

Having just written that, I would say that there is a correlation between class size and degree of organization. Robert C. Martin (or "Uncle Bob") covers similar ground with package dependencies in his very thorough paper on Design Principles and Design Patterns[pdf]. JDepend is an implementation of the ideas behind the graph on page 26 and complements static analysis tools such as Checkstyle and PMD.