3 ms·

> With REPL driven development, there's nothing of the sort. Wouldn't there be production code that you can read? You're already working in the codebase after

• ethagnawl 6y ago
  In the specific case I have in mind, there was a business process that involved multiple pieces of the application being used to accomplish a task (creating database entries, etc.). Prior to my inheriting the project, this had been done in an ad hoc manner using the REPL and was not documented. When I had to try to run this process myself, I had nothing to go on. This is absolutely the result of poor practices and, documentation aside, if the developers had been using tests to drive out this behavior, I'd have had a sort of playbook that I could reference.
  • gmfawcett 6y ago
    That sounds horrible! But this is an operational failure, not a development one. (Well, the one clear development gap is that nobody thought to write a script to replace all those REPL commands. There's no reason that couldn't have been done, that's not a REPL issue at all.) It's not uncommon for REPL users to write tests for their code. And nobody worth their salt would think that the REPL is a license not to document and operationalize their work properly! Your root cause seems to be some mix of developer laziness or inexperience, and poor business practice -- not really a tooling issue.