In January 2019, I had an epiphany of sorts. I came across a blog post by Kent Beck called test && commit || revert and started looking into what this meant to me. TCR is an idea that blew my mind after trying it out for a day.

I’ve written about the way I auto-commit every successful build into a special repository in order to ensure I don’t lose work so I was almost there. My test was “does it build” and the commit was automatic if it did. TCR takes this much further but you can see why the idea resonated with me so strongly.

I had been writing some really tricky code (for me anyway) to do with parsing IMAP responses and I’d written quite a lot of unit tests to test my string tokeniser as some of the responses can get quite complex. I don’t always use TDD but this really needed it so I was already back in that test-first frame of mind when I discovered TCR.

As an iOS and Mac developer, my primary tool is Xcode which has had Swift Playgrounds for a while but I could never figure out how to use them in my everyday work. After watching this video demonstrating TCR by Kent Beck, I set about trying to make TCR work in a Swift Playground. I ended up writing a couple of command line tools and Keyboard Maestro macros to get it to work.

I had also agreed to teach programming at my children’s school and was looking at different approaches and tools to use to teach programming. I learnt with BASIC running on an 8-bit processor with no debugger etc… Sometimes that simple world seems so much more approachable than the infinite choices and complexity available today. I wanted a Playground-based approach that was not just toying with Swift but one that I could do serious work with as well.

To say the least, Xcode and Swift Playgrounds are not really set up to do this yet but with my tools and macros it is workable and I think gives a faster development process than using Xcode’s unit testing framework. I’d long-ago eschewed putting everything into frameworks for a simpler approach inspired by Wil Shipley’s 2005 blog post which meant that I was already in the mindset of managing my source files by sharing them directly (or links to them) rather than packaging them up in frameworks. I had a tool at the back of my mind for a while. Yesterday, I made the first version of it that extracts working code from a Playground and delivers it to the right folders to be integrated into other projects. My motivatioon being my belief that current version control systems are too complex for a solo developer like me and introduce a ton of overhead. I never know what to put in my commit messages and often forget to commit at the right time. As I operate a monolithic repository and flit between projects far too much, I dread to think what my commit history looks like. The truth is that all I care about is that I don’t lose working code and that if I make an improvement somewhere it will be duplicated to everywhere instantly rather than finding out that an API has changed months after I changed it.

During my research into Playgrounds I came across another video from a talk by Brando Williams on how Kickstarter had made good use of Playgrounds. This reaffirmed that I was on to something by trying to use Swift Playgrounds as a development tool and not just a toy.

When talking to children and novices, I don’t want to go into the history of TDD and unit tests, explain different git commands, or even go into version control at all. I want to be able to talk about this in a simpler way. I also want to talk to seasoned professional programmers, who know about version control and understand git far more than I ever will, without getting into the details of any particular VCS. Version Control Systems solve a problem that may not exist in the same way if we use TCR and that’s what I want to explore.

Play, Keep or Scrap is my friendly name for the idea. You can develop in a playful way knowing that you will only keep the working code as anything that doesn’t work is automatically and immediately scrapped. I hope Kent Beck will allow me the indulgence of using my own name whilst I experiment with this. I’ve always found his books and ideas inspiring and was amazed when he replied to an email I sent in the 90s and happy that he also replied to my tweet just this week.

I’m planning to share my experience in experimenting with Play, Keep or Scrap and the creation of the tools needed to make it a viable software development methodology in the context of making shipping Swift apps and teaching app development to beginners.