Some good points were made and burning fast can make sense on throwaway code. We at Unboxed Consulting have worked on a codebase for a client that was written by New Bamboo and have experienced first hand that code produced like that is still likely to end up in a production code. I think it is important for us as Ruby professionals to refuse to take shortcuts for all production code because it will hurt the good name of Ruby in the long run.

@tomtt

This talk was reasonably well thought out with Gwyn and Bartosz playing a double-act, with Bartosz playing the 'straight' man and Gywn being the maverick wanting us to all write bad code. It served to illustrate that sometimes you just need to write bad code, do things wrongly - but only for prototyping of applications or where you need instant feedback. It was heavily underlined that all of your 'speed-run' code should be binned and re-written properly before it hits production. This talk was one of many highlights of the conference for me, well done guys. @ryanstenhouse

That was a well done talk, and it really underlined the need of hackish solutions in the first place. It reminded me a lot of the proof of concept I made for my company, and during the talk I rediscovered some nice things.

But I have to say, that the talk was 'only' worth hearing, because the content itself is nothing innovative. Writing hackish/throwaway code for a proof of concept is a common practice in pragmatic programming. @Overbryd