DEV Community: Emmanuel Genard

Chapter 5: Franc-ly Speaking

Emmanuel Genard — Sun, 28 Jun 2020 00:00:00 +0000

Chapter 5: Franc-ly Speaking

Summary

Beck wants to implement multi-currency multiplication but can't because we only have one currency implemented, Dollar. So in this chapter he does a quick and dirty implementation of Franc. He copies the code in Dollar and renames the class Franc. Beck acknowledges that most programmers would consider this bad code but makes the case the the first goal is to get a green test. Once you have a green test, you can then improve the design with a refactoring.

Commentary

Good design at good times. Make it run, make it right.

This quote by Beck reminds me something I've heard about writing: "The only kind of writing is rewriting". It's supposedly from Ernest Hemingway. Writing is about getting something, anything, down and then working it until it's good. I think Beck is advocating the same thing for writing programs. You could say that he thinks clean code is cleaned code.

However, I almost never see this attitude. In my experience there is an expectation of a good design immediately. I feel this pressure almost every time. Every time I try to make it run then make it right, I feel like I'm doing something wrong. There seems to be an unstated norm that a good programmer is able to do a good design right away. This maybe some imposter syndrome on my part or some other projection of my fears and insecurities. Nonetheless it feels risky not not make it right, right away.

I think another reason is that I don't always know when I have a good or bad design. When is the code clean? When is it OK to leave it a little dirty? How do I know when to insist on squeaky clean and when not to? I tend to just do what feels right. I settle for "good enough" but I have many different versions of "good enough".

Good design at good times. Make it run, make it right.

What is a good design? When is it a good time? What makes it right?

Chapter 4: Privacy

Emmanuel Genard — Sun, 07 Jun 2020 23:29:01 +0000

Chapter 4: Privacy

Summary

This is a short chapter that cleans up after the refactoring in the previous chapter. Beck refactors the multiplication test to make it clear that the times method returns a new instance of the Dollar object.

He goes from this test

public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}

which checks against the primitive numbers 10 and 15.

To this test

public void testMultiplication() {
Dollar five = new Dollar(5);
assertEquals(new Dollar(10), five.times(2));
assertEquals(new Dollar(15), five.times(3));
}

which compares the result of the multiplication with new instances of Dollar.

This change is made possible because of the implementation of equals in Dollar. It also allows the instance variable amount to be made private since it is no longer referenced outside of Dollar.

Beck notes that this refactoring does a better job of expressing intent:

This test speaks to us more clearly, as if it were an assertion of truth, not a sequence of operations.

The rest of the chapter is about the tradeoff of TDD. He argues that TDD is not about perfect code but about having enough confidence with the code you've written to move forward.

Commentary

I think this chapter has two important ideas that are not talked about enough when discussing TDD. The refactoring of a test. The tradeoff of TDD.

The refactoring of tests is not emphasized in most of the writing about TDD. I've seen its importance in practice but there isn't much guidance on how to do it and when to do it. Beck does it here because the tests no longer express the intent of the code. This is a good heuristic but understanding when the tests no longer express the intent of the code is not always obvious. Other reasons I've refactored tests are, they don't provide any value, they are coupled to an implementation, or they are unreliable.

When tests are coupled to an implementation it is usually easy to spot. You write code that does the same thing in a different way but the tests fail. It can even be explicit duplication between the tests and the code. When tests are unreliable every test run is exciting. You don't know whether they will pass or fail even though you haven't changed any code. Value can be harder to determine. Sometimes the test tests something covered elsewhere. Sometimes it's the wrong test. Sometimes it's not important in the context of the domain. Sometimes the effort of maintaining the test is not worth it. These are a few of the things form my experience, I think there is a big opportunity in helping programmers evaluate and improve the quality of their tests.

The tradeoff of TDD is summarized beautifully by Beck.

By saying everything two ways—both as code and as tests—we hope to reduce our defects enough to move forward with confidence. From time to time our reasoning will fail us and a defect will slip through. When that happens, we learn our lesson about the test we should have written and move on.

It's not about preventing all mistakes. It's about lessening the chance mistakes. Like refactoring tests I think this is something that is under-emphasized in the discussions about TDD. It is not a silver bullet. I think "we hope to reduce our defects enough to move forward with confidence" should be mentioned anytime someone mentions TDD. The point is not to be good at TDD, the point is to write good software. TDD is a tool that can help you write good software.

An interesting question is what counts as "good" software?

Chapter 3: Equality For All

Emmanuel Genard — Sun, 24 May 2020 14:42:29 +0000

Summary

Beck starts the chapter by introducing the concept of a value object. A value object cannot be mutated and so any message that changes the "value" in a value object should produce a new object. Dollar is on its way to becoming a value object. The refactoring in the previous chapter made the times method return a new Dollar object instead of mutating the amount.

Another property of a value object is responding to equals. This makes it comparable to other value objects of the same class.

public void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
}

He first implements equals by hardcoding the return value of equals.

public boolean equals(Object object) {
   return true;
}

He uses this as an opportunity to introduce triangulation.
Triangulation is adding a test to drive you towards a refactoring. A refactoring to a more generalized implementation. It's another tactic you can use when following the strategy of first making things work and then making things right. Beck says triangulation is useful when the refactoring is not obvious.

The second test is

public void testEquality() {
    assertTrue(new Dollar(5).equals(new Dollar(5)));
    assertFalse(new Dollar(5).equals(new Dollar(6)));
}

He finishes by implementing a more generalized equals. He postpones implementing other properties of value objects because they are not immediately necessary, but he adds those things to his test list.

Commentary

This chapter seems to be a way for Beck to introduce triangulation. However, he makes a few casual remarks that stood out to me.

In trying to explain the value of using triangulation he asks:

What axes of variability are you trying to support in your design?

I think this is a question that has many levels. There is the level of comparing instances of Dollar. There is the level of trying to add support for multiple currencies. There is another level of the whole WyCash bond portfolio management system. But I can only say "I think" because Beck does not offer any more explanation. Maybe it's just about comparing instances of Dollar.

Another remark is:

That will let us make “amount” private, as all good instance variables should be

Why should instance variables be private? What makes that a better design? He continually drops lines like this as if the reader shares his context. It's one of the most frustrating parts of the book.

Beck could not have known that the book would be read by people who don't share his background or sensibilities. Programming wasn't as a big an industry as it was when he wrote the book and there weren't so many different people trying to become better programmers. This makes the book difficult for people without some background in the design ideas that he uses to navigate towards an implementation.

Chapter 2: Degenerate Objects

Emmanuel Genard — Sun, 17 May 2020 22:21:38 +0000

TDD by Example: Chapter 2 Degenerate Objects

Summary

The chapter starts off with a summary of the "general TDD cycle". My summary of that summary is:

Write a test so your code has the API you want it to have.
Get the test to green as fast as possible. Don't worry about "clean code" or "design".
Improve the design of the code while keeping the tests green. Otherwise known as refactoring.

He explains that the idea behind these three steps is to reduce the cognitive load on the programmer. First get the code to work, then worry about how it's designed. This approach is in contrast to what he calls "architecture-driven development" which focuses on the design of the code first and then tries to get it to work.

He puts the ideas into practice using them to remove the side effects from the Dollar object that mutates the value of the amount property. He writes a test that passes if multiplying a Dollar object returned a new instance of Dollar whose amount is the result of the multiplication.

He changes the test from this:

public void testMultiplication() {
    Dollar five = new Dollar(5);
    five.times(2);
    assertEquals(10, five.amount);
    five.times(3);
    assertEquals(15, five.amount);
}

To this:

public void testMultiplication() {
    Dollar five = new Dollar(5);
    Dollar product = five.times(2);
    assertEquals(10, product.amount);
    product = five.times(3);
    assertEquals(15, product.amount);
}

He then introduces two tactics for quickly getting the tests to pass, hardcoding and implementation and doing the obvious thing. Hardcoding an implementation means that you write something to just get the tests to green. You then refactor the code into a real implementation while keeping the tests green. Doing the obvious thing is used when the real implementation is obvious to you. These are the two main tactics used by Beck. He mentions a third tactic, Triangulation, that will be explained in the following chapter.

The chapter ends with a paragraph talking about using your feelings to guide you. Beck used the feeling of something being wrong with the code to write a test that exposes the underlying reason for the feeling. Getting the test to pass made him feel better and improved the design.

Commentary

There is one great thing about this chapter and two problematic things.

I think the restatement of the TDD cycle and the example that followed is great. Repetition of the steps of TDD in a different way helped my understanding. I hope he does this many more times throughout the book.

The goal is clean code that works (thanks to Ron Jeffries for this pithy summary). Clean code that works is out of the reach of even the best programmers some of the time, and out of the reach of most programmers (like me) most of the time. Divide and conquer, baby. First we'll solve the “that works” part of the problem. Then we'll solve the “clean code” part.

I think this quote captures the power of TDD as a design tool. By writing the test, getting it to past and then worrying about the design of the code, you can be sure that your design works as longs the tests still pass.

The problems start right after:

This is the opposite of architecture-driven development, where you solve “clean code” first, then scramble around trying to integrate into the design the things you learn as you solve the “that works” problem.

Sometimes you need to think about the problem before writing any code. And one of the best tools for thinking is drawing. It externalizes your thoughts and helps you see the problem at a different level of abstraction. It is also faster feedback than writing code. I don't know if drawing a UML diagram or any other type of diagram is what Beck means by "architecture-driven development". He doesn't explain it. He just takes a passing shot.

In my experience, if I can represent the problem or different solutions to the problem at a different level of abstraction this can lead to insights that are difficult to see when down in the code. A diagram can help answer the question, "What tests should I write?" or "Where should I start?". It's also much cheaper to explore different approaches with drawings than with code. You can just erase a whiteboard or throw out a piece of paper.

The other thing I have a problem is this:

The translation of a feeling (for example, disgust at side effects) into a test (for example, multiply the same Dollar twice) is a common theme of TDD.

When he was writing this book Beck was already an expert at programming and at TDD. He had been doing both long enough to have built up an intuition. He could feel when something was wrong. A person just learning will not have that intuition. I think it would have been a more useful for a wider range of people if he took the time to point out exactly what was wrong with the design. Implying that anyone reading this book can go off a feeling, especially the same feelings he has, is something that can alienate the readers.

TDD By Example: Chapter 1 Multi-Currency Money

Emmanuel Genard — Thu, 16 Apr 2020 01:51:17 +0000

Summary

The first part of this chapter Beck gathers requirements and starts to define the acceptance criteria. He doesn't call what he does by those names but when he writes:

What behavior will we need to produce the revised report? Put another way, what set of tests, when passed, will demonstrate the presence of code we are confident will compute the report correctly?

I think he is talking about putting the requirements for the code into the tests.

He describes that he is going to put everything he needs to do on a list. He is going to focus on one thing at a time. He will add things to the list as they come up.

We start to understand one of the main tactics of TDD.

When we write a test, we imagine the perfect interface for our operation.

He writes the test so that code has the API he wants it to have. He then gets the test to green as fast as he can. One of the most important things in TDD is to get to a passing test as fast as possible.

You probably aren't going to like the solution, but the goal right now is not to get the perfect answer but to pass the test.

The TDD cycle:

Add a little test.

Run all tests and fail.

Make a little change.

Run the tests and succeed.

Refactor to remove duplication.

There is a sidebar on "Dependency and Duplication". He mentions that dependencies are the key problem in software at all scales and that the key to removing dependencies is remove duplication.

There is now a refactoring where duplication is removed in very small steps.

Do these steps seem too small to you? Remember, TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps.

Commentary

I think the sidebar on dependency and duplication is the most interesting thing in the chapter. When he writes:

Dependency is the key problem in software development at all scales.

my eyes stop.

I wonder if that's true. I think about on my own experience and I feel like there is some truth to it. But could it really be the "key" problem? And can the answer to the "key" problem be as simple finding duplication and removing it?

I have these questions in my mind as I read on. Some part of me feels like there is a lot truth to that statement. Some part of me feels that there are much more pressing problems, like building trust on a team.

The rest of the chapter is a good introduction to the technique of TDD. Beck emphasizes small focused steps. I appreciate that approach more and more in my day to day work. I'm starting to feel that I actually move faster taking as small a step as possible.

TDD by Example: Part 1: The Money Example

Emmanuel Genard — Tue, 14 Apr 2020 17:32:11 +0000

Summary

Beck opens this part of the book giving a summary of what to expect. He lays out the rhythm of TDD and what the reader will find surprising. There isn't much to summarize here so I'll just quote him.

Quickly add a test.

Run all tests and see the new one fail.

Make a little change.

Run all tests and see them all succeed.

Refactor to remove duplication.

The surprises are likely to include

How each test can cover a small increment of functionality

How small and ugly the changes can be to make the new tests run

How often the tests are run

How many teensy-weensy steps make up the refactorings

Commentary

These seem simple enough and self explanatory. I didn't think I would have any thoughts other than, "Let's start!". But then I remembered how often I've tried to add a test and had no idea what to do.

I don't see:

How to know what test to write

I think step 0 could be the most important. It would help answer not just what the next test is but how many there are and what they cover. It might help answer what kind of test to write. Which would probably be lead to:

-1. The many kinds of tests and what they cover.

But it's likely that those two steps would require a different book.

TDD by Example: Introduction

Emmanuel Genard — Sun, 12 Apr 2020 23:52:37 +0000

Summary

Beck tells a story. It starts with an unexpected new requirement. The CEO of the company they work for asks if the bond portfolio management system the company is selling could be changed to support multiple currencies. Ward Cunningham gets a couple of days to think about it.
The Dollar object originally had calculation and formatting responsibilities but those have been refactored away. The built-in classes of Smalltalk could handle the calculations. The formatting was done in the user interface classes. The Dollar object is just used as a counter in calculating something in the user interface that deals with averages. He tries to substitute Currency for Dollar and finds that it can support it. He then tries to see what happens if the currencies being calculated are different and finds that can also be supported. He runs the tests and after fixing a few failing tests he checks in the code.

Beck analyses the story. When the system was proved to be able to support multiple currencies, it multiplied the value of the system and thus the company that was selling it. This was because Ward Cunningham and his team were experienced making changes to the design of the system, they understood how valuable it would be to the business if they were able to make the system multi-currency, and automatic tests and good separation of concerns allowed them to make changes and have the confidence that their whole system still worked.

Beck then says that this kind of progress is possible for most programmers, except for geniuses(they do not need any method) and idiots(no method will help them). If they follow these two simple rules:

Write a failing test before you write any code
1. Remove duplication

The rest of the book is about how complicated it can be to follow those two simple rules.

Commentary

It's a neat story. The good programmer because of his good programming has made a system that can respond to unexpected requirements from the business and deliver features that multiply business value.

The thing that sticks out to me is that are lines like:

After six months of careful paring, the resulting Dollar didn't have much responsibility left.

And

Ward and the WyCash team needed to have constant experience growing the design of the system, little by little, so the mechanics of the transformation were well practiced.

These quotes tell me of an almost ideal work environment for programming. One where you can spend six months carefully refactoring essential parts. One where your whole team believes this kind of thing is worth improving. One where the business stakeholders see the value in this.

Beck acknowledges my skepticism when he says:

Does this mean that if you are not one of the ten best software engineers on the planet and don't have a wad of cash in the bank so you can tell your boss to take a hike, then you're going to take the time to do this right, that such moments are forever beyond your reach?

I think about what is within my reach. If I'm pairing with somebody I may not be able always convince them to write a failing test first but I can always suggest it. And when I'm programming solo I can always do it. I may not always have the time to work on removing duplication, especially if it's not obvious duplication. I may not know enough of the domain to understand that the same concept is being encoded in two different places.

If I do these things maybe one day I can tell a neat story too. I was a good programmer and because of my good programming I made a system that can respond to unexpected requirements from the business and deliver features that multiply business value.