gentusmaximus / Dan

There are four people in gentusmaximus’s collective.

Huffduffed (392) activity chart

  1. Episode #2: Marriott

    What if it wasn’t enough just to launch a responsive redesign? What if you wanted everyone on your digital team to learn and embrace a new iterative prototyping process? Livia Labate of Marriott did just that for a large, global website.

    Read more »

    http://responsivewebdesign.com/podcast/marriott.html

    —Huffduffed by gentusmaximus

  2. Episode #1: The Boston Globe

    As the first major site to go responsive, it’s only fitting that The Boston Globe is the first episode of our podcast. We talk with Miranda Mulligan about the politics between the newsroom and the design team, and how responsive design brought them together.

    Read more »

    http://responsivewebdesign.com/podcast/boston-globe.html

    —Huffduffed by gentusmaximus

  3. Nerdist Podcast: Adam Buxton « Nerdist

    British actor/comedian/radio host Adam Buxton sits down with Chris and Jonah to talk about cleaning the airplane bathroom on his flight to L.A., horror stories of doing shows in venues that aren’t properly prepared, what is was like making a music video with Radiohead, and his own love of podcasts!

    Photo Credit: Ben Meadows

    http://www.nerdist.com/pepisode/nerdist-podcast-adam-buxton/

    —Huffduffed by gentusmaximus

  4. Signal vs. Noise podcast: Hiring

    A discussion about hiring and applying for jobs. What’s the best way to find candidates? What makes for a good "help wanted" post/ad? What’s the key to a good cover letter? What happens in an interview with 37signals?

    —Huffduffed by gentusmaximus

  5. Episode 64 | Hiring and Managing Remote Developers | Startups For the Rest of Us

    http://www.startupsfortherestofus.com/episodes/episode-64-hiring-and-managing-remote-developers

    —Huffduffed by gentusmaximus

  6. Is TDD Dead part 2: Test-induced design damage

    David feels that using TDD leads to approaches such as hexagonal rails that is test-induced design damage due to the complexity of excessive indirection. Kent thinks it’s less about TDD and more about the quality of design decisions.

    —Huffduffed by gentusmaximus

  7. Is TDD Dead part 3: Feedback and QA

    We discuss the various ways in which we get feedback while programming and the role of QA in providing feedback to developers.

    —Huffduffed by gentusmaximus

  8. Is TDD Dead part 4: Costs of Testing

    We discuss some downsides of testing and TDD: can you do too much testing, and is there a problem with teams valuing tests more than they value the functional code?

    —Huffduffed by gentusmaximus

  9. Is TDD Dead part 5: Answering Questions

    We answer a couple of questions from our viewers and wrap up our thoughts on this topic.

    —Huffduffed by gentusmaximus

  10. Is TDD Dead? Part 1: TDD and Confidence

    A series of conversations between Kent Beck, David Heinemeier Hansson, and Martin Fowler on the topic of Test-Driven Development (TDD) and its impact upon software design.

    David opened the discussion by raising his three major issues with TDD and Unit Testing: confusion over the definition of TDD and unit testing, test-induced damage through using mocks to drive architecture, and how the red/green/refactor cycle of TDD never worked for him. I commented that to understand where TDD etc came from its useful to understand the history, so Kent explained the origins of TDD by trying things out in Smalltalk, finding that TDD worked well for his personality.

    I commented that when we first worked together at C3, we didn’t start using TDD, but ensuring each programming episode delivered code and tests together. Kent said that programmers deserve to feel confident that their code works, TDD is one (not the only) way to reach that. David feels Ruby’s design goal of programmer happiness, and is on board with the notion that you’re not done till you have tests - but doesn’t like TDD as a way to get there. He thinks people have different brains and thus like different techniques and languages, he doesn’t like that TDD gets conflated with the confidence you get from self-testing code.

    Kent talked about a recent hackathon at Facebook, about half of which he could use TDD and half wasn’t suitable. In the TDDable code he found he was an enjoyable flow, but found the other part more tricky but still used regression tests and short feedback loops. He has no problem mixing both styles, it’s like playing both classical and jazz, TDD reminds him of how he learned mathematics at school - always needing examples.

    David has been in situations where TDD flowed well, but most of his work isn’t like that, his question is what are you willing to sacrifice to get that flow? Many people make bad trade-offs, especially with heavy mocking. Kent thinks it’s about trade-offs, is it worth making intermediate results testable? He uses the example of a compiler where an intermediate parse-tree makes a good test point, and is also a better design. But in response to David’s question about mocks, he says he rarely uses them, he’s concerned that those that do often find refactoring difficult, while he finds testing makes refactoring easier.

    I comment that there are two problems with terminology where different things get conflated: first that DHH’s critique of TDD was based on an assumption that you had to use heavy mocking in TDD, which isn’t the case; second that there is a difference between self-testing code and TDD. TDD is one way to achieve self-testing code. David said his reaction was to seeing people describe TDD in a mock-heavy as a moral thing to do and the result was a lot of code that was poorly designed due to its desire to enable isolated unit tests.

    I finished by playing time-cop and saying that in the next session we’ll explore how TDD may lead to damage, if that is really damage, and how we can judge if it’s damage.

    —Huffduffed by gentusmaximus

Page 1 of 40Older