# REPL Driven Design

DevFeed: [REPL Driven Design](<https://devfeed.tech/articles/repl-driven-design-21787.md>)

Original publisher: [Read original article](<http://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenDesign.html>)

Published: 2020-05-27T00:00:00Z

Content type: opinion

Language: en

Sources: [Robert C. Martin](<https://devfeed.tech/sources/robert-c-martin.md>), [The Clean Code Blog](<https://devfeed.tech/sources/the-clean-code-blog.md>)

Topics: [Clojure](<https://devfeed.tech/topics/clojure.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Code](<https://devfeed.tech/topics/code.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [clojure](<https://devfeed.tech/tags/clojure.md>), [code](<https://devfeed.tech/tags/code.md>), [coronavirus](<https://devfeed.tech/tags/coronavirus.md>), [data](<https://devfeed.tech/tags/data.md>), [github](<https://devfeed.tech/tags/github.md>), [mocking](<https://devfeed.tech/tags/mocking.md>), [tdd](<https://devfeed.tech/tags/tdd.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

The article reflects on using REPL Driven Design while developing a Clojure program that processes daily Coronavirus statistics from the Johns Hopkins GitHub repository. The author found REPL experiments and tests fast and confidence-building, and real production data reduced the need for mocks and fake data. However, a later design change exposed weak verification, delayed the change, and ultimately allowed a bug into production that was discovered four days later.

## Source excerpt

If you follow me on facebook you know that I've been publishing daily CoronaVirus statistics. I generate these statistics using the daily updates in the Johns Hopkins github repository. At first I just hand copied the data into a spreadsheet. But that became tedious quite rapidly. Then, in late March, I wrote a little Clojure program to extract and process the data. Every morning I pull the repo, and then run my little program. It reads the files, does the math, and prints the results. Of course I used TDD to write this little program. But over the last several weeks I've made quite a few small modifications to the program; and it has grown substantially. In making these adaptations I chose to use a different discipline: REPL Driven Design. REPL Driven Design is quite popular in Clojure circles. It's also quite seductive. The idea is that you try some experiments in the REPL to make sure you've got the right ideas. Then you write a function in your code using those idea. Finally, you test that function by invoking it at the REPL. It turns out that this is a very satisfying way to work. The cycle time - the time between a code experiment and the test at the REPL - is nearly as small as TDD. This breeds lots of confidence in the solution. It also seems to save the time needed to mock, and create fake data because, at least in my case, I could use real production data in my REPL tests. So, overall, it felt like I was moving faster than I would have with TDD. But then, in late April, I wanted to do something a little more complicated than usual. It required a design change to my basic structure. And suddenly I found myself full of fear. I had no way to ensure that those design changes wouldn't leave the system broken in some way. If I made those changes, I'd have to examine every output to make sure that none of them had broken. So I postponed the change until I could muster the courage, and set aside the dedicated time it would require. The change was not too painful.