Constant improvement does not require judgmental reflection

June 9, 2009 at 6:49 pm (Scala, Week 12) (, , , , )

I spent much of the morning wrapping tests around the state machine code I’d written last week and over the weekend. Obviously, this isn’t the ideal way to write tests. I want to be a programmer who does TDD all the time, but I wasn’t that programmer on parts of this project. In the sections of the application where I’d done similar things before (the board and the players, for instance), I had no problem incrementally describing the functionality in specs and implementing it. But as I wrote my first state machine code and experimented with a new interface to Swing, I found myself implementing more and testing less.

As I gain experience and learn from colleagues through pair programming, I imagine that my discipline and abilities with regard to TDD will continue to improve as they have in the past few months. In the time being, I’m proud of the amount of code I’ve been able to delete as I write tests and discover the functionality that is really necessary. There is plenty left to do, but my Scala code is much simpler and easier to modify than the Java version of Tic-Tac-Toe, even though the language is still pretty unfamiliar, and the documentation sparser than Java’s.

I was complaining to Doug late this afternoon about the variations in GUI frameworks that make it difficult to get started in a new one, and I realized that what I really want is to know Swing and Limelight as well as I know XHTML/CSS. Again, I think this is a case of frustration based on lack of experience: once I have years of day-to-day Swing experience under my belt, that will feel great, too. I’m slowly learning to reflect on my coding in a less judgmental way. Bruce Eckel’s recent blog post, “A Career in Computing”, advises “There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.” This gels with my experience in music, where I find it very easy to beat myself up mentally for mistakes that I’m not yet skilled enough to avoid. My goal here is not to feel good about bad code, it’s to learn from my mistakes and engrain a healthy state of mind when coding. If I’m frustrated when coding, I’m teaching myself (unconsiously, of course) that it’s the correct way to feel when coding, and inevitably I’m going to make less progress.

Permalink Leave a Comment

Back and ready for action: reading and writing

May 4, 2009 at 9:40 pm (Limelight, Reading, Week 7) (, , , , , , , )

Well, I’ve played my last trumpet gig on the books for the time being. Took a trip down to South Carolina over the weekend to play a wedding ceremony and visit my mom. It was a good trip, and I actually got a decent amount of work done, believe it or not. The Limelight GUI that talks to my Java Tic-Tac-Toe code is finally in a completed state! I showed it to Micah this morning, and he didn’t have much to say at first besides that it worked pretty smoothly (he also noticed that I’d put in artificial sleeps to make the Computer vs. Computer game look more interesting). We spent a bit of time looking at some problems I was having with a refactoring in a Props file, but didn’t make much headway.

Most of the other work I did over the long weekend was reading – I’m really enjoying Michael Feathers’ Working Effectively with Legacy Code. I’ve noticed that most TDD resources I’ve read so far have dealt with simple, granular situations, where the design is perfect. But when I go to write tests for my code, I find that things are much more complicated. This tells me that at least one of two things are happening:

  1. Most textbook examples are simpler than real life situations
  2. My design isn’t clean enough

My estimation is that both are the case, but at any rate, I’m getting more and more motivated to write tests, even when it seems like it might be difficult. Particularly, the ideas of “sensing” and “separating” are helping me to crystallize what exactly I’m trying to accomplish when I write tests. The idea is that if I have an implementation method that needs to set a variable, I need to write a test that somehow senses the change in that variable based on the use of that method. It’s a simple idea, but there are a lot of ways that legacy code can make this difficult.

My next assignment was to pretend I was a writer (gasp!) and write a review of Limelight, as though it was for a magazine or something. I found myself drifting into tutorial mode for a paragraph or two, but eventually made my way toward an opinion on the framework. Basically, I think it’s great. There are a few strange behaviors here and there, and some features I’d like to see added, but it’s pretty cool to have a desktop application framework where you only need to write Ruby. Now, I must be completely forthcoming and admit that I’ve never tried any other Ruby GUI frameworks like Shoes, RubyCocoa, or wxRuby. In taking a cursory glance at Shoes (by everyone’s favorite Ruby mad scientist, _why), it looks interesting and feature-packed, but I’d like to see bigger examples, with the same separation of concerns that Limelight boasts. I’d also be surprised if interfacing with Java code was easy, or even possible, since Shoes doesn’t use the JVM.

Whew, I think I’ve written about all the prose I can write in a day; think I’ll spend the rest of the evening working some more SICP exercises. I watched another lecture over the weekend and finally started to look at the book and its exercises. It’s definitely forcing me to think in a very different way than I’m used to – I think this is exactly what Dave Thomas and Andy Hunt had in mind in The Pragmatic Programmer with their suggestion to learn a new language every year. At this point, I’m trying to learn several this half of the year, but since I’d at least written some cursory Java and Javascript code, I think I’m OK for now. I do worry sometimes about stretching myself too thin and becoming a jack of all trades, master of none, but as long as I can keep improving on all the fronts I’m aware of, I think I’m in good shape.

Permalink 1 Comment

Week 2, Monday

March 30, 2009 at 6:57 pm (Java, Week 2) (, , , , , , )

I feel like I’m getting close to completing the Tic-Tac-Toe game in Java. The functionality is there for Swing GUI and console modes, but I have a lot more to learn about GUI testing (simulating mousePressed and actionPerformed events) and testing threads (turns out I need to USE threads to test threads – duh).

But I’m feeling much more comfortable in Java. At Micah’s suggestion today, I took a lot of GUI-specific code (JLabel, JButton, etc.) out of my controller class and moved it into the view. This made a lot of sense since the implementation of the view should be easily swappable, without the controller worrying about it. I also refactored my old ConsoleDisplay class out to be more in line with my GUI code, so that both the console code and GUI code are just views, using the SAME controller/presenter. This was kind of a pain in that I had to add threading in the console code so that the GUI controller worked for it as well, but the big win here is that I can swap out views super-easily. It probably would have taken me another whole weekend without Micah’s help today, though.

We had an internal stand-up meeting, where everybody briefly talked about their current projects, side projects, learning experiences, blogs, kata, etc. It was short and to the point, but I think it’s a great idea for a team’s camaraderie – especially since two of the team members work at a client site. Paul just came out with a great blog post titled Material Consciousness in Software that’s well worth your time, and both Erics have blog posts in the works. Stay tuned!

Speaking of the culture here at 8th Light, I noticed very early on that everyone, without exception, shakes hands with everyone else as they arrive at work, and as they leave. It seemed very formal and quirky at first, but it’s really growing on me. So often, people show up to work with their team and barely grunt a “Morning” before diving into code. I definitely was guilty of that at my old job, and it seems like this is a good way to reinforce the team’s communication. Now that I write this down, it sounds like marketing mumbo-jumbo, but it’s a fact. I don’t know whether this is something that’s grown organically here or if the guys formulated the idea before its execution (or somewhere in between), but shaking hands feels like it solidifies a relationship each time, and at the same time heightens the importance of what you’re about to do (or have just done): software craftsmanship.

Permalink Leave a Comment

Week 1, Friday

March 27, 2009 at 5:28 pm (Java, Week 1) (, , , , , )

I spent some time last night experimenting with Swing and was able to get the Tic-Tac-Toe grid set up, with some listeners on the squares. Then this morning I wired up the GUI to my existing Java Code. I only had to make one major change, which was getting rid of the Dependency Inversion Principle violation I had in my display code. I just turned that into an abstract class and moved the existing, console-based code into a subclass, and then also derived a GUI display class from the abstract class.

That part was simple, but I really did a lot of monkey-hacking today to get the GUI working properly together with the existing game code. I think part of the problem was that I never really stopped the “spiking” I did last night to learn how to use Swing a little bit. I just kept right on trucking (in implementation code, without tests) until I had a working game. So I need to go back and retrofit some tests to most of the code I’ve written today, which I’m sure will mean rewriting some things. My mom got me Michael Feathers’ Working Effectively With Legacy Code for my birthday, so I may dig into that some to give me some ideas. My understanding is that the book describes legacy code as any code not under test, so I wrote a bunch of legacy code today [frown].

On a brighter note, I’m going to be working with one of the craftsmen on an internal project, most likely using Rails, so at least I’ll be familiar with the language for this one. I’m glad I’ll have a compelling reason to learn RSpec, and probably Cucumber and Selenium as well. These are the kinds of things that motivated me to want to work at 8th Light in the first place. As I told one of the craftsmen when I interviewed, it seems like all of the big names in the Ruby world use TDD/BDD, so I really was looking forward to writing code that way.

I took my first crack at estimating (our initial iteration meeting for the project was today), and only time will tell if I was being too optimistic or not. I certainly don’t think we’ll have too little to do, but as I said in a previous post, I think I’ll get better at estimating as I do it more often and measure actual velocity (stories completed per iteration) against estimates.

Since it’s the end of my first week here, I’ll just close with a general thought on TDD: it isn’t faster to write your first few lines of code in a new project. But if you have tests for those lines, then you know they work. The tests allow you to forget about them, and still be able to change other parts of the eventual system without fear of breaking old stuff. Because it’s got a test suite that you run and see that of the system’s requirements that you have encoded in tests, you’re passing. I’m looking forward to making this a habit and really having TDD become my default coding behavior.

Permalink 6 Comments