In this talk from GOTO Berlin 2013, Cory Foy discusses the importance of listening to your code to know when to refactor, test, and build solutions which will withstand the test of time.

1. When Code Cries
Cory Foy
@cory_foy
foyc@coryfoy.com
http://www.coryfoy.com
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Reading from Timeless Way. Then: All of us here are technologists in some way. We desire to
build things that people will use. Living software. But if you look at our industry, the fruit of
our labors is not living software. The majority of software out there has a common attribute.
It is:
1

2. Bad Code
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Bad Code is the bane of the software industry. Why is it that, over time, code becomes harder
and harder to work with - and how can we prevent ours from ending up with the same fate?
To answer that, perhaps we should start with identifying what quality code is. So, is this
quality code?
2

3. Is this quality code?
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Why do we like Easy to Change code? Because it is a lower cognitive burden. Because writing
code is hard enough, as we’ll see.
3

4. Cognitively Undemanding
Where we want our
software
Context
Embedded
Context
Reduced
Modifying Software we
wrote
#gotober @cory_foy
Modifying Software we
didn’t write
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
We want code that is in the upper right quadrant. But, if we’re lucky to be modifying our own
code, it’s in the lower left. Worse case, we don’t even have the context, so it’s in the lower
right. Now, if we have tests, that helps increase the context. But when we don’t, we can end
up with code that looks like
4

5. #gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
5
Code that isn’t a joy. That is anti-joy. Code which is frustrating to be around. This is not code
that is alive - this is code which has problems. And these problems - we tend to name them
something. When we see something not right in code, what do we say?

6. Code Smells
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
6
Right - “Smelly Code”. But what I’d like to do today is reframe the discussion slightly. Instead
of telling our code that it smells, let’s recognize something else - our code is trying to talk to
us.

7. Code Talks
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
And imagine trying to talk to someone about something important - say, the building is on
fire - and them not understanding your strange gestures and telling you you are smelly.
Would that make you happy? It doesn’t make our code happy. And if I can take some poetic
license, I’d even say that code cries
7

8. Code Cries
Because No One
Understands What It Is
Saying
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
8
And our code cries not because it is smelly, but because no one understands what it is trying
to say. It’s trying to point out what it wants to do, what is important, and how to use it. And it
isn’t happy about that! Too often we try to force what we want, what we think is best.

9. “...we have so far beset ourselves with rules, and
concepts, and ideas...that we have become afraid of
what will happen naturally, and convinced that we must
work within a “system” and with “methods” [or] our
surroundings will come tumbling down in chaos.”
Christopher Alexander - “The Timeless Way of Building”
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
9
We turn to our UML and architecture diagrams and design documents, trying to brute force a
system that will work, afraid that if we don’t - chaos. But nature *dictates* an iterative design
- one where the best path is not only discovered, but continually chosen. We literally can not
build software any other way.

10. #gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
10
This is a map of the Mississippi River in the United States. What’s special about it is that it is all of the routes the
river has run through the years. We create a design. We settle down, build a house, have a family. But the code
doesn't want that. It has plans beyond our design. And if we don't listen to those plans, our days will become filled
with holding off the impending - and inevitable - change (http://www.adammandelman.net/tag/harold-fisk/)

11. #gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
11
For example, in 2011, the Mississippi River tried to change course, I believe to the Orange
area. And it normally would have - except for the millions of dollars the Army Corp of
Engineers spent to erect dams, flood farm fields and otherwise keep it on the course best for
us - not for it. But trying to brute force design into nature’s iterative process isn’t the only
problem. (10k next)

12. Ten Thousand Hours
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
12
There’s a common figure that is given to developers about what it takes to become great in
software. Does anyone know that number? <Click> This is the number of hours to “master” a
skill. But as much as we tout this, we don’t really act like this is important. People new to
software either get this

13. bloody
#gotober @cory_foy
Friday, October 18, 13
So, confusion and frustration, or this
foyc@coryfoy.com
13

14. #gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Empty promises! (Beaker story). Can you imagine learning C++ in 24 hours? Well, you might
be able to learn syntax, but programming isn’t about syntax. It’s about communication,
precisely why they are called programming languages. But learning communication is hard,
and we don’t have time for that! (Jr vs Sr next)
14

15. Number of Results for
“X Developer”
Linked In:
Junior Developer: 17,157
Senior Developer: 123,634
Google:
Junior Developer: 1,060,000
Senior Developer: 4,290,000
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
We have a gap there. If we really want to make it better, we have to figure out how to fill that
gap. And it turns out we can look at how we classify and learn natural languages and create
some interesting parallels to software
15

16. Imperative Programming
Functional Programming
Logic Programming
Dynamic Typing
Static Typing
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
16
The first is how different languages - and paradigms - can affect our viewpoints. Linguist
Roman Jakobson points out “Languages differ essentially in what they must convey and not in
what they may convey”. For example, if I said, in English, I had dinner with a neighbor last
night, I wouldn’t have to reveal if it was a male or female. But if I said the same thing in
French or German, I would be obliged to (voisin vs voisine and Nachbar vs Nachbarin). So
they same can be said for programming languages. Functional must express problems in the
context of reduction of terms. Imperative expresses problems as a statement of the process,
and logic expresses problems as a statement of the result. Static typing forces us to
abstractions sooner, while dynamic typing allows the abstraction to be held off

17. Coding Standards Define Dialects
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
17
The second is that even within languages we have dialects. We have to agree on what that
common dialect is going to be. This is traditionally the essence of coding standards - what is
our agreed upon dialect?

18. Cognitively Undemanding
- Copying from the board
- Reading a Map
- Face to Face Conversation
- Selecting food in the
lunchroom
BICS
- Following a class schedule
- Telephone Conversation
- Oral Presentations
- Getting an absence excuse
Context
Embedded
Context
Reduced
- Demonstrations
- Basic Math
Computations
- Science Experiments
- Standardized Tests
- Math Concepts and
Applications
- Listening to a Lecture
CALP
#gotober @cory_foy
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
The process of learning a natural language has been mapped in two ways. If we look at this
model, we can now do something similar with programming. We can create a model to show
where our gaps are - both in teaching, and in our own learning.
18

19. Foy-Z
Cognitively Undemanding
BICS
Katas
Koans
Context
Embedded
Context
Reduced
Principles and
Patterns
Writing Production
Code
CALP
#gotober @cory_foy
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
This model, which I’m calling the “Foy-Z” model, since my name isn’t Jay, looks like this. We
need to start by providing context. Katas provide low cognitive challenge to practice
expanding viewpoints. Koans provide language specific nuances. Principles and Patterns
provide guides for forces you’ll encounter, and it takes all of the above to write production
code.
19

20. Katas
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Let’s start with Katas. First described in the software world by Pragmatic Dave Thomas, they
offer the ability to practice without the solution being the cognitive challenge. In short, they
allow developers to practice varying externally motivated viewpoints.
20

21. Conway’s Game of Life
- Infinite Grid of Cells
- Each Cell has two states - alive or dead
- Interacts with neighbors in a well known way
http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
21

22. Conway’s Game of Life - If Statement
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
22

23. Conway’s Game of Life - No Conditional
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
23

24. Foy-Z
Cognitively Undemanding
BICS
Katas
Koans
Context
Embedded
Context
Reduced
Principles and
Patterns
Writing Production
Code
CALP
#gotober @cory_foy
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
So Katas allow us to not focus on solving the problem, but instead using the problem to
explore the space of viewpoints. The context is very high - we cognitively understand the
problem, so we can focus on practice. But at some point we need more - and that’s where
24

25. Koans
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
25
Koans come in. Koans provide language-specific nuances - the grammar if you will. They
tend to be language specific, but lower context. It’s like practicing nouns and verbs - great to
do, but much better if you have some context to put them in. For example (next Edgecase
Koans)

26. https://github.com/neo/ruby_koans
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
one of the more famous software Koans was by Edgecase (now called Neo). You can see in
the structure it was very specific to the Ruby language - arrays, assets, blocks, etc.
26

27. Ruby Koans Asserts
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
27

28. Ruby Koans Arrays
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
28

29. Foy-Z
Cognitively Undemanding
BICS
Katas
Koans
Context
Embedded
Context
Reduced
Principles and
Patterns
Writing Production
Code
CALP
#gotober @cory_foy
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
So far, we’ve stayed in the BICS realm. BUT! We’ve learned something interesting. The Koans
taught us Ruby array management, and we needed that for our exercise, so let’s revisit the
Katas
29

30. Conway’s Game of Life - With Map
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
30

31. Foy-Z
Cognitively Undemanding
BICS
Katas
Koans
Context
Embedded
Context
Reduced
Principles and
Patterns
Writing Production
Code
CALP
#gotober @cory_foy
Cognitively Demanding
foyc@coryfoy.com
Friday, October 18, 13
At this point, we have enough basic skills that we can begin to get into cognitively
demanding work. As I mentioned earlier, Design Patterns
31

32. Principles and
Patterns
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
32
Design Patterns provide a guide for the forces encountered. What does that mean? We have a
tendency to think of Design Patterns as recipes to make our code look a certain way. But

33. 4 Rules of Simple Design
Does this code
express all of the
ideas we want to
express?
Are there concepts
from our domain
that can be
expressed?
#gotober @cory_foy
Friday, October 18, 13
Patterns. 4 Rules of Simple Design. Fowler. SOLID
foyc@coryfoy.com
33

34. Fowler’s Perspectives (from UML Distilled)
Are we operating at
the right level Conceptual,
Specification or
Implementation?
#gotober @cory_foy
Friday, October 18, 13
Patterns. 4 Rules of Simple Design. Fowler. SOLID
foyc@coryfoy.com
34

35. SOLID Principles
Do we have
duplication
(implementation or
conceptual)?
Single
responsibilities?
LoD violations?
LSP violations?
#gotober @cory_foy
Friday, October 18, 13
Transition to patterns
foyc@coryfoy.com
35

36. Naming something the name of a pattern
does not make it that pattern
Putting patterns in our code does not
make our code good
#gotober @cory_foy
Friday, October 18, 13
Patterns are something else.
foyc@coryfoy.com
36

37. Porch Swing
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
37

38. Swimming Pool
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
38

39. Hedge Trimmer
#gotober @cory_foy
Friday, October 18, 13
Not a pattern, but a death trap (next GoF Book / Structure of Patterns)
foyc@coryfoy.com
39

40. • Pattern Name
• Intent
• Also Known As
• Motivation / Forces
• Applicability
• Structure
• Participants
• Collaboration
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Patterns
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
The GoF Book wasn’t a beginners guide. It was Erich’s PhD Thesis. Patterns are designed to
put into form the forces you may run into while building code. What does that mean?
40

41. Multiple
Pictures
- Countries
- Products
- Locations
Send
Pictures
- Send Data
- Receive Data
Server
#gotober @cory_foy
Storage Options
foyc@coryfoy.com
Friday, October 18, 13
Let’s imagine a mobile application to upload pictures. So what forces are at play here? We
know we have to associate multiple pictures to data. Data can have new types added, which
need to be available on all other phones. The phone needs to be able to send the pictures to
the server, as well as send and receive data updates. And deal with offline conditions.
41

42. Offline
Not allow send
Automatically
Forces:
- Store multiple requests
- Schedule to run them
- Handle failed requests
- Allow user to see
status
#gotober @cory_foy
Queue items to send
Manually
Forces:
- User has to remember to
send
- User can’t do other tasks
until sent
- User has to send each one
foyc@coryfoy.com
Friday, October 18, 13
One way is by knowing the forces at play and comparing them to previous events. For
example, the phone (or server) could be offline. What can we do if we are offline?
42

43. http://www.soapatterns.org/asynchronous_queuing.php
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
So the patterns we choose are a result of the forces we are trying to resolve - the forces
inherent in the solution itself.
43

44. Foy-Z
Cognitively Undemanding
BICS
Katas
Koans
Context
Embedded
Context
Reduced
Principles and
Patterns
Writing Production
Code
CALP
#gotober @cory_foy
Cognitively Demanding
Friday, October 18, 13
Finally, we can get to writing production code...
foyc@coryfoy.com
44

45. Writing Production
Code
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
45
This is the most demanding of all. Why? Sure, it seems easy when we have greenfield projects
- but have we forgotten already about (We think of legacy code as old code, but there are
people writing legacy code right this very second)

46. Legacy Code
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
46
Let’s look at some legacy code. This is from an app which scores a bowling game. In bowling
parlance, a game consists of 10 frames. The first 9 frames can have 1 or 2 rolls (depending
upon whether all of the pins are knocked down in the first roll) while the last frame can have
up to three rolls (depending upon whether the player knocked down all the pins in the first
two rolls). Explain scoring. So we can extract out some logic here to reduce our cognitive load

47. After Refactor
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
47

48. After Refactor
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
48

49. To Listen, We Must Understand
To Understand, We Must Practice
To Practice, We Must Have Context
#gotober @cory_foy
foyc@coryfoy.com
Friday, October 18, 13
Software is not something we will solve through force. It is instead something that we must
learn to listen to, to feel what our code is telling us. It is through this method that we can
create software which is alive. And software which is alive is software that will survive to
match our vision of building great software to help the world, instead of having the world
utter the time honored phrase of “WTF?”
49

50. Cory Foy
(@cory_foy)
foyc@coryfoy.com
www.coryfoy.com
#gotober @cory_foy
Friday, October 18, 13
foyc@coryfoy.com
50