[python-uk] Game of Life / TDD ideas

[Nicholas H.Tollervey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey David,

On 07/02/12 11:36, David Read wrote:
> Those of us at last week's London Python Dojo had fun hacking
> together

A shame I missed it :-(

> little animated Game of Life simulators. My team's data model was
> based on a set of the alive cells, rather than the world as an
> array / list of lists, and its a choice I pushed for having
> recently read an extremely relevant blog post:
> http://emilybache.blogspot.com/2011/12/global-day-of-code-retreat.html
> I mentioned it to some of the people in the pub afterwards and
> wondered if the rest of you would be interested.
> 
> Emily r 
> <http://emilybache.blogspot.com/2011/12/global-day-of-code-retreat.html>uns
>
> 
Python Dojos in Gothenburg and provides "clean code" training for
> companies, so practises doing problems like Game of Life time
> after time. She aims for clarity / pythonic-ness and practising
> different coding methods to get high quality.
> 
> I was particularly interested to watch her screen cast
> https://s3.amazonaws.com/ryanbigg_screencasts/Game+of+Life+-+Full.mov
> where she goes through her practised version of Game of Life
> whilst demonstrating several of the latest ideas in the TDD world.
> It's quite different to most people's ways of thinking / coding,
> and perhaps won't be to everyone's tastes, but it's definitely food
> for thought!
> 

It's definitely an interesting read. I especially liked the Norvig quote:

"you can test all you want and if you don’t know how to approach the
problem, you’re not going to get a solution"

Which chimes with Rich Hickey's (creator of Clojure) "Hammock Driven
Development" (see:
http://blip.tv/clojure/hammock-driven-development-4475586 - definitely
worth a watch all the way through). I.e without thought, wisdom,
exploration or time to reflect on a problem it doesn't matter what *DD
you're practising you're not going to get good results. He also warns
against what he terms "guard-rail" development in
http://www.infoq.com/presentations/Simple-Made-Easy (around the
14-18min mark) and again emphasises simplicity and understanding
trumps methodology.

Given the high-energy coding that happens at the dojo I'm currently
trying to think of a way to preserve the enthusiasm whilst allowing
participants a chance to reflect on the problem without jumping in to
create an unholy mess of spaghetti code. As you may know, I feel very
uncomfortable promoting "one true way" to do development since I think
it's essential that people discover what works best for them after
reflection and exploration of lots of different solutions rather than
forming habits due to a "that's just how it should be done" mentality.

In any case I was going to suggest a 15minute design-time followed by
a "stand up and explain" session of each group having 1 minute to
explain what they're going to code (erm, sort of lightning-lightning
talks). Of course groups could copy / learn from other's designs.
Let's see what happens next time. :-)

Thanks Dave for leading me to the blog post. Definitely food for thought!

N.

> Dave
> 
> 
> _______________________________________________ python-uk mailing
> list python-uk at python.org 
> http://mail.python.org/mailman/listinfo/python-uk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPMSoDAAoJEP0qBPaYQbb6yHYIAJkpEBw8bmomohRllMTgZMpN
TI4IOeccXW6mi3eAclKNTl95mNa0MEpGD0P0ct/I5xGpsuNHaot9nuGIshqMqGwr
/PkDqSFCBZF33aOeECBb9cEjAzef+Bg+LQJBMrqM5X2rLmRcUonfmE8uORnG0Fsu
f6hHlVCTPdukbHNZbuhNPg/xh1gAbG3q4gsZ1fJdzjRawvnGZcX/t/IqC8a6dT6F
mlK7pI6WYtRu+Hd1W92lRuoV4Nq80dq1c2jKMXTUHqWVbO+ZxYDXX39Y46UruJq/
1+kXjjYhichH8F13APScdeaUCiWArDhziORK4bCf5OlcfWb726Ku5Ja1n3Qi1Ls=
=6fp4
-----END PGP SIGNATURE-----