Jack Reeves on Software Design...

The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings -- Jack Reeves

The design of a software project is an abstract concept. It has to do with the overall shape and structure of the program, as well as the detailed shape and structure of each module, class, and method. The design can be represented by many different media, but its final embodiment is source code. In the end, the source code is the design. --  Robert Martin

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.