When Code Cries Cory Foy @cory_foy foyc@coryfoy.com - - PDF document

▶
when code cries
SMART_READER_LITE
LIVE PREVIEW

When Code Cries Cory Foy @cory_foy foyc@coryfoy.com - - PDF document

Jan 02, 2023 483 likes •995 views

When Code Cries Cory Foy @cory_foy foyc@coryfoy.com http://www.coryfoy.com #gotober @cory_foy foyc@coryfoy.com Friday, October 18, 13 1 Reading from Timeless Way. Then: All of us here are technologists in some way. We desire to build

slide-1
SLIDE 1

#gotober @cory_foy foyc@coryfoy.com

When Code Cries

Cory Foy @cory_foy foyc@coryfoy.com http://www.coryfoy.com

1 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

  • ur labors is not living software. The majority of software out there has a common attribute.

It is:

slide-2
SLIDE 2

#gotober @cory_foy foyc@coryfoy.com

Bad Code

2 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?

slide-3
SLIDE 3

#gotober @cory_foy foyc@coryfoy.com

Is this quality code?

3 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.

slide-4
SLIDE 4

#gotober @cory_foy foyc@coryfoy.com

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Where we want our software Modifying Software we wrote Modifying Software we didn’t write

4 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

slide-5
SLIDE 5

#gotober @cory_foy foyc@coryfoy.com

5 Friday, October 18, 13

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?
slide-6
SLIDE 6

#gotober @cory_foy foyc@coryfoy.com

Code Smells

6 Friday, October 18, 13

Right - “Smelly Code”. But what I’d like to do today is reframe the discussion slightly. Instead

  • f telling our code that it smells, let’s recognize something else - our code is trying to talk to

us.

slide-7
SLIDE 7

#gotober @cory_foy foyc@coryfoy.com

Code Talks

7 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

slide-8
SLIDE 8

#gotober @cory_foy foyc@coryfoy.com

Because No One Understands What It Is Saying Code Cries

8 Friday, October 18, 13

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.

slide-9
SLIDE 9

#gotober @cory_foy foyc@coryfoy.com

“...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 W ay of Building”

9 Friday, October 18, 13

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.

slide-10
SLIDE 10

#gotober @cory_foy foyc@coryfoy.com

10 Friday, October 18, 13

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 ofg the impending - and inevitable - change (http://www.adammandelman.net/tag/harold-fisk/)

slide-11
SLIDE 11

#gotober @cory_foy foyc@coryfoy.com

11 Friday, October 18, 13

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)
slide-12
SLIDE 12

#gotober @cory_foy foyc@coryfoy.com

TenThousand Hours

12 Friday, October 18, 13

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

slide-13
SLIDE 13

#gotober @cory_foy foyc@coryfoy.com

bloody

13 Friday, October 18, 13

So, confusion and frustration, or this

slide-14
SLIDE 14

#gotober @cory_foy foyc@coryfoy.com

14 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)

slide-15
SLIDE 15

#gotober @cory_foy foyc@coryfoy.com

Linked In: Junior Developer: 17,157 Senior Developer: 123,634 Google: Junior Developer: 1,060,000 Senior Developer: 4,290,000

Number of Results for “X Developer”

15 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

slide-16
SLIDE 16

#gotober @cory_foy foyc@coryfoy.com

Functional Programming Imperative Programming Logic Programming Static Typing Dynamic Typing

16 Friday, October 18, 13

The first is how difgerent languages - and paradigms - can afgect our viewpoints. Linguist Roman Jakobson points out “Languages difger 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 ofg

slide-17
SLIDE 17

#gotober @cory_foy foyc@coryfoy.com

Coding Standards Define Dialects

17 Friday, October 18, 13

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

  • ur agreed upon dialect?
slide-18
SLIDE 18

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding

  • Copying from the board
  • Reading a Map
  • Face to Face Conversation
  • Selecting food in the

lunchroom

  • Following a class schedule
  • Telephone Conversation
  • Oral Presentations
  • Getting an absence excuse
  • Demonstrations
  • Basic Math

Computations

  • Science Experiments
  • Standardized Tests
  • Math Concepts and

Applications

  • Listening to a Lecture

18 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.

slide-19
SLIDE 19

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Katas Koans Principles and Patterns Writing Production Code Foy-Z

19 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.

slide-20
SLIDE 20

#gotober @cory_foy foyc@coryfoy.com

Katas

20 Friday, October 18, 13

Let’s start with Katas. First described in the software world by Pragmatic Dave Thomas, they

  • fger the ability to practice without the solution being the cognitive challenge. In short, they

allow developers to practice varying externally motivated viewpoints.

slide-21
SLIDE 21

#gotober @cory_foy foyc@coryfoy.com

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

21 Friday, October 18, 13

slide-22
SLIDE 22

#gotober @cory_foy foyc@coryfoy.com

Conway’s Game of Life - If Statement

22 Friday, October 18, 13

slide-23
SLIDE 23

#gotober @cory_foy foyc@coryfoy.com

Conway’s Game of Life - No Conditional

23 Friday, October 18, 13

slide-24
SLIDE 24

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Katas Koans Principles and Patterns Writing Production Code Foy-Z

24 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

slide-25
SLIDE 25

#gotober @cory_foy foyc@coryfoy.com

Koans

25 Friday, October 18, 13

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)

slide-26
SLIDE 26

#gotober @cory_foy foyc@coryfoy.com https://github.com/neo/ruby_koans

26 Friday, October 18, 13

  • ne 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.

slide-27
SLIDE 27

#gotober @cory_foy foyc@coryfoy.com

Ruby Koans Asserts

27 Friday, October 18, 13

slide-28
SLIDE 28

#gotober @cory_foy foyc@coryfoy.com

Ruby Koans Arrays

28 Friday, October 18, 13

slide-29
SLIDE 29

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Katas Koans Principles and Patterns Writing Production Code Foy-Z

29 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

slide-30
SLIDE 30

#gotober @cory_foy foyc@coryfoy.com

Conway’s Game of Life - With Map

30 Friday, October 18, 13

slide-31
SLIDE 31

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Katas Koans Principles and Patterns Writing Production Code Foy-Z

31 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

slide-32
SLIDE 32

#gotober @cory_foy foyc@coryfoy.com

Principles and Patterns

32 Friday, October 18, 13

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

slide-33
SLIDE 33

#gotober @cory_foy foyc@coryfoy.com

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?

33 Friday, October 18, 13

  • Patterns. 4 Rules of Simple Design. Fowler. SOLID
slide-34
SLIDE 34

#gotober @cory_foy foyc@coryfoy.com

Fowler’s Perspectives (from UML Distilled) Are we operating at the right level - Conceptual, Specification or Implementation?

34 Friday, October 18, 13

  • Patterns. 4 Rules of Simple Design. Fowler. SOLID
slide-35
SLIDE 35

#gotober @cory_foy foyc@coryfoy.com

SOLID Principles Do we have duplication (implementation or conceptual)? Single responsibilities? LoD violations? LSP violations?

35 Friday, October 18, 13

Transition to patterns

slide-36
SLIDE 36

#gotober @cory_foy foyc@coryfoy.com

Naming something the name of a pattern does not make it that pattern Putting patterns in our code does not make our code good

36 Friday, October 18, 13

Patterns are something else.

slide-37
SLIDE 37

#gotober @cory_foy foyc@coryfoy.com

Porch Swing

37 Friday, October 18, 13

slide-38
SLIDE 38

#gotober @cory_foy foyc@coryfoy.com

Swimming Pool

38 Friday, October 18, 13

slide-39
SLIDE 39

#gotober @cory_foy foyc@coryfoy.com

Hedge Trimmer

39 Friday, October 18, 13

Not a pattern, but a death trap (next GoF Book / Structure of Patterns)

slide-40
SLIDE 40

#gotober @cory_foy foyc@coryfoy.com

  • Pattern Name
  • Intent
  • Also Known As
  • Motivation / Forces
  • Applicability
  • Structure
  • Participants
  • Collaboration
  • Consequences
  • Implementation
  • Sample Code
  • Known Uses
  • Related Patterns

40 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?

slide-41
SLIDE 41

#gotober @cory_foy foyc@coryfoy.com

  • Countries
  • Products
  • Locations

Multiple Pictures Send Pictures

Server

  • Send Data
  • Receive Data

Storage Options

41 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 offmine conditions.

slide-42
SLIDE 42

#gotober @cory_foy foyc@coryfoy.com

Offline

Not allow send Queue items to send Automatically Manually

Forces:

  • Store multiple requests
  • Schedule to run them
  • Handle failed requests
  • Allow user to see

status Forces:

  • User has to remember to

send

  • User can’t do other tasks

until sent

  • User has to send each one

42 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 offmine. What can we do if we are offmine?

slide-43
SLIDE 43

#gotober @cory_foy foyc@coryfoy.com

http://www.soapatterns.org/asynchronous_queuing.php

43 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.

slide-44
SLIDE 44

#gotober @cory_foy foyc@coryfoy.com

BICS CALP

Context Reduced Context Embedded Cognitively Undemanding Cognitively Demanding Katas Koans Principles and Patterns Writing Production Code Foy-Z

44 Friday, October 18, 13

Finally, we can get to writing production code...

slide-45
SLIDE 45

#gotober @cory_foy foyc@coryfoy.com

Writing Production Code

45 Friday, October 18, 13

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)

slide-46
SLIDE 46

#gotober @cory_foy foyc@coryfoy.com

Legacy Code

46 Friday, October 18, 13

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

slide-47
SLIDE 47

#gotober @cory_foy foyc@coryfoy.com

After Refactor

47 Friday, October 18, 13

slide-48
SLIDE 48

#gotober @cory_foy foyc@coryfoy.com

After Refactor

48 Friday, October 18, 13

slide-49
SLIDE 49

#gotober @cory_foy foyc@coryfoy.com

To Listen, We Must Understand To Understand, We Must Practice To Practice, We Must Have Context

49 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?”

slide-50
SLIDE 50

#gotober @cory_foy foyc@coryfoy.com

Cory Foy (@cory_foy) foyc@coryfoy.com www.coryfoy.com

50 Friday, October 18, 13