Archive for the ‘TDD Coding’ Category

How do you tell a master craftsman?

January 17, 2011

I asked my 12-year old son today what it means to be a craftsman and a master craftsman (of any profession). Then we went on to discuss how you can tell that someone is a master craftsman. I find his answer illuminating:

  1. They should be able to talk their craft and, if you’re not a master yourself, they will lose you and go over your head and talk about things you don’t understand. This was from a child’s view, but I interpret it as “They must be able to talk up their craft”.
  2. They should be able to create a sample on demand. He was thinking about small crafts when he mentioned it, but when we talked about bigger things (like skyscrapers), we decided a small test problem would suffice.
  3. (and this I think is the most important one) They should show you their previous work. They should be able to say, “Look, I created these high quality things in the past, so I can create high quality things for you in the future.”

The book Software Craftsmanship book mentions that to be a master, you must have a masterpiece. To claim that you’re a master, you must be able to show some really good work. So in our discussion of how do you tell a master craftsman, the answer is simple: look at their work.

When you hire an artist (painter, photographer, sculptor, etc.), you look at their portfolio. All artists have one, and it’s how they get work. So, if we’re craftsman, we should have portfolios. Résumés are similar to portfolios, but a) they don’t emphasize actual completed works enough, and b) they’re dry and boring. So maybe we need to start making multimedia portfolios to highlight our abilities as a craftsman. I picture web sites with screen shots, customer testimonials, sample code, links to your blog and other sites, and links to free software or other non-work projects you’ve created.

The key here is, if you want to convince someone that you’re a master craftsman, show them your work and your masterpieces.

Ron “Ziroby” Romero
http://www.ziroby.com (which has some portfolio elements, but needs to talk about my actual for-pay work)

[cross-posted to the Software Craftmanship list at http://groups.google.com/group/software_craftsmanship/browse_thread/thread/a9a03d96ff298a26 ]

What comes next after TDD katas?

August 16, 2010

What comes next after TDD katas?  UI Testing?  Mocks?  Design Patterns?

I’ve been doing TDD katas and dojos for a while now, and I think I’ve learned the first lesson.  I know the cadence of “break it, fix it, refactor”.  I understand Baby Steps and The Simplest Thing That Could Possible Work.  I get the importance of test choice in guiding the evolution of design.

So what’s my next lesson?  What’s the next thing the katas and dojos can teach me?  Maybe I need to figure out how to test UIs, and how to make testable UIs. The Humble Dialog Box may provide insight and direction there.  A coworker suggested that I need to learn mocks, maybe JMock or RhinoMocks.  I think there’s a kata in there somewhere.  I’ve tried the Publish/Subscribe example from JMock, but that feels too simple, a Hello World of JMock.  What’s a more complex kata that needs mocks to solve?  Or maybe I need to find a way to incorporate Design Patterns into my solutions.  So far I’ve evolved very simple designs, so they haven’t needed Design Patterns.

So what’s the next lesson to learn from code katas?  I know there’s a lesson in there somewhere, and I feel like I’m on the verge of learning it.  What is that lesson?

Quick Code Kata Restrospective

May 31, 2010

I’ve been doing Coding Katas three to five days a week for the last several weeks. I mentioned this to a friend, and he asked to join me. We did the reversi Kara, and learned some good stuff.  We learned to start with empty test cases and progress slowly from there.  We discovered we had to trust ourselves to pick which test cases to write, rather than doing complete comprehensive tests.  Finally, we wrote down lessons learned, which let us contemplate the process later.

(more…)

TDD FizzBuzz on the Android

May 23, 2010

I’m starting Android development, but I want to work in a Test Driven development (TDD) way. I’ve looked at the Notepad Tutorial, but each step is too big, and it’s not at all TDD. This blog post describes the first step I took.
(more…)

Dojo in a Community Ed Class

May 20, 2010

I’m interested in having a regular Coding Dojo that I attend, and I think setting up a community ed “class” would be a great way to organize it.

(more…)

Cyborg Chess Kata

May 18, 2010

This Kata creates a tool used for Cyborg Chess that displays the number of pieces attacking each square.

Background

Cyborg chess is a special kind of league where each “player” is actually a human-computer team. Gary Kasparov is a proponent of Cyborg chess, saying it will lead to higher quality play and “blunder free” games. Most Cyborg chess today is played by a human sitting in front of a chess engine. The human gets proposals from the engine and types in potential moves to be evaluated. But I think there’s more potential. The computer can present information to the human in interesting ways which help the human better visualize the position of the board.
(more…)

The Term “Unit Test”

April 30, 2010

The phrase “unit test” means so many different things to different people, that we need some new terminology to describe the tests involved in test driven development (TDD).

I gave a presentation on unit testing, and there was some pushback on the “unit tests must run fast” rule. Michael Feathers says, “Unit tests run fast.  If they don’t run fast, they aren’t unit tests.” (p. 14) Someone said that they wrote a unit test that tested all possible input (all numbers in range), and that took a couple if seconds to run, but they wanted to fully test it. It tests the unit, so isn’t it a unit test?
(more…)

TDD Hello World

April 18, 2010

The first program you’re s’posed to write in any new language is Hello World. If you’re doing Test Driven Development (TDD), what does Hello World look like?

The actual printing of the hello world text is the UI, and it’s hard to write unit tests for UIs.  So we create a thin veneer of a UI, and put all logic into an engine layer.  The engine layer is all unit-testable, and we design that Test First.  then when we have the engine done, we slap a quick UI on it and our program’s done.
(more…)