Intentional Programming

"Intentional Programming is a programming paradigm (Charles Simonyi, Microsoft) that encodes in the software source code the precise intention which the programmers ( or users) have in mind."

A Java program that writes numbers from 1 to 10 looks like this.

for (int i = 1; i <= 10; i++) {
    System.out.println("the number is " + i);
 }

However, this does not "does not capture the intentions of the programmer". A modified code would look like this.

for (int i = 1; i <= 10; i++) {
    System.out.println("Printing the numbers 1 to 10 " + i);
 }

TDD encourages intentional programming. You are able to state your intentions (via TDD) even before you code.

TDD vs. Create Test Case After Code

Test Case After Code

Test Case Before Code (TDD)

-         Focus is on artefacts -         Writing tests after the code is a combination of recall of what has been coded and re-reading. -         Relies much more on the discipline of the coder. -         As a coder you may end up writing more code than is necessary when doing a test case after code

-         Requires coder to have a clue about where they are heading with the code. -         It is the beginning of a detailed code design -         We use the tests to literally drive function into the code, so that the fit between the test and code is much higher. -         By writing a test before we are challenging ourselves to pass it. -         TDD creates a narrowed focus, a narrow bandwidth to solve the issue on hand thereby ensuring optimized solution.

By writing test first, we force ourselves to design the program to be both testable as well as callable. This leads the class to be decoupled from its surroundings.

Diagram courtesy: Cohn

• TDD takes about 15% longer than not doing TDD. But there is evidence that TDD leads to fewer defects. Bugs go down by 24% to 38%.
• TDD may initially take a longer time, but will benefit the team in terms of reduced defects, reduced bug fixing and maintenance time.
• 
  

SOLID Principles

Courtesy: Uncle Bob

SOLID is an Acronym for the five Object Oriented design principles

• S: Single Responsibility Principle
• O: Open-Closed Principle
• L: LISKOV Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

Single Responsibility Principle: A Class should have only one reason to change.

"If a class has more than one responsibility, the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class's ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed."

Christopher Avery's views on Organization as a Living System.

Organizations are living systems. We can never direct a living system, only disturb it and wait to see the response. We can't know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens -- Christopher Avery's views on Organization as a Living System.

There can't be an End State in a process that calls for continuous improvement

 -- Mike Cohn...