Module 1 - Overview

Module overview

By the end of this module you should be able to:

• Test drive simple programs comfortably

• Test drive a simple object orientated program

This handbook is about growing the technical practices we use to develop high-quality, well crafted software. Each developer has their own preferences, opinions and experiences so coming up with a definitive list, or even a widely accepted consensus is a daunting task.

At ASOS, we have developed a shared understanding of what good technical practices look like to us.

The title of the book mentions agile, so let’s start there.

What are agile technical practices? Still pretty open to interpretation, the agile manifesto does not mention any technical practices. SCRUM and Kanban do not mention any technical practices also. Can we use the Software Craftsmanship manifesto? No, no specific technical practices there as well. So what about Extreme Programing? XP does have a set of technical practices. The image below shows the technical practices advocated by XP. Now, what of these are individual practices? The inner circle is probably the best candidate. In absence of anything else we can start with these.

Now another question arises. Do we need a core of technical practices in agile? Let’s answer this question with a couple of questions. How often do projects become stagnated under the weight of technical debt? Why does this happen? One of the factors is probably technical debt. Or the lack of technical practices that constantly reduces the amount of technical debt in a project. This is one of the reasons why technical practices are so important to the success of an agile project. They allow us to continue delivering value by addressing the incidental complexity or tech debt as it emerges.

So are XP practices TDD, Pair programming, Refactoring and Simple Design our core practices? Would these practices help prevent tech debt accumulating. Simple design and refactoring look promising; let’s label them as design technical practices. What about pair programming and TDD, these are in a slightly different category; let’s label them feedback technical practices.

Having practices related to design and feedback creates an interesting situation. It allows for experimentation. Consider a design change and get feedback from the pair, then change the design and get feedback from tests. Rapid experimentation and feedback is a pillar of human evolution. Kent Beck on extreme programming:

“Optimism is an occupational hazard of programming: feedback is the treatment.”

“Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.”

The importance of feedback loops in XP is illustrated in the following diagram:

Back to the XP technical practices: TDD, Pair programming, Refactoring and Simple Design. They are still big boxes we need to open and find out what is inside each of them. Let’s do that.

If we go more granular on pair programming we can find the following concepts and practices:

· Driver-navigator

· Ping-Pong/Popcorn

· Chess clock

· Pomodoro

· Pair Rotation

There are two big TDD schools the Classic/Classicist/Detroit school and the Outside-In/Mockist/London so let’s add both to the TDD box. Outside-In TDD relies heavily on mocks and both schools recommend using stubs. The Transformation Priority Premise is a great way to evolve code without adding complexity too soon, so can be seen as part of TDD or Simple Design we choose to add it to TDD. Mocks and stubs are often referred more generically as test doubles. Add test doubles to the mix and we end up with:

· Classic TDD

· Outside-In TDD

· Test Doubles

· Transformation Priority Premise

Doing the same exercise for refactoring we can end up with something like the following:

· IDE Productivity

· Refactoring smells

· Refactoring legacy code

Design is a much more controversial box regarding content, but XP speaks about simple design, so let’s stay with high level generally accepted design principles and practices such as:

· Object Calisthenics

· Code smells

· SOLID

· 4 elements of simple design

· Design Patterns

· CRC Cards

· Domain Driven Design

After we went a bit more granular in XP practices we need to address the next problem. In what order should one learn these subjects?

After spending many hours coaching and going through several iterations on the order of subjects we are now at this point: