Prototyping, tracers and the art of throwing things away

I’m a fan of prototyping. Not all the time but I strongly believe that it has a place within the toolkit.

If I am unsure of how something might be put together then I might put together a quick version to test out a current approach. If I am working with a team who know what the outcome needs to be but are unsure of the way it needs to be done, then writing something that echoes what has been discussed is often a great way of focusing meaning and decisions. Sometimes I find it useful to force decisions when there is endless procrastination or that I see ideas that are not fully formed.

So I find it useful for focus, getting decisions made or just helping to identify parts where a more refinement is required.

A prototype is to be thrown away though.

It demonstrates and cajoles but it should not last into the fully fledged version of the software. Jeff Atwood on Coding Horror calls it “The Prototype Pitfall” and lists Tim Weaver’s 5 laws of prototypes. Sadly, I know that number 4 is true: once a prototype is deployed, you will never get around to fixing or improving it unless a bug is filed. (Even then, it may not be fixed.) Prototyping standards are not production standards.

The purpose is to write a minimal version of what is being achieved to help everyone understand the complexity or the missing requirements. It aids the conversation and provides valuable learning points but is then thrown away.

From that code, the teams should understand the domain in deeper depth and learn from it, rather than repeating the same errors. I think that it can also support Domain Driven Design by forcing the points of non- or misunderstanding into the open.

Using the Pragmatic Programmers’ words, Atwood discusses the Tracer Bullet approach. Rather like a prototype, the basic system is mocked up. Instead of being something that is thrown away, the tracer provides a minimal implementation of the system that can be iterated over and developed into the fully fledged system. If an algorithm is required, put in the basic version: it can be optimised and improved later. If a remote call is required, provide a stub.

Towards the end of the article, a useful point is made about how to make the prototype more disposable whilst being useful:

I think it might help to develop prototypes in a totally different language or environment. That’d reduce the temptation to code around the prototype

For instance Python could be used where the final code would be C++. A simple UI could be put together using static HTML5 and some JavaScript though this might turn into a Tracer Bullet event (Dan North describes a colleague doing this in his “The Browser is Dead” talk at GoTo 2012). A choice needs to be made about intent and only the developer or development team can do that.

In a recent project, I used the Tracer Bullet approach to create a framework using Flask and relatively simple JavaScript with some mock interfaces behind it where required. Using this, I was able to have a meaningful conversation with the other team members leading to a better understanding of the deficiencies of the data, assumptions made in the specifications given, and defects in the specifications given, such as little real thought about how the user would interact with large amounts and varied types of data.

As part of the refactoring of the code, the underlying code is becoming aligned with the various project principles and architectures. The initial version of the code did not need this but the final versions will use them. Colleagues have already commented that they want to have places to extend the code base so it has been updated to reflect this and allow requirements without writing large amounts of code to support it. To some degree, this follows the open to extension, close to change principle.

So I still love prototyping as a tool but it will only be useful if the caveats and restrictions are applied to it: throw it away. If it is going to be used, then use Tracer Bullets.

 


Some Thoughts on Digitizing the Stage

I attended the Digitizing the Stage conference, jointly between the Bodleian libraries and Folger Shakespeare library. A basic storify exists here for the various tweets. A mix of performance, textual, makers, and doers, this was a chance to consider the needs of archives, scholars and the data for ongoing scholarship. I noticed a disenchantment with […]


Jane Austen’s word choices

A Facebook friend had a link to an NY Times piece on Jane Austen’s word choices. Using Franco Moretti’s techniques, it begins showing how Digital Humanities can be useful. There are one of two of his books that I am waiting for before I can get into the pros and cons but I do have […]


Reflections on the Docker Containers for Reproducible Research workshop

I’ve just come back from an workshop run by the Software Sustainability Institute about Docker and reproducibility. Widely used in industry and academia, Docker, the containerisation technology, is perhaps one of many tools to support the running of software across different platforms in a sane way. Two or three years ago, there was a huge […]


Approaching physical user experience as a total novice

As part of a project that I am involved with, I am currently trying to design some hardware. It is mainly casing around the components but it is completely new experience for me. I have never tried building anything for a person with visual impairments before, let alone a user experience. It is certainly a […]


Background music in podcasts

Music can be an interesting topic for audio, such as podcasts and so on. It is something that I have a passing interest in for other purposes. Pitchfork magazine has an article on the issue reflecting on luminary podcasts such as This American Life, The Secrets of Successful Podcast Music.


Studying at the Sussex Humanities Lab

It is with an absolute joy that I’m going to the Sussex Humanities Laboratory at Sussex University to do a PhD in the autumn. I recently gained an MSc in Software Engineering at Oxford. I have been trying to do more in Digital Humanities and this was an opportunity that I could not miss really, […]


Sometimes the project is for turning

In a speech to the Conservative Party in 1980, Margaret Thatcher said that the “lady’s not for turning”. Projects are not always like this. Recently a decision was made to change direction completely. A project meeting was held and a demonstration of some technology shown that followed the agreed project path. In the following conversation, […]


Continuing on the path to better reproducible work

Last year I had the pleasure of helping Julia Stewart Lowndes at a Software Carpentry style workshop in Oxford. I got notice of her paper, Our path to better science in less time using open data science tools, [1] via various means and made time to read the other day. It describes the path taken […]


Looking into profiling Python

Periodically I get back to profiling code, or at least some of it. Profiling is an tricky art: I do not claim expertise but it is something that I come back to every so often. In a previous project I used strace to follow the ins and outs of a very long running process (about […]