Programs & Geometry Theorems

In the preceding post I linked the regular expressions that define tokens in a programming language to the definitions in a formal mathematical system. Productions of the grammar that define the language, I said, were axioms. The programs we write in that language are theorems.

The definitions and axioms of Euclid's Geometry construct a formal mathematical system. The proof of theorems in geometry "stand on the shoulders" of other theorems. For any theorem there is a "tree" of theorems. The theorem to be proved is the root node of the tree. Definitions and axioms are the leaf nodes. That is how the complete system is constructed.

That is how programs should be constructed. Sure, everyone constructs programs that consist of functions. But do we check the complexity of the functions? We need to refactor till we get functions that have low complexity. Such functions are easy to inspect and easy to test (unit test). If all the functions in the call tree of a function have been "proved" - by inspection and unit test coverage - then the function itself stands on a "proven" foundation.

Programs must be "proven" with rigor approximating the rigor with which geometry theorems are proven. Tools for Complexity metrics, Refactoring, Unit Testing, & Coverage metrics are the instruments that help in doing this.

Earlier post on the subject.

Validity & Veracity

I finally summoned up motivation to read The Annotated Turing by Charles Petzold. I bought the book in Jan2012. Ever since then it was a pending TODO. Now that I have time on my hands, I decided to attend to it while the grey cells were still active.

 From pg. 45. "In Hilbert's conception, the construction of a formal mathematical system begins with definitions, axioms, and rules for constructing theorems from axioms."

My Take:

• The regular expressions that are used by in the Lexical Analysis phase of the compiler are Definitions .
• The productions of the grammar rules, used in the Syntax Analysis phase, are Axioms. The output is an Abstract Syntax Tree (AST)
• Finally the Semantic Analysis phase is the one where the rules of the language are used to extract the operations that are implied by the AST. The output is an Intermediate Representation (IR). That is where the front end of a compiler ends. Subsequent steps are transformations to make the code execute on some CPU
• Thus the IR output of the compiler is a theorem constructed from axioms.
• The rules and axioms are coded in to the compiler.
• A compiler therefore qualifies as a formal mathematical system.
  
  

From pg. 46. " ... but the rules also imply the syntax of a well formed formula ... that is possible within the system. You can assemble a well-formed formula without first deriving it from your system, and then you can attempt to show that it's a consequence of the axioms by applying the axioms and rules in a proof."

My Take:

• When we write a program in a high-level language we in fact "assemble a well-formed formula without first deriving it from your system".
• Then when we successfully compile it we in fact show that "it's a consequence of the axioms by applying the axioms and rules in a proof"

From pg. 47. "Provability is a syntactic concept; it is based on the axioms of the system and the rules used to derive theorems. Truth, however, is semantic concept that depends upon the actual meaning we give to the symbols in the system."

My Take:

• Successful compilation proves Validity.
• Successful compilation does not prove Veracity (Truth).
• There is no getting away from well designed tests. Such tests are close approximations of a "proof" of Veracity.

The Hare & The Tortoise

The fable of the Hare & the tortoise has been used to draw lessons in competing and co-operating.

The fable also applies to software organizations.

The Hare Company.

• No prototypes are being worked on. (Hare Sleeping)
• No experiments being done to Cross The Chasm. (Hare Sleeping.)
• Wishful thinking about own capability. (Hare Dreaming.)
• RFP is received. (Hare wakes up.)
• Estimate based on myth.
• Mad scramble to bung in a business proposal. (Hare racing.)
• Loses Contract. (Tortoise wins. Hare team gets more dysfunctional.)

The Tortoise Company.

• Prototypes concepts that are likely to win in the marketplace. (Steady progress.)
• Experiment. Be ready. (Steady Progress.)
• Fast feedback loops. (Course correction. Prepare to undertake "Op Overlord")
• Has true picture of own Capability. Uses CMM as a "dashboard" instrument.
• Estimate based on track record.
• RFP is answered based on known facts. Risk minimized.
• Wins without breaking a sweat.
• Proceeds with Agile implementation of project.

Surprisingly, It is the Tortoise that is Agile!

Dilbert: Agile

Today's Times Of India, shows why an Agile process is needed. Will Pointy-haired managers get it?

Humility & Courage

Humility is not lack of confidence. Bravado is not courage.

I believe that Humility & Courage are essential traits for doing quality software work. The reality of software development teaches that. Refusal to learn this lesson is a root cause for poor software quality and dysfunctional teams.

Humility.
Humility means being aware that one could be wrong; that one's understanding has gaps. Humility leads us to always question our assumptions; to always put them to the test.

Defensive coding is humility. Assert statements check one's mental model of the state of execution of the code. It is accepting that one could be wrong.

Recognizing the primacy of unit tests that can be easily and frequently run, and provide appropriate coverage metrics, is humility. Adding tests that increase coverage metrics is humility.

Humility is a prerequisite for learning.

Courage.
Visually challenged persons are not be able to walk briskly. But they learn to progress by testing their way with the help of a cane. That is courage.

As software professionals we should realize that we are "visually challenged". Courage is "tapping" our way forward. The "tapping of the cane" are experiments that we must conduct to improve our understanding. These experiments have to be small steps.

Resolutely "tapping" our way to our objective is Courage.

Agile.
An Agile process is about Humility & Courage.

Prose & Code

The ABC of writing good prose: Accuracy, Brevity, Clarity.

The ABC of writing good code:

• Accuracy: A function should do one thing and one thing only.
• Brevity: Coding standard must specify the acceptable length of functions. If the function is getting long; Refactor.
• Clarity: 
• Track complexity metrics. Refactor
• Use names that convey intention. 
• Avoid globals.
• Write Executable Specifications.

Architecture of Internal Combustion Engines

As I mentioned in an earlier post architecture is about "What" gets done "Where".

Form follows functionality is a principle of the architecture of buildings that also applies to software architecture. I recommend reading the complete article.

Why am I talking about the internal combustion engine?

• Most automobiles, and motorcycles, have a 4-stroke engine. A 4-stroke engine has four processing stages - Intake, Compression, Ignition/Working/Expansion, and Exhaust. All done in the same processing space - The cylinder.
• What about Jet Engines? Jet Engines too are internal combustion engines. They too have the same four processing stages -  Intake, Compression, Ignition/Working/Expansion, and Exhaust. Except, in a jet engine these are not done in the same place. The processing is pipe-lined.

A jet engine is an internal combustion engine with a pipe-lined architecture!

Takeaway. Architecture is not restricted to buildings. Architecture is about the way work is organized.

Note: I assert my IP right to all of the above.