DaedTech

Stories about Software

Oct
4

By

Chess TDD 49: Castling is Hard

Category: You Asked For It Tags: , , , , | 4 Comments

In this episode, I start to discover that castling is hard.  There’s unusual movement, the fact that 2 pieces move simultaneously, and the fact that you have to keep track of a lot of status.  People have even commented on this being a particularly hard facet of the game.  Oh well, c’est la vie.  I think I came up with an idea for a helpful strategy during the course of this episode, even though this episode itself wasn’t wholly productive.

One thing to note if you’ve been following this series is that I’ve switched to Visual Studio 2015.  I brough CodeRush, NDepend, and NCrunch along for the ride, not to mention some of my preferred VS plugins.

What I accomplish in this clip:

  • Fixed castling implementation to the long side of the board.
  • Got a little more organized in Trello.
  • Started on implementation of not allowing castling when pieces have moved.

Here are some lessons to take away:

  • When you need to correct a mistake or bug, make sure you start with a red test that exposes the mistake.
  • It’s okay to have a situation where making a test you’ve altered green makes others red.  If those tests are now wrong or out of date, this gives you basically a checklist of the tests you need to fix.
  • If you consider yourself advanced enough to skip a step, it’s still always possible that you’re making a mistake.  TDD is all about micro-hypotheses and verification of your understanding of the code.  If you find yourself being wrong, slow down and get back to basics.
  • No matter how long you’ve been at this, you’ll still make mistakes, especially if you get a little fast and loose.
  • If you write a test to confirm your understanding of behavior in a certain context, I recommend leaving it in.  If you were wondering about that behavior, chances are someone else will, later, as well.

Sep
29

By

Chess TDD 48: Getting Started with Castling

Category: You Asked For It Tags: , , , , |

Back in the saddle and making these regularly once again.  In this episode, I start implementing castling.  This proves to be something of a challenge because I’d gotten into such a routine of adding acceptance tests for the Pawn feature and changing mainly the Board class.  Here I’m in a different set of acceptance tests and changing a different set of production code, so it took a bit to get my bearings.  Castling, like en passant, is also a non-trivial edge case that deviates a fair bit from standard piece movement.

What I accomplish in this clip:

  • Implemented castling to the short side of the board.
  • Implemented castling to the far side of the board (though I think I got the move wrong).

Here are some lessons to take away:

  • It’s a big help if you keep a nice, large surface area of testable code in your code base.  This lets you dig in with the granularity of your choosing for writing tests.
  • You need to carve out time to keep your code clean and do boy scout refactorings.  If anyone is telling you not to do this, that’s a serious organization/group smell.  You need to keep the code reasonably clean to sustain the pace at which you deliver value.
  • As you have a larger and increasingly complex code base, “do the simplest thing that will work” becomes an increasingly tall order.  With more tests that can go red, it gets harder and harder to do trivial things that satisfy all tests.
  • It’s important to audit your tests continually to make sure they continue to add value.

Sep
25

By

Chess TDD 47: En Passant in the Other Direction

Category: You Asked For It Tags: , , , , |

It’s been a while since the last episode, due mainly to my wedding and honeymoon, but here I am, back in action.  For some, there were a few audio glitches in the recording of this episode.  I did just upgrade to Windows 10, so maybe my version of Camtasia isn’t playing nicely with or something.  My apologies, but I think it’s just minorly annoying and not a problem for understanding.  This episode is pretty straightforward.  I performed a little bit of cleanup on naming and then finished up by implementing en passant in the other direction.

What I accomplish in this clip:

  • Fixed some naming hangover from last episode.
  • Got en passant working in the other direction: white pieces capturing black pieces.

Here are some lessons to take away:

  • I’ve said it more times than I can count, but naming is so important.  Spend extra time with it.  Revisit it.  Make your methods as readable as progress.
  • When you’re test driving (or, at least, making sure to write a lot of automated tests), the kinds of refactorings that a lot of people promise to do ‘later’ and never do turn out to be a lot easier.  You’re much more likely to deliver on promises to clean up later.
  • If you have logic that you want to test and it’s 2, 3 or more calls deep in private methods, this is often a sign that you should extract a class and have two different public surface areas to test.
  • If you can delete a line of code in your code base and no test goes red, you’ve failed at some point in your test driving.  Either you’ve deleted a test that should exist or else you’ve added functionality to prod without having a failing test that requires that addition.  It happens to the best of us, but understand that it’s a problem and either delete that code or add a test that makes it necessary.

Sep
2

By

Surviving Software Heroes

Category: You Asked For It Tags: , , | 7 Comments

There’s an entertainer named Garrison Keillor who talks about the fictional town of Lake Wobegon.  At the end of live monologues on this subject, he ‘signs off’ with the following summation.

Well, that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average.

Heroes of Software

Most of our life is spent in search of a place where all of the children are above average — a place where we can all grow up to be heroes.  Society idolizes its ready-made heroes: royalty, athletes, celebrities, and even, to some lesser extent, great thinkers, executives, and artists.  There are also situational, role-based heroes, such as first responders or even people who perform some bit of heroism in a pinch, such as pulling a potential drowning victim from an icy lake.  The key here is specialness.  Heroes are special.

For the rest of us ordinary mortals that don’t knock in World Series clinching home runs or play home run hitters in movies, we’re left to manufacture our own specialness narratives.  Smartest lady in the room?  The guy with the legendary collection of beer steins from each year’s Oktoberfest?  Sometimes you have to dig pretty deep to find a venue in which you’re significantly above average.  It is to this need that I attribute hardcore conspiracy theorists and people who fret endlessly about organic food, holistic medicine and ‘ancient’ treatments — being in possession of some kind of uncommon knowledge that the ‘sheeple’ lack is a path to specialness, if not heroism, per se.

We have heroes in the software world.  They’re the ones with encyclopedic knowledge of the domain and the existing code base.  They’re the ones who are known for being reliable when the chips are down — getting in early, staying late, and coming through in the clutch with a put-upon, but satisfied expression.  They make project managers swoon and gush during their academy award speeches.  They come in late sometimes and leave early other times, when there isn’t delivery pressure, because they’re trusted with the special privileges that fall to A players on teams.  But they do it knowing that, at any moment, they might need to swoop in and take over entirely while the rest of the team twiddles their thumbs and gets out of the way.

SuperDev

And you know what?  They love it.  Because in the narrow scope defined by their cube farm, they are heroes.  They are Michael friggin’ Jordan.  They’ve found their specialness in life. Read More

Aug
30

By

Chess TDD 46: En Passant Expiration Date

Category: You Asked For It Tags: , , , , | 4 Comments

This installment of Chess TDD was another episode focused on en passant.  It’s been a while since I was in this code base.  I’d been on the road a lot and without my main development/recording rig.  But now I’m back and was able to take the opportunity to record a little Chess TDD ahead of my wedding next week.  This episode went pretty smoothly.  I cleaned up a method from last time that had become unwieldy and then got the next acceptance test to pass without any flailing.  Not bad for so much time between episodes!

What I accomplish in this clip:

  • Refactored the Board.MovePiece method away from mounting ickiness.
  • Implemented functionality to prevent en passant from lasting beyond one turn.

Here are some lessons to take away:

  • When extracting methods during a refactor, if you have a hard time giving the new method a coherent name, it might be a sign that you’ve selected non-cohesive functionality to extract.
  • Spend a few extra brain cycles contemplating the names that you give things.  This investment will pay off because it’s easier to give things good names when their functionality is fresh in your mind.
  • If you start to have code that no longer seems to belong in a class, make sure you’re keeping that visible to yourself as you go so that you can have a nice cue for refactoring.
  • Take care to keep communication between methods and classes at an appropriate level of abstraction.  Make sure they’re communicating in obvious domain concepts.

« Older Posts
Newer Posts »