Combating Fear Driven Development

Photo by Tim Trad on Unsplash

Here’s a list of techniques that help me combat “Fear Driven Development”:

Test Driven Development

Does this code work? Will it work in the future with the rest of my team’s changes? What was I working on or where do I begin?

• Writing a failing test first helps me understand the inputs, outputs, and names of functions that I need to implement.
• Need to walk away briefly? — come back to a failing test.
• If I’m pairing, we don’t have to argue about implementation details, whatever makes the test pass can easily be changed for something better.
• I can easily validate my work with the latest git pull .

Type Driven Development

How do I ensure everyone will remember to use and test this piece of logic?

• Encoding logic into the type system means no longer have to worry about missing tests.
• Compilation act as another form of expressive feedback
• I can offload details to the computer and keep my working memory free for more important things.
• Not having to fear that an illegal state may be lurking in the system because I’ve made it unrepresentable by the type system.

Mikado Method

Large structural changes are scary. How do I more effectively break down the problem while making progress?

• I don’t have to spend time guessing how to subdivide the problem, it happens naturally.
• I can easily rotate into another pair or team and have anyone else on the team pick up the work with the context provided by the mikado graph.
• I can more readily answer the question, “how are we progressing and what have we done?”
• I can commit and push smaller structural improvements along the way.

Continuous Integration/Deployment

When can we release a new version to our customers or look at our current progress?

• Repeatable builds and deployments means no snowflakes that hide dependencies
• Important safe guards are automatically executed before each deployment
• All passing tests reassure the team that no breaking changes were introduced
• Easily rollback to a previous build

Functional Programming

Does the code contain any side effects?

• I can refactor code with greater confidence with equational reasoning.
• Code without side effects is more testable.
• Side effects are more readily found and can be pushed to the edges of the system and dealt with a different level of care.