Importance Of Geometry

I believe the subject of geometry to be the most important subject taught in schools. It is first rate preparation for the mind for any profession that that requires reasoning. Abraham Lincoln kept a copy of Euclid's Elements of Geometry in his saddlebag, and studied it late at night by lamplight; he related that he said to himself, " … you never can make a lawyer if you do not understand what demonstrate means; and I left my situation in Springfield, went home to my father's house, and stayed there till I could give any proposition in the six books of Euclid at sight. I then found out what demonstrate means, and went back to my law studies" (see The Abraham Lincoln connection.)

A very readable translation of the 13 books of Elements is available here.

Euclid built geometry on ten postulates (axioms). In addition to the axioms, each of the books contains definitions of the geometric terms used in that book and following books. No symbols (as in current geometry textbooks) are used. This make the proofs verbose. The proofs are all graphical as Euclid did not have symbolic algebra that we use today. What he had was Geometrical Algebra. The proof of Pythagoras’s Theorem is an example.

Application of Euclid’s Method to Software

Software should be provably correct. The propositions in Euclid’s books rest on propositions proved earlier. The initial propositions of Book 1 depend just on the definitions and axioms. They are like the leaf functions in a program. I believe that software constructed in the same way will result in provable software.

What a function should do (including any side-effects) should be clearly documented like a proposition. The function body itself is equivalent to a sequence of geometric constructions.

I have found that writing unit tests drives the process of re-factoring code into simpler functions. If unit tests are getting messy, the function under test is messy. The function must be re-factored.

Unit tests and re-factoring are the initial stages. These must be followed by proof of correctness of the construction. The process is not linear; it is cyclical. If the proof is difficult, decompose the function yet again.

A proof answers the question, “Why will this do what it is meant to do?” It should be part of the function documentation. Correctness of the proof must be attested to in the same manner as mathematical proofs. It must be accepted by peers who understand what is being coded.

Assertions, Preconditions, and Post-conditions are akin to lemmas. They are simpler to prove. In addition they have the added advantage of being executable.

Of course, proofs, despite peer reviews, can be defective. That does not mean they should not be attempted. We should learn from defective proofs.

Sherlock Holmes & Software Engineering

In an earlier post I had mentioned "Pratyaksha Pramana" and "Anuman Pramana" and how these constitute the scientific method. And that "Shabda Pramana", contrary to what Justice Katju seems to think, cannot be part of the scientific method.

Sherlock’s Scientific Method

Very good illustrations of these are to be found in Arthur Conan Doyle’s, Sherlock Holmes mysteries. If you have not read them, I suggest you read a couple of them. If you have read them, it would have been a long time ago; I urge you to reread them.

The primary Pratyaksha Pramana is of course the crime. That is the phenomena for which a sequence of verifiable actions needs to be established.

Holmes then uses his acute powers of observation to establish a secondary set of Pratyaksha Pramana.  That enables him to deduce facts (Anuman Pramana) that appear incredible till Holmes describes his observations and the deductive steps. Holmes description of the deductive steps, to my mind, is equivalent to the presentation of a mathematical proof for peer review (not that Holmes would consider any of his interlocutors his peer).

Note it is not just “Pratyaksha Pramana” but acute powers of “Pratyaksha Pramana”. Acute observation is not sufficient. As Holmes says, “Having gathered these facts, Watson, I smoked several pipes over them, trying to separate those which were crucial from others which were merely incidental.” (The Crooked Man). Holmes emphatically expresses the primacy of data: “Data! Data! Data!” he cried impatiently, “I can’t make bricks without clay.” (From The Adventure of The Copper Beeches). If it is not relevant, it is not data. Needless to say, deciding what is relevant is error prone. The only way to reduce it is by regular practice of the scientific method.

Holmes’s “Anumana Pramana” are always subjected to test. In some cases the test consists of simply presenting the deductions to the person involved for their confirmation. In other cases Holmes sets up experiments. As for example, in the “The Adventure of the Beryl Coronet” he dons a disguise to get confirmatory evidence, in the form of the suspect’s used boots, from the suspect’s valet.

Why is Sherlock relevant to the practice of Software? Because, defect rectification is detective work; locating performance bottle-necks is detective work.

Cyber World Detective Work

“The Cuckoo's Egg” is the true story of how the author, Clifford Stoll, uncovered a cyber-attack by the KGB . The “Pratyaksha Pramana” was a 75 cent shortfall in the total billed computer time at a research facility! The Anuman Pramanas and the experiments (tests/traps) setup to verify those and ultimately catch the hackers makes for thrilling reading. 

Clifford Stoll is a scientist - an astronomer.

Dogs That Should Not Bark

The absence of "Pratyaksha Pramana" (call it "A-Pratyaksha Pramana") could also be valid observation. In the “Silver Blaze” the following conversation illustrates this:

Gregory (Scotland Yard detective): "Is there any other point to which you would wish to draw my attention?"

Holmes: "To the curious incident of the dog in the night-time."

Gregory: "The dog did nothing in the night-time."

Holmes: "That was the curious incident."

Assertions and Unit Tests are “dogs that should not bark”. Assertions are hypotheses (Anumana) as to what the internal state of the code should be (or should not be). Unit tests are an anumana (hypotheses) of what a unit of code will do for a given set of inputs. If an assertion dog barks it indicates something is not as expected. If they do not bark they provide "A-Pratyaksha Pramana" that the code behavior (anumana) is as expected – or to coin a words, as “anumana-ed”. However, it must be checked that the dogs can bark! The first step in Test Driven Development is to write a unit test that fails. Only then is functionality written that will silence the dog.

The Significance of Proofs

Justice Katju’s post, mentioned in my previous post, motivated me to get a copy of “The Aryabhatiya of Aryabhata” by Walter Eugene Clark.

Some Rules from the Book

The translation of rule 19 in the chapter titled Ganitapada, as given by Clark:

“19. The desired number of terms minus one, halved, plus the number of terms which precedes, multiplied by the common difference between the terms, plus the first term, is the middle term. This multiplied by the number of terms desired is the sum of the desired number of terms.

Or the sum of the first and last terms is multiplied by half the number of terms”

Clark then goes on to explain the above:

“This rule tells how to find the sum of any number of terms taken anywhere within an arithmetic progression. Let n be the number of terms extending from the (p + 1)th to the (p + n)th terms in an arithmetical progression, let d be the common difference between the terms, let a be the first term of the progression, and l the last term.

The second part of the rule applies only to the sum of the whole progression beginning with the first term.

S = n * [a + {((n -1)/2) + p} * d]

S = {(a + l) * n}/2

 “

The above is the sum of an arithmetic progression. Where is the proof/derivation of the rule?

Clark then gives Aryabhatta’s rule 20 of the Ganitapada as follows:

“20. Multiply the sum of the progression by eight times the common difference, add the square of the difference between twice the first term and the common difference, take the square root of this, subtract twice the first term, divide by the common difference, add one, divide by two. The result will be the number of terms.”

Really? Prove it!!

Using symbols the rule can be expressed as the algebraic formula:

N = [({sqrt{(8 * d * S) + (d – 2 * a)^2} – 2 * a}/d) + 1]

This is obtained from the first expression for S above, by taking the series from the first term onwards (p = 0). Since the expression contains the square of n, it means solving for n requires solving a quadratic equation. Why does the Aryabhattiya not have a derivation for the general formula?

The rules that follow are even more mind blowing! But, regrettably, no proofs/derivations.

Importance Attached to Memory

The rules (algorithms?), in the original Sanskrit, were in stanzas. Being in the form of poetic verse would make them easier to memorize. This was a handbook that could be memorized.

Memorizing formulae does not produce a trained mathematical mind. The discipline of proofs/derivation does.

Memorizing rules is good for speed. Memory, however, is fallible, Good practitioners should be able to at least derive the important formulae, which they use, from first principles – or at least have understood it once in their life.

Implication of Missing Proofs

Somehow I find it hard to believe that the derivations/proofs did not exist. What happened to them? Why were the proofs/derivations not passed on? Were they not valued? If they exist, why are they not given pride of place?

Without proofs/derivations what we have is not a textbook. What we have is a handbook of formulae. Handbooks are useful. But can the study of handbooks discipline the mind to be capable of making new discoveries and constructs? Computational rules/algorithm are Know-How. Proofs are Know-Why. Know-How is good enough for applying knowledge. Creating knowledge requires Know-Why. What does it say of us as a civilization if we celebrate formulae and disregard proofs?

A democracy requires debate. Debate requires ascertaining facts and applying logic. A democracy cannot exist on received wisdom (“Shabda Pramana”).  If as a society we blindly celebrate mathematical formulae without regard to proofs, will we celebrate rational discourse? Our preferred source of knowledge in all fields will be the word of authority (“Shabda Pramana”). Why then should we be surprised if our education system rewards rote learning?

Manjul Bhargava who got the Fields Prize this year, figured out the number of oranges that could be stacked on a triangular base whose sides had N oranges. The number equals N(N + 1)(N + 2)/6. Bhargava did it at the age of 8. The same formula is given as rule 21 of the Ganitapada. The proof can be seen here.  The proof depends upon a result proved on another webpage. That is how mathematics progresses – one proof built on one or more other proofs.

One proof built on other proofs: Is it conceptually identical to good engineering? I shall expand on that in my next post.

Misconception About Science

I came across a blog post by Justice Katju, titled  Sanskrit As A Language Of Science. It is a talk that he gave at the IISc, Bangalore.

In the post Justice Katju says:

“Epistemology is the study of the means of valid knowledge. For instance, how do I know that this object in front of me exists? The answer is that it is Pratyaksha? I can see it with my eyes Pratyaksha is the knowledge which we derive from the five senses, and pratyaksha pramana is regarded as the pradhan pramana or the most basic of all the means of valid knowledge.

However, there are other pramanas e.g. anuman (inference), shabda (statement of some expert or authoritative persons) etc.  Thus, much of scientific knowledge comes from anuman pramana.  For instance, Rutherford never saw an atom with his eyes, but by studying the scattering of alpha rays (which are positively charged helium ions) he used anuman praman (inference) to deduce that there was a positively charged nucleus around which negatively charged electrons were orbiting. Similarly, black holes can not be know by pratyaksha pramana (since light cannot escape from them), but we can infer their existence by the movement of some nearby heavenly bodies on which an invisible body (the black hole) is exercising a gravitational pull.

The third Pramana in the epistemology of the Nyaya system is Shabda Pramana, which is the statement of an expert or a person having great reputation in a particular field.  We often accept such statements to be correct, even though we may not understand the proof, because the person making it has a reputation of an expert.

For instance, we accept that e=mc2 as Shabda pramana since Einstein has a great reputation as a theoretical physicist, although we ourselves may be unable to understand how he reached that equation (as that will require a knowledge of higher mathematics and physics which we may not possess)”

“Pramana” is defined as “pramāṇa,  (Sanskrit: “measure”), in Indian philosophy, the means by which one obtains accurate and valid knowledge”. Pramana, as commonly used today, also means proof/evidence (as in “pramana-patra”). So phenomena that can be observed is knowledge gained by “Pratyaksha Pramana” –Direct Evidence. Knowledge that can be logically derived/inferred from the current body of knowledge is “Anuman Praman”. As used today anuman means estimate/guess, and hence – in my opinion, more appropriately – hypothesis.

Hypotheses, or anuman, is not where it should stop. Anuman must be tested by conducting rigorous experimentation. The scientific method is a cyclic process of observation->hypotheses construction->experimentation->observation-> …. And it is this observation of the results of an experiment which brings us back to “Pratyaksha Pramana”.

Justice Katju has missed this crucial step and hence does not see the never ending scientific cycle of improving knowledge. This reflects in his illustrations.

Rutherford setup an experiment to test the “plum pudding model” (the Anumana Pramana). The observed results of the experiment (the Pratyaksha Pramana) showed that the model was not valid. Rutherford then hypothesized about a new model (Anumana Pramana). Subsequent experiments showed that the Rutherford’s model did indeed explain observed phenomena (Pratyaksha Pramana).

Einstein’s General Theory Of Relativity (the Anumana Pramana) predicts the bending of space-time. Einstein calculated the bending that the Sun would cause. This was then confirmed by observation (Pratyaksha Pramana). The process of the evolution of stars till they become visible red-dwarfs and their gravitational pull, is observed phenomena (Pratykasha Pramana – both visible and gravitational). Further shrinkage results in their becoming gravitational singularities. Their Pratykasha Pramana is just their gravitational on other stars. The observation that they are no longer visible is confirmation (a negative Pratyksha Pramana) of the General Theory.

An illustration of the Pratyaksha Pramana, Anumana Pramana cycle that I would like to give is that of Maxwell’s Equations. Working from the basic laws of Electric and Magnetic fields that had been established by experimentations, Maxwell, in 1861, first formulated the equations that were subsequently reduced to four. The solution to these equations predicted the existence of electromagnetic waves – Anumana Pramana. It was almost thirty before Hertz proved their existence – the Pratyaksha Pramana.

Shabda Pramana, however, has no place in the scientific method. The logic for arriving at Anumana Pramana has to be subjected to rigorous scrutiny by the scientific community. And Anumana Pramana has to be subjected to experimental verification. “Expert witnesses” belong in a court room - not in science.

It is rigorous logical scrutiny by a scientific community and experimental verification that prevents science from descending into voodoo.

I found it strange that Justice Katju, for his illustrations, could not find any examples from ancient Indian Science. Why did he use examples from science that was done in Europe? Are Indian records available of observations made and used to prove/disprove theories? I suppose not. Once Shabda Pramana is admitted then where is the need for experiment?

Unfortunately, it is Shabda Pramana which dominates the teaching of science in our schools. TataSky has an advertisement where a child shows how to differentiate a bad egg from a good egg. He puts them in water. The one that floats, he says, is bad. The one that does not, he says, is good. That is Shabda Pramana. All that has happened is that one floats and one sinks. It is an observation – nothing more. The Pratyaksha Pramana here is: Some eggs float and some sink. That is all. Why does that happen? That calls for an Anuman Pramana. If the Anuman is that one is bad the other good, we need to conduct an experiment. (Incidentally, what is the criteria for classifying an egg as bad?) Separate the eggs that float and the eggs that sink. (There are going to be eggs that float partially. But let us assume we do not have any of those in the current sample.) Boil the eggs (for how long?). Crack the shells and record the difference between the two sets of eggs. Does the observation (Pratyksha Pramana) show that the lot that floated are bad? That would be teaching science.

Beautiful Code: Documenting Source Code

An article, authored by Adam Kolawa, in the book Beautiful Code, uses the subroutine SGBSV from the CERN mathematical library, written in Fortran, as example. The function comment block covers almost 2 pages of the book. The executable lines of code take up barely half a page! As Adam says, "One of the first things to notice in the code for the SGBSV routine is that it starts with a long comment that describes the routines purpose and use. In fact, the comment is exactly the same as the manual page for that routine".

Two statements that specially resonated with me:

• "If you cannot tell what the code does by glancing at the naming convention and several code lines, then the code is too complicated".
• "I hate reading code that was written to show off the developer's knowledge of the language, and I shouldn't need to go through 25 files before I can really understand what a piece is really doing".

Needed "Renovation"
Personally, I consider SGBSV - or any of the other names in the function - fails the test mentioned in the first quote above. But I suppose it makes sense to people who use the CERN mathematical library. Considering Fortran 90 permits names with 31 characters, I think the routines need to be "renovated".

Beautiful Code: Testing a Binary Search Implementation

The Binary Search algorithm has been around for quite a while. I remember doing an implementation (in Fortran) as part of course work in 1977. Hence it was a surprise to read about it in Joshua Bloch's blog post. I am  pretty sure that what I, and the rest of the course, implemented had the same defect.

Alberto Savola in his essay "Beautiful Tests" in Beautiful Code, quotes Donald Knuth as saying that though the first binary search was published in 1946, it took 12 more years for the first binary search without bugs to be published. However, defective implementations could, and did recur.

All very humbling. To quote Joshua, "The general lesson that I take away from this bug is humility".

Alberto Savola's piece uses the Binary Search program to show how tests should be developed. Here are some topics that I found educative:

• The utility of smoke tests.
• Re-factoring code to improve testability. A side-effect of this is to improve the design and the readability of the program.
• The design of tests to verify that neither a true condition is detected as false nor a false condition detected as true. What in radar theory are called failed detection and false alarm.
• Formulating theories (I think calling them hypotheses, would be more appropriate) of the forms: If A is true then B should be true; If A is not true then B should not be true. 
• Random generation of tests. This is most intriguing. I wonder if genetic algorithms could be used to generate tests.
• The use of helper tests that give an alternate way of checking. These are simple tests whose correctness are easy to verify by visual inspection. For the binary search a test using a linear search is also implemented. The linear search is used to cross check results obtained using the binary search.

A quote from Savola:
"Truly beautiful testing requires a developer to make an effort, think outside the box, explore weird scenarios, look for weaknesses, and try to break things".
(Note 1: The emphasis is mine.
Note 2: A side note: "outside the box", I think, is a more appropriate expression, in such contexts, rather than the more commonly used "out of the box".)

Beautiful Code: ABC, Ruby & Churchill

One of the essays in the book Beautiful code is titled, "Treating Code as an Essay". The author is Yukihiro Matsumoto. Yukihiro is the creator of Ruby.

Here are some quotes from the essay:
1. "The style in which they are written is just as important as their purpose. Both essays and lines of code are meant - before all else - to be understood by human beings".
2. "Unreadable code will reduce most people's productivity significantly. On the other hand easily understandable code will increase it. And we see beauty in such code".
3. "Brevity is one element that helps make code beautiful".
4. "Simplicity ... We often see beauty in simple code. If a program is hard to understand, it cannot be considered beautiful".

As an example of brevity he gives the HelloWorld program in Java and in Ruby. In Ruby just the statement, "print "Hello World\n" constitutes the complete program!

However, I do find it hard to accept, "The real shortcut for elegant code is to chose an elegant programming language. Ruby and other lightweight languages like it support this approach". This is like saying English is more elegant than Kanji - or the other way around. What can be more elegant than substituting a couple of lines of English with a few brush strokes!

The book has an essay where the code is in Fortran, another where it is in Lisp. Obviously if the program is math intensive, Fortran is the lightweight language. If the application is AI, Lisp, I presume, will be the lightweight language.

No matter what the language, I believe the qualities mentioned by Mr. Matsumoto will characterize beautiful code.

Of course code should not become Haiku:-)

But Haiku is poetry. Code should be like good tight prose.

Consider what Churchill called the moral of his six volume "The Second World War" : "In War: Resolution, In Defeat: Defiance, In Victory: Magnanimity, In Peace: Goodwill". How's that for minimal brush-strokes?

Beautiful Code

That's the title of a book edited by Andy Oram & Greg Wilson. I am currently reading it.

I believe that writing good code is akin to writing good prose. The ABCs of writing prose - Accuracy, Brevity, Clarity - are applicable to writing good code.

Consider Subroto Bagchi's valedictory speech at IIMB. Observe how:

• each episode (function?) supports a single value/moral (a function should do only one thing, and do it well?),
• simply constructed each sentence(each line of code?) is,
• the episodes are sequenced (sequence of function calls?),
• all the episodes support the purpose of the talk (the deliverable functionality?).

Code - like prose - has to be engineered. Well engineered artifacts are beautiful. It takes art to create them.

Apple's Software Process

Apparently Apple's Software Process has some problems. See Michael Barr's post.

Ah well! Apple is famed for cool products. Can quality processes qualify as cool? Well ... :-)

Scientific Method

The basis of the scientific method is recording data. To record data we need to establish metrics.  Without standard units and measurement there is no physics. Without metrics there is no software process. Without records we have only myths.

The other day I was speaking with a developer with about 8 year experience. I asked, on a software tool project, using the C programming language, with an expected size of 10K lines of code (LOC), what would be the average LOC per day. (He did not ask as to how I defined LOC. I broadly put it as the number of executable LOC - STXLN in the tool QA-C from Programming Research). The amazing answer: ~400 LOC/day!!!

In the Tools BU of Acme Technologies we constructed and renovated programming tools. My experience was a rate of 8~10 LOC/day. We had recorded data. We did not depend on myths.

Have a look at the data for the project gpsd — a GPS service daemon. A code-only size of 51,064 required 12 person-years. Assuming 22 working days/month, this works out to a rate of 16 LOC/day!

PS:  An earlier post on keeping records

Bolt or Jackie?

I was in conversation with someone who said he had experience of agile methodology at one of the companies he had worked at.

I asked him to describe agile development. The first statement that he made was, "It is for fast development."

Not quite correct. Agility is not the same as speed. Usain Bolt is the fastest human. I doubt if he is anywhere near the most agile. Arguably the most agile would be Jackie Chan. Though Mr. Chan would undoubtedly be quick, I doubt if he is a world class sprinter. I doubt if Mr. Bolt would qualify for the Jamaican acrobatics team.

Agility is the ability to respond to surprises. It needs muscular coordination, quick reflexes, flexibility, excellent sense of balance, and sixth sense.

A software process that focuses on speed wants to anticipate all surprises. It is about risk minimization. It invests in up-front detailed design and the associated processes to ensure that the plan is followed. It needs a clearly marked standard track to sprint down.

A software process that focuses on agility acknowledges that the only thing that can be said in advance about surprises is that they will occur. It is not about speed of development but speed of response to surprises. Speed of response to surprises needs leadership with a mindset that is willing to accept surprises - not sweep them under the carpet. It needs leadership with a mindset willing to invest time in keeping the code malleable at all times.

When I asked my interlocutor to name some of the agile practices, the only one he mentioned was morning ten minute stand-up meetings. Questioned as to how it was determined if the day's commitment was achieved, or not, there was no answer. (Expected Answer: unit tests that pass.)

Malleability

Malleability is that property of a material that allows it to be easily shaped. Gold is malleable. Stone is not.

Code should be malleable.

Polymorphism (from the Greek poly meaning "many", and morphe meaning "form, shape") adds to malleability. So do unit tests. Coupling destroys malleability. Cohesion enhances it.

Reluctance to modify code is a sure sign that malleability is being degraded. Attend to it. If it is hard to do now, it is not going to easier on its own.

Code that is not malleable become "Bhoot Banglas". Code that is not malleable is code that is petrified (from the Greek petro for stone). Petrified code leads to petrified code maintainers.

E-mail Practice & Code

I remember reading somewhere: Software reflects the organization that made it. The quality of  the code says a lot about the practices of the organization (company, team, individual) that created it. After all, quality of code is the result of software practices.

The opposite is equally true. The practices of an organization say a lot about its software practices.

Practices are the result of values, of world views, held as individuals and, in the aggregate, by an organization.

One practice that I have found to be specially revealing is the handling of email threads.

Anti-Patterns

• If threads need to be measured "by-the-yard", will functions in the code be any different?
• If subject fields are not indicative of the contents of an email, will function and variable names be any different?
• If mail threads are not forked, will code be re-factored?
• If sentences run on and on, will the code be any less convoluted?
• If paragraphing is poorly done, will code structure be done well?
• If mail is not self-reviewed, will code have unit tests?
• Most importantly, if the CEO and CTO tolerate sloppy email, will they do anything about sloppy code?

Takeaway

Code is written - just like a document is written. Code is constructed - just like a document is constructed. Both require thinking. Careless thinking for one is a good indicator it will be so for the other.

Movies & Temping

Consider movies. The big studios employed actor, directors, story writers, ... Even owned theaters. The days of the big production studios, whether in Bollywood, or Hollywood, are long over. Earlier directors and actors signed on with a studio. Now they sign on for a movie. They refer to them as projects. They are temps. The big studios have been replaced by a movie-making ecosystem


Consider credit lists. Movies these days have credit lists at the end of the film. And they run for miles. I do not recall earlier movies having credit lists at the end of the movie. I suppose it is a result of the new model of movie making. Temps require to get credit for their work. They need to be acknowledged as having been part of the project.

The same I believe is happening in software. No, neither Infosys, nor TCS, nor ...  are going to disappear any time soon. But they will increasingly resort to temping (I believe some of them already do). Their margins are going to get squeezed. They just will not be able to afford talent sitting on the bench.

My advice to those preparing for a career in software: forget it, there is no career. But there is a profession.

Networking does not mean partying. It means making other professionally more than superficially aware of  your skills; and being more than superficially aware of other professionals' skills. It means getting to know other professionals, professionally.

Be very prudent with your personal finances. Avoid the debt trap. The days of the regular pay-check, for years and years, is over; so are the days of regular increments - be prepared for decrements.

Try and acquire some marketing & sales skills and communication skills. You are a marketing and sales person. The product you are marketing, and selling, is YOU. And be ready to modify the product.

Read & digest The Clean Coder: A Code of Conduct For Professional Programmers  

 

Pre-Conditions, Post-Conditions & Unit Tests

Recently I wrote a class for program flow-graphs. Writing unit tests, it turned out, required more effort than the unit tests that I had written for other classes .

I was aware that when writing functions one must document the pre-conditions and the post-conditions. These I implemented as asserts. I usually felt that these were adequate. But when it came to the program flow-graph methods, the set of asserts was turning up to be just too messy

As I mentioned, the development of unit tests was turning out to be more difficult. The program flow-graph object to be used for the test had to be decided. What it would be transformed to was to be worked out. I found myself putting these down, in the test case file, as a file comment block. While doing that, I realized I was effectively specifying Pre-Conditions and Post-Conditions. I was saying, "Given this program graph object as the input, some set of attributes should change, and some set of attributes should remain invariant".

Light-Bulb event: Unit tests are statements of Pre-Conditions and Post-conditions.

What about asserts? I now regard these as micro unit tests that are embedded in the code.

PS: I hope to be more frequent in my posts in 2014:-)
Happy New Year.