8th Light - Home

Walk and Code

2010-02-25T14:24:00Z

The Motivation

A few years ago when we were buying furniture for the first 8th Light office I came across a piece called the WalkStation. It was an adjustable height desk with a treadmill underneath. I had just started to get myself into better physical shape, and thought this would be a unique way to change a sedentary job into an active one. The price tag turned out to be way to high ($4500+).

Fast forward to January 30th, 2010. At ORDCamp, Zach Kaplan, founder of Inventables, gave a presentation about Dr. James Levine and the research he's done creating active computer workstations. It turns out that Dr. Levine is the guy behind the WalkStation that I had seen earlier. Zach had thrown together a treadmill and a laptop desk to try out the concept and was raving about the benefits. It was the motivation that I needed to finally get to building my own treadmill desk.

Acquisition

Using Craigslist, I found a treadmill just blocks from my house. It is a ProForm 830QT. Sears sells this brand, and I think this one retailed for around $900. I paid my neighbor $140 for this one.

My next stop was Ikea. Somewhere in the back of my brain I remembered seeing a desk at Ikea that was adjustable on-the-fly. I went searching, but found nothing that could be adjusted without tools and without unloading the desk first. I had done a bit of a web search earlier for adjustable surfaces, but hadn't come across anything in a reasonable price range. I headed downstairs to the "as-is" section of Ikea and snatched a Gallant table, frame, and T-Leg combo for $60. The legs alone cost that much new. The combo had been a display model and we a little bit dinged up, but the price was right.

Construction

My first concept was to build a free standing table that would sit over the top the treadmill. The table I picked up was wide enough, but the Gallant legs maxed out at around 36" and I knew that wouldn't be enough. I began envisioning ways to make the legs longer.

In the meantime I started to take apart the treadmill. I just started unscrewing and unplugging everything I found until I was left with just the touch-panel unit and circuit board in my hand. There was one cable running through a leg of the treadmill that was pretty obviously the main control cable back down to the motor below. There was also an audio cable, a cable running to the hand-grip heart rate monitor, and an extra heart rate cable leading to nothing. After a look at the manual, I discovered that this cable can be connected to an optional sensor for heart rate chest straps. The whole idea of this setup is to walk slowly and keep the heart rate down, so I just yanked out all the heart rate cables and sensors.

With all of the electronics off of the treadmill, it was back to figuring out how to mount the desk. This treadmill has hand grips on either side. I yanked furiously on these for several minutes trying to pull them off to see what was underneath. After consulting the assembly manual, I saw there was nothing holding them on, so I got out a pry bar and went to town. They eventually gave way and revealed the horizontal supports that were to become the foundation of the table mount.

A 2x4 set across the hand grip post put the work surface at just about the right height, so I drilled a hole through the posts and bolted on the 2x4. The Gallant table frame has lots of mounting holes, so after removing the frame from the desktop, I chose two holes and bolted the frame on top of the 2x4.

Things were looking good, but for the two post that would prevent the table top from being installed. At first I thought that I could cut the uprights off. But my dremel cutting wheel and hack saw were no match for the thick posts. Without the right tools or know-how to deal with metal, I resigned myself to notching out the table top to fit around the posts. This operation was a measure twice, start over, measure twice again kind of affair. But with some care, I was able to cut the notches with a drill and a jigsaw. A quick tip here. When you cut through a laminated surface like most Ikea stuff, masking or packing tape on your cut line will prevent the laminate from chipping.

Amazingly, I had measured and cut the notches right and the table top slid in place and the old holes to the frame lined up nicely.

With the table top mounted, it was time to get control of the treadmill back. First the touch-panel and circuit boards needed to be contained. I didn't want to spend more money on a project box, so I started hacking away at the plastic enclosure that I had disassembled earlier. I was able to cut away everything but a box the just enclosed all the pieces and was even left with two screw holes for mounting. The problem was where to mount it. I wanted the controls accessible, but out of the way most of the time. They couldn't interfere with walking or typing.

I settled on a keyboard tray that would mount underneath the desktop. It could slide under most of the time, and then pull out easily to start and stop the treadmill or change the speed. Ikea has a tray for just under $10, so it was back to Ikea for the Summera Pull-out keyboard shelf. With the touch-panel mounted on the keyboard tray, there was just not quite enough slack in the control line to be able to pull the controls out far enough to see the entire display. I took the cover off on the base of the treadmill to investigate the control cable and see if I could create any slack. I was able to free up enough cable so that the tray could come out far enough, but it came at the cost of the treadmill's incline feature. The cable will bind now because of the re-routing when the incline it pushed up.

Results

So it's been about 3 weeks with the treadmill desk. Here are some of the question I've received: Q: Don't you get tired?
A: Sure, then I sit down for a while.

Q: Isn't it distracting to your work?
A: I'll admit it took a little while to get over the novelty of walking and coding. Once the meta-conversation in my head stopped ("Look at me, I'm on a treadmill, and I'm writing code!") then I think that low level physical activity has actually helped to keep me focused. Walking engages a completely different part of my brain. I compare it to how some people will pace when they are making a decision.

Q: What about pair-programming?
A: Colin and I have been experimenting with pairing on the treadmill. We've integrated it into our normal ping-pong rhythm. The one coding is the one walking. One green-red cycle, and then we switch. It's a little bit hard to stand and look over the walkers shoulder, so we've been using a second laptop sharing the screen of the first. With both laptops on the same network, the point-to-point screen sharing is pretty responsive. We've had the best luck with Skype. A second screen also allows the pair to sit for a while. I'm still imagining how two treadmills could come together for a fully-walking pair station.

Q: How fast do you walk?
A: 1 MPH for the most part. We've done okay at 1.3 - 1.5 too. I can stay pretty stable even up to 2.0, but I start to get overheated at that speed.

Q: What effect has it had on you?
A: My knee hurts a bit after being on all day. Colin and I have both noticed that we get hungry sooner when walking. I think that mean that our metabolisms are running faster. So I make sure to eat a good breakfast everyday, and we are really ready for lunch at noon now.

References:

Dr. James Levine talk about treadmill desks
The Mayo Clinic's Non-Exercise Activity Thermogenesis Lab
Jay Buster's Treadmill Desk
Treadmill Sensei - Good reviews and info and treadmills

Photos

From the Side:

The touch panel mounted beneath the work surface:

From the Front:

Underneath / Mounting detail:

Update 2/28/2010: Here is some video footage.

Stubbing :new Considered Harmful

2010-02-09T01:41:00Z

Hi my name is Eric, and I have made a mess.

There I said it. I’m not proud of it, but I believe a couple very loosely related things:

You only learn from your mistakes
Everybody makes mistakes, a craftsman cleans them up.

It is in the process of cleaning up the mess that I’ve been trying to evaluate the messy code in the first place. How is the code messy? Was it Test-Driven? It was - or at least it attempted to be (we’ll get back to that). Was I lazy? Certainly not. Am I stupid? Crap I hope not. So how did we end up in this mess?

What’s the mess nimrod?

Recently Justin, our latest apprentice, wrote about attending a code review here. The feature he is referring to is part of one of our best client’s systems, where we integrated with several webservices, making them look seamless in our application. This was an extremely difficult problem, and our code bent in a dozen painful ways for a solution, and has since become rigid. Changes have stopped being done in the nice Test-Code-Refactor mode, and instead are being done by trying a change, trying the product, then backing out the change and making the test pass. While we identified several ways to improve the code, such as better naming and adding a facade between some of our interfaces, one stated goal was to “make the tests readable.” See the problem isn’t that it’s not tested - it’s that you can’t follow the tests at all. Let’s look at an example, modified to protect the guilty:

  
  it "should call a webservice when its complete" do
    @caller.should_receive(:call_webservice)
    typedObj = mock("Obj", :no_follow_ups? => false, :null_object => true)
    ProprietaryObject.stub!(:create_typed_obj).and_return(typedObj)

    @page.stub!(:widget_id).and_return(@widget.id)
    @page.stub!(:previous_page_id).and_return(nil)
    @product.page_cache = [@page]

    @widget.follow_ups({}, {:application_id => "123", :group => "group"})
  end

This probably isn’t the worst example - if you look closely you can see that we’re testing that call_webservice needs to get called when ‘its complete.’ But what complete? I don’t see a stubbed object that returns complete. Also I have no idea what @page, @widget, @product or :createtypedobj are doing here. When I want to write the next test I have to guess at intent, and start playing with variables. What this is trying to test is that a webservice caller object receives call_webservice when the widget (an object on the screen) is called with certain variables. I’d tell you what those variables are, but I truly don’t know.

It doesn’t get better. Let’s look at where some of those variables are coming from. These are excerpts from a setup method that is too long.*

  
  Context.stub!(:find_by_widget_and_application_form).and_return(@context)
  Page.stub!(:new).and_return(@page)
  ...
  @caller = mock('caller', :call_webservice => nil)
  WebserviceCaller.stub!(:new).and_return(@caller) 
  ...
  @page_factory = mock_model(PageFactory, :acquire => @page)
  PageFactory.stub!(:new).and_return(@page_factory)

So by my count we’ve stubbed new three times, two finders, and an acquire all of which inject yet another dependency into the code. Thus the premise of the article stubbing new considered harmful.

Is it really harmful?

Dependencies in static languages are generally more onerous than what we’ve got here, sometimes extremely painful although usually it can be accomplished with simple setters and constructors. In Ruby this isn’t the case - you can just stub new and create the object the way the user intended, thereby continuing to test. This can be a VERY BAD THING because it’s a moment where you need to pause. Do you need this dependency? Should you be wrapping dependencies? Do you need a facade or wrapper object for a couple dependencies? The difficulty of DI in other languages enforces that pause, but Ruby does not. It lets you stub anything, only to one day wonder why you have such a mess on your hands.

It’s important to remember that Dependency Inversion existed before Unit Testing, and isn’t just a Unit Testing technique. Indeed we often sell TDD as a way to make you have better designs, and yet here it failed me because I can so simply call new and continue testing. This is a mistake. To paraphrase Jurassic Park, just because you can easily stub new doesn’t mean you should. Would you create a constructor that took five objects? Then why would you stub :new (or finders, or factory methods) five times. Would you pass in an object to the constructor that’s only used in one method? No - that’s not cohesive. By stubbing :new you can slowly, and easily, introduce dependency after dependency creating an indecipherable mess despite writing tests. Worse you can do this easily, without suffering the traditional pain of tightly coupled code. It’s only later that you’ll feel the awful, horrible, indescribable pain. Trust me it’s bad.

Am I really advocating stopping stubbing :new? No not really. It makes perfect since to just call :new when you can, and in many cases factories are a way to get around the limitations of a static language. What I am saying is that each time you do stub!(:new) THINK! You have a dependency to manage, so manage it. It’s your job you know.

*This is also a smell. Allow me to quote “The Art of Unit Testing”, an excellent book on Unit Testing by Roy Osherove

Don’t use [SetUp] and [TearDown] to initialize or destroy objects that aren’t shared throughout the test class in all the tests, because it makes the tests less understandable. Someone reading your code won’t know which tests use the logic inside the setup method and which don’t.

Zeroth rule of professionalism

2010-01-08T18:09:00Z

This is a response to an article “Software Testing Craft” by Markus Gärtner in inaugural issue of Agile Record.

As an apprentice, I remember thinking that solutions to software were either right or wrong. Later this was able to be simplified to either the solution works or doesn’t work. This became my base level understanding of a software solution.

Then came the time I thought solutions should be judged by how clean or efficient they were. This was my renaissance of aesthetics in the code. How to code your intentions expressively was the goal. This too became a new base level of understanding.

Now I am of the understanding that software solutions are a judged by factors of time. Making all the trade offs correctly so the code works and is readable, but also in the shortest amount of time possible. The key thing here is to take the long term view of time. Not how much time in a single sitting, but every time you come back to the same solution. How often do you come back? How hard is it to change?

From the article, Markus says, “As a software tester, you should take responsibility for the out- come of every decision you make. I call this the zeroth rule of professionalism.”

I think this is an elegant way of stating my understanding of software solutions. Every decision you make is a function of time and understanding. By taking responsibility for each of your decisions software becomes a series of trade offs that you have to live with and learn from. When a design works and is written well, it becomes easier to live with the outcomes of your decisions.

It is much like how I learned to play chess. At first I would make a move and try to understand the consequences in position and strength. Then I learned the common openings and endgames which helped me express my strategic creativity and play moves that had aesthetic value. Finally came the important skill. Being able to project moves forward and do a risk analysis of each possible move. This let me take the previous skills and put them together in a coherent fashion. I could understand how a move fatal to my king was a consequence of a move made much earlier in the game and learn from that decision. This skill is when I started playing chess as a game rather than a set of moves.

For me, it was only through the out-comes of my design decisions that I learn this lesson. It was very important for me to be in a position transparent to the positive and negative consequences of the code I write. Like the chess analogy, I need to project forward to attempt to understand the consequences of a decision before I make it.

A Software Craftsman's New Year's Resolutions

2009-12-30T22:27:00Z

There is so much to learn in this field, and the many new languages, frameworks, and APIs that are developed every day only add to our task. Sorry for the title-bait, but no self-respecting iterative-developing programmer would make resolutions for an entire year of learning. I expect to re-evaluate every few months, but making a long list of goals is a fun way to brainstorm paths to improvement.

Let me first take a moment to reflect on the past year. I've learned so much in 2009, beginning with my discovery of the Software Craftsmanship movement and its focus on apprenticeship. I leapt at the opportunity to come to 8th Light as an apprentice under Micah Martin, and was excited to come onboard long-term at the conclusion of my formal apprenticeship. It's important to remember that only a year ago, I wasn't doing TDD or Agile and hadn't really used any other technologies professionally beyond the Rails ecosystem. This year, I've done quite a bit of Java and JRuby, and I've studied Scheme through SICP, as well as some Clojure (mostly exercise-type practice) and Scala (just enough to write a Tic-Tac-Toe program). My progress speaks both to the time and effort I invested in learning (see Uncle Bob's tweet about professionalism) and to the tremendously positive peer pressure that surrounds me here in the Chicago area, the Software Craftsmanship community, and 8th Light specifically.

However, a software developer can't be caught looking backwards for very long. With that in mind, I present my goals for 2010.

1. Check email and Twitter less frequently.

Like many other developers (and musicians), I have a bit of an obsessive personality, so I end up interrupting my work and personal life to get my news fix much more often than necessary. Besides, it's going to be illegal to text, email, or tweet while driving in Illinois beginning January 1, so it's absolutely necessary (not that it was safe while driving before).

2. Take more breaks when coding alone.

When programming without a pair, I tend to stay very close to the code and neglect the big picture. With some open-source work over a recent vacation, I found myself coming to an impass nearly every evening, and invariably I'd have a simple solution the following morning. It's less necessary with a pair (like Doug Bradbury) who's able to step back and evaluate bigger-picture ideas, but our minds don't have infinite endurance, even with the labor split up.

3. Timebox spike code.

I'm improving my test-driven development habits, but there are so many unfamiliar areas to me as a programmer that I have a hard time telling whether I'm going in the correct direction until I'm there. I don't write tests for most spikes, so this means that I sometimes end up with a couple hundred lines of working code that I need to retrofit tests onto. Obviously, this ends up being more work than it should, and while I can refactor to make the code more easily testable (especially with automated refactoring tools), I'd prefer to have tests in the first place. And in the worst cases, I might miss some tests that need to be written and allow bugs that should have been caught. So my intention is to put a cap on the amount of time I spend on a spike before I backtrack and start writing tests. Something like 30 minutes seems reasonable. Besides, most of the spike code I write is alone, so I should be taking more breaks anyway.

4. Focus language study.

There's something to be said for the tremendous breadth in the languages I studied this year (Java, Ruby, Scheme, Clojure, Scala, and C), but I don't want to be a jack of all trades, master of none. It's time to get serious and get some real depth. Since my current project is mostly in Java and JRuby, it seems logical to get really in-depth with those two languages. My study at home would be reinforced by what I do daily at work, and vice versa. On the other hand, it also seems smart to go after an up-and-coming language and get ahead of the curve there. So I won't rule out more Clojure or Scala study, but it's my intention to pick one at most.

5. Focus open-source efforts.

I tend to leap around open-source projects a bit, looking into a few projects just enough to catch some low-hanging fruit from the bug or feature lists. I'd like to get more depth on a project or two, ideally in the same languages I'm planning to study more of: Java and Ruby. Limelight is the no-brainer choice, and I've already started a bit of work there. The best news is that I already know Micah, the creator/maintainer, and he's very willing to help me learn and contribute to the project. I highly recommend the project, as well as Nokogiri (the Java branch would be exciting to get working) and JRuby, for anyone with Java and Ruby skills looking for a project.

6. Really learn testing frameworks well.

It's not very often that I run into a testing problem that's limited by my lack of knowledge of the testing framework, but it sure is embarrassing when that does happen. The acceptance tests for my project are in Fitnesse, and the unit tests are in RSpec and JUnit. Following my current rationale, I should get really good at those. I have the longest to go in Fitnesse, where I still feel like a beginner, so I plan to start there.

7. Schedule study / practice.

My evenings often end up being extended mashups of coding, reading, and television. It's nice to have a relaxed feel about practice, but too often, it means less quality time with my wife and dogs. I'd like to schedule my study, both to increase the quality of my work during that time and to increase the amount of quality family time.

I'm sure the ways to achieve these will vary, but I think they're specific enough to drive my growth as a developer. I'm excited about continuing the improvements of the past year in 2010, and I hope that by focusing on these "resolutions", I'll even accelerate things a bit. I'd love to hear other ideas people have for improving their skills in the coming year!

Why Software Development is a Craft

2009-10-22T12:41:00Z

Craftsmanship has been used as a metaphor for software development. Pete McBreen argues in his book “Software Craftsmanship” that craft is a better metaphor for software development than is engineering or science.

I take the association one step further and claim that it craft is not just a good metaphor for software development, but that software development is literally a craft.

The Hand and the Eye

A key facet of historical craft is the intimate connection between the hand and the eye. A furniture maker cuts a joint with his hands, then fits the two pieces together. If the alignment isn’t perfect, he sands and trims and fills until the joint is true. It’s a cycle of shaping and observing. A glass blower turns the bead of molten glass over and over in a steady rhythm as she shapes the glass towards its final form. Her eye informs her hands and she constantly sees the effects of the changing speed and angle of the turning rod.

Code is a physical thing. Though technically code is nothing more than some states stored on a fast spinning magnetic disk, it is just as physical as a lump of clay. Consider the language used when talking about code. It is touched, shaped, moved, broken, cut, pasted, fiddled with, tweaked, and played with. It is the physicality of code that enables the feedback between the hand and the eye. It is touched and a change is observed.

This is why Test Driven Development is such a key practice in software craftsmanship. There was a time when a programmer would write a bunch of code and try it out hours or even days later. The time between making something with the hand and seeing the results was long. When a programmer writes a little bit of test code and runs it, then a little bit of production code and runs it, this cycle shrinks to minutes or even seconds. The connection between the hand and the eye increases. The craftsman immediately sees the work of his hand.

Making

Another element that makes software development a literal craft is that software development is a process of making. Contrast that to engineering. What is the primary activity of an engineer? It is design. A civil engineer designs a bridge that an ironworker builds. The electrical engineer doesn’t typically etch or populate the circuit board. She designs a circuit that is printed on a board and populated by either machine or technician.

In contrast, the software craftsman doesn’t just design the software (though she does do that), she also makes it. She writes the code that makes it work. There is little manufacturing involved in taking the made software and putting it in the hands of the person who will use it. Sometimes there is a deployment to a server or perhaps a CD is burnt and packaged in a box. But often even these tasks are performed or automated by the maker herself.

Material

Historical craftsmen have always been makers. The potter makes a vessel; the blacksmith, a horseshoe; the weaver, a garment. These makers have always had close connection to the raw material of their work: the wool, the iron, and the clay. What then is the raw material of software craftsmanship? What is the material of which software is made?

The material of software is language. Java, Ruby, C, Scala, Clojure, etc.: these syntaxes are the medium in which the software craftsman works. What makes this media so interesting is that the materials themselves are composite materials made of more primitive materials. Beneath Ruby code lies an interpreter built in C which is compiled by a compiler. The most basic of which is built in an assembly language which is assembled by an assembler which is built in the most primitive machine language which is read directly by the computer’s processor. Each new language emerges out of other languages as craftsmen explore the materials and invent new ways of combining and deconstructing what they have at hand.

It’s similar to metal alloys like steel. Iron is combined with other metals to make an new raw material whose strength enables the construction of enormous buildings. Each new language innovation gives the software craftsman a new, more powerful material from which to build both larger and simpler systems.

Tools

A discussion of software as craft isn’t complete without mentioning tools. A software craftsman does deal with the hardware on which his software runs, but the more interesting tool set is the software that the craftsman uses to write code. The text editor or development environment, the unit testing framework, the continuous integration system, and the acceptance test system are the tools of the software craftsman’s trade. Because these tools are built from the same raw materials as the thing being made, software craftsmen have the ability like historical craftsmen to be tool makers.

Learning

The final argument for treating software development as a literal craft is the way in which it is learned. A traditional college education in computer engineering or computer science produces graduates woefully unprepared to develop software. The best way to learn how to make software is to sit down with someone who knows how to do it and learn from them. This is currently being displayed in many shops throughout the world that are embracing an apprenticeship model for training and growth. This model has been used for centuries to pass on crafts from one generation to the next.

Software is Craft

The Software Craftsmanship community is growing and having some fabulous discussions. I think that this is largely a result of people not just using craftsmanship as a way to talk about or explain software, but embracing and practicing software as a literal craft. The historical crafts have begun to inform us in the software craft and have helped us develop our practice. Most metaphors break down when taken too far, but software-as-craft isn’t losing any steam. Perhaps that is because the association is more than metaphor and software really is a craft.

Limelight 0.5.0 Released

2009-10-19T22:16:00Z

Today we released a new and exciting version of Limelight. Just a reminder, Limelight is a user-interface framework for Ruby. Included in this release are not only some new features, but also a new means of production(application) distribution called Playbills, and a snazzy production that documents the Limelight framework.

Playbills

Playbills is a hosted repository of available Limelight production. When you open the Limelight application, Playbills will open automatically (assuming you’re connected to the internet) and display a playbill for each production. Each Playbill provides a brief description to help you decide if you’d like to open the production. When you’re convince, click on the provided button. The production will be downloaded an opened in Limelight. Pretty nifty I think.

Limelight Docs

Among one list is a Playbill for our own Limelight Docs production. We’re quite pleased with this one. It’s a swiss army knife of documentation that should make it fairly simple for developers to build their own Limelight productions. You’ll find descriptions, walkthroughs, RDoc, and dynamic sandboxes where you can experiment with the features right inside the documentation! What’s more, the RDoc is loaded dynamically from Limelight’s runtime… You can’t get more up to date than that!

Status

Limelight has been a thrilling side project to work on. I’m very pleased with how it is turning out. We are using Limelight internally at 8th Light for a variety of projects. This release (0.5.0) is still a beta but the Framework is maturing rapidly. Although there are still a few rough spots, I’d certainly be willing to use it for production projects. Development on Limelight is active and the productivity advantages of using Limelight are hard to beat.

P.S. If you have a production you’d like listed on the Playbills server, let me know (micah at 8thlight dot com).

Pair Fridays

2009-10-06T21:17:00Z

8th Light has always had an open door policy towards developers. When anyone has asked to come hang out at 8th Light offices, we don’t turn anyone away. We also invite developers to come in and pair with us. It has been a fun practice to get to know other developers here in Chicago as well as developers traveling through town. We would like to flip that practice around and invite anyone interested in pairing with 8th Lighters or just coming in to hang out.

Every Friday we have a noon lunch and learn (lunch provided by 8th Light) and then we will be available to pair for the afternoon. Want to come in and see how we work? Learn to use Limelight? Teach us something cool? Just hang out with cool developers?

Please RSVP with me (paul [at] our domain name) so we know how much food to order.

Reflection on Hangman

2009-10-04T17:43:00Z

Last week concluded the Hangman Ruby Sparring Tournament. The results are below.

Unlike the previous Battleship Tournament, I put the effort in to write a competitive hangman player (of course he was banned from competition). This made things interesting. By knowing precisely what it takes to create a player, I was able to precisely tune the scoring metrics. My goal with the scoring metrics was to evaluate the code, without actually looking at it myself, and rate it’s quality/cleanliness on a scale of 0 to 100, where 100 was asymptotically impossible to reach.

It is not easy to score well on ALL the metrics. Each metric will push your code in a different direction some of them are opposing. For example, to score well on the flog metrics, you have to break your code up in to lots of tiny methods. However, extracting methods increases the amount of code you have which brings down the simplicity score. To get an overall high score requires compromising between opposing metrics over and over again. Realistically, writing clean code requires the same type of compromising between coding principles. I am thoroughly impressed with the high scores that people were able to achieve in this tournament.

In the end, I believe that the highest scoring players do fit many of the criteria for “clean code”. Which is to say that to metrics used to evaluate the code are fairly complete. However, there is one gaping hole. The highest scoring solutions look like this:

def b
  @r.fill(0)
  c
  @l = @l.sort_by { |x| @r[x] }
end

People discovered that by using short variable names and method names, they could considerably reduce the “simplicity” of their solution. For this tournament, the simplicity score measures the code mass (compress all the code and count the bytes). It’s a fair metrics because in general, the less code there is, the less code people have to read to understand it. I especially like the fact that comments hurt the score. Anyhow, clearly the code above is not good code.

What’s missing is a analysis tool to measure “Readability” of code. I imagine such a tool would be similar to flog and flay in that it parses your code and examines all names used for variables, methods, classes, etc. When it finds 1-letter names like above, it punishes. When it finds names containing english (or other languages) words, or derivatives of other names, it rewards. For example, it I had a class named “Player”, that’s an english word which is readable. Good. Now a class named “ThingAmaBob” is not english but that not necessarily bad. And you’d expect variables with names like “mythingamabob” or “thingama_bobs” which would be good. There are plenty of ways to expand on the idea. Such a tool would bring our repertoire of metric tools one step close to completion.

Apprenticing to Mastery

2009-09-29T15:48:00Z

Come see Dave Hoover and I speak about about software apprenticeships on November 19, 2009 in San Fransisco.

Thoughts from a Boutique Software Shop

2009-09-12T17:51:00Z

Michael Feathers recently wrote a blog about boutique software shops. He drew the parallel between master chefs and software shops. There were a few great points I would like to respond to:

1. “So, where are the high-end restaurants of software development? One place to look is in the “boutique software shops.” I don’t know where I first heard that term, but for me it is a “catch all” for all of the small software development houses that I see springing up all over the place.”

This is an interesting phenomenon. I am not sure if this has always happened or if I am paying attention more to boutique shops now that I am a part of one. 8th Light is an 8 craftsmen software shop that started in 2006 with the goal of writing high quality software. No teaching, coaching, staff augmentation. Just writing software, with the idea that focusing on proving quality has a high correlation to success.

I agree with the high-end software shop analogy. If you take a small team of trained craftsmen focused on doing their best work, the result is most often a very strong culture of quality. Ramsay creates this strong culture of quality through a theatrical performance of yelling and screaming at failure. There are other ways for masters to do the same thing. Micah Martin, the 8th Light master craftsman, creates this strong culture by setting an example of writing good code and holding yourself to a constantly higher standard. This is the common thread that I have seen through these boutique shops–they all have an owner who is a technical leader who creates a strong culture where (excuse the pun) failure is just not an option. There are other similarities like strong discipline, small teams, cutting edge technologies, and ability to develop strong skill sets in developers, however, I think that all of these are direct descendants of the strong leadership.

2. “It’s not that development teams need UX people, it’s more like UX teams need developers.”

I partially agree with Michael. I think this statement can be replaced with any critical specialization in the domain of software applications. The reason UX is getting a spotlight is because, as Michael notes, we have stuck UX on the back burner for so long. In the last few years though, the expectations from users of software have luckily skyrocketed. It is no longer okay to plow through features, but they need to be simple, attractive, and intuitive. When I worked with Gilberto Medrano in 2005, he talked about the UX revolution that was coming. In 2006, he created a UX design while at 8th Light that continues to impress 3 years later (in web application years, that is a lifetime). Well, he was right, I can no longer stand an application which is not aesthetically pleasing. It doesn’t matter how cool the feature set–which is a weird statement to come from a developer.

This is an argument for craftsmen teams. Craftsmen have many tools in their bag, and UX is one of them. Part of being a craftsman is to know enough about UX that you can talk to an expert as well as do some UX. Just like a UX expert craftsman can dabble in code. A craftsmen has many shallow skills as well as a few very deep skills. Craftsmen teams have individuals with diverse expertise talents and a common knowledge of intermediate and beginner talents. It is very fun to be on these teams, when the work is one which has quality–quality of being “aesthetically” impressive as well as “feature set” impressive.

Hangman Tournament

2009-08-28T21:17:00Z

Several months ago, I hosted the Ruby Battleship Tournament. It was an all-round fun event where craftsmen sharpened their claws and pitted their skills against their peers. Since then, there has been much interest in the next tournament.

Today I am announcing the commencement of the Ruby Hangman Tournament. In this tournament your challenge is to build an AI to play hangman. Unlike Battleship, your AI will not battle against opponents, but will instead play solo. You must teach your player how find words as accurately and as quickly as possible.

The most prodigious player will be dubbed Tournament Champion. But this is a tournament of Craftsmanship, so the ultimate title will be awarded to the Tournament Master. To earn this most prestigious of monikers, your player must not only play hangman spectacularly, but also be crafted with the utmost quality of code.

Getting started is easy. Simply follow the instructions to get a default AI generated and running on your computer. Then all you have to do is tweak the solution to be as good as you can get it before the end of September.

This is a great way to practice your craft. You could introduce the tournament in your next user group meeting. Show it to your peers over lunch and learn.

You can also just play the game if you like (screenshot below). Good luck!

We're Busy!

2009-08-23T18:32:00Z

This week is a big one for the 8th Light team. Let’s head through the highlights:

Agile 2009

As usual a large number of 8th Lighters will be participating at Agile 2009. This is always a fun and educational experience for us, and this year it’s in our hometown. Let’s go through the talks we’re giving:

Mission Impossible: TDD and Javascript In the New Orleans room on Tuesday at 11:00 Jim Suchy will be giving a talk on doing TDD in Javascript. Javascript is a language that people tend to claim is “untestable” or “not worth it” but Jim will be showing that testing is not only possible, but worthwhile. In addition he demonstrates some of the neat features that make Javascript a cool language.

Ruby Kata and Sparring Back in the New Orleans room on Thursday at 9:45, Micah Martin will be talking about Ruby Kata and Sparring. Everybody wants to be a great developer, but how do you do it? Micah will show two different practice techniques, kata’s and sparring. If you go to this talk you get to judge the speaker and tell him how well he codes. How often do you get to do that?

TDD on iPhone The Eric’s are giving their legendary talk on practicing TDD on the iPhone on Thursday from 2:00 - 3:30 in Grand Ballroom F. This time we have a special surprise for those who attend - a Randori coding session where you will code functioning iPhone application. Please wash your hands before attending, as you’ll be using my keyboard. Head to my github page to see a sneak preview of what we’ll be working on.

Live Aid Once again some 8th Light guys will be helping out with Live Aid, including our newest Craftsman Colin Jones. Come to the stage, write some Rails, help charity. 10 minutes or 10 hours it doesn’t matter. Experience in Rails or even web development are unnecessary - that’s what the mentors are there for.

chiPhone

The second meeting of chiPhone, the Chicago iPhone developer group, will be held at a special location this week: the Obtiva offices! Thursday night if you’d like to do some hacking head to the chiPhone website to register - or just show up. I only need to count so I order the right amount of pizza.

SCNA America

I saved the best for last. Software Craftsmanship North America is a joint effort by 8th Light and Obtiva and frankly it has the best speaker lineup I’ve ever seen. Registrations are still available and cheap! If I could take credit for this I would - but it really goes to the organizers, who did a fantastic job. The entire 8th Light staff well be there and available for discussion, questions, and to accept free beer from the attendees. Meanwhile two of us will be speaking:

The Business of Craftsmanship “Craftsmanship sounds expensive!” If you’ve heard similar comments from your supervisors or clients, then join Micah, Kevin Taylor and Carl Erickson, three experienced craftsmen-turned-entrepreneurs for this 30 minute panel discussion. All three panelists come from technical backgrounds and have built successful software development companies that are built on craftsmanship values, such as quality, learning, and community, and use Extreme Programming practices to develop software.

Apprenticing to Mastery Listen to Paul and Obtiva’s Dave Hoover discuss how an Apprenticeship program can benefit your company and your career. Software companies are always looking for ways to develop skilled developers. Formal software apprenticeship is the approach taken by more and more companies, including Obtiva and 8th Light. Over the past 2 years we have observed almost a dozen apprenticeships and come to recognize certain apprenticeships of developers that are themed by their aspiration to mastery.

This might be the biggest week in 8th Light history - hope to see you there!

JRuby Installer Samples

2009-07-22T02:55:00Z

The JRuby dev team is interested in distributing friendly installers for future released of JRuby. The installer will take care of unpacking files, setting environment variables, and even installing Java is need be. Sweet huh?

Having worked with Install4J on Limelight, I proposed using it for JRuby. The good folks at ej-technologies were kind enough to donate a license so I whipped up some installers. But there are a few options to consider and we want to choose the option that offers the best experience.

Below are links to sample JRuby installers for Windows (built on my mac) using Install4J. If you’re willing, try out an installer and let us know what you think.

Disclaimer: Use at your own risk.

Bowling in Clojure

2009-07-20T14:52:00Z

I’ve been long overdue to learn a new programming language and Clojure recently caught my eye. Clojure attracted my attention because it seemed like a rich Lisp dialect where I could learn all the goodness of functional programming, and it runs on the JVM allowing me to make use of all hte Java goodness out there.

Along with a couple colleagues at 8th Light, I read Halloway’s Book. We then challenged each other to write the bowling game in Clojure so we could compare our solutions. Coincidentally, my father, Unclebob, performed the same exercise independently. Below is my solution.

First comes the tests:

(ns micah.test.bowling (:use micah.bowling clojure.contrib.test-is))

(deftest test-gutter-game
  (is (= 0 (score (repeat 20 0)))))

(deftest test-one-pin-wonder
  (is (= 20 (score (repeat 20 1)))))

(deftest test-one-spare
  (is (= 20 (score (concat (list 5 5 5) (repeat 17 0))))))

(deftest test-one-strike
  (is (= 30 (score (cons 10 (repeat 18 1))))))

(deftest test-perfect-game
  (is (= 300 (score (repeat 12 10)))))

(deftest test-all-spares
  (is (= 150 (score (repeat 21 5)))))

(deftest test-heart-breaker
  (is (= 299 (score (concat (repeat 11 10) (list 9))))))

(run-tests)

And the production code:

(ns micah.bowling (:use clojure.contrib.seq-utils))

(defn score [rolls]
  (loop [score 0 rolls (vec rolls) frame 1]
    (if (> frame 10)
      score
      (cond
        (= 10 (rolls 0)) 
          (recur (+ score 10 (rolls 1) (rolls 2)) (subvec rolls 1) (inc frame))
        (= 10 (+ (rolls 0) (rolls 1)))
          (recur (+ score 10 (rolls 2)) (subvec rolls 2) (inc frame))
        :else 
          (recur (+ score (rolls 0) (rolls 1)) (subvec rolls 2) (inc frame))))))

Thoughts

As with learing any new language, writing this first program was frustrating. Getting the environment running took a while and simple tasks, like creating a list of 20 zeros, required several minutes of research. Nonetheless, I was very pleased when it was complete.

I was quite impressed with size of the program. Compared to previous Java solutions I’ve written, this Clojure solution is about 20% the size. That’s a huge size reduction. But as I compare the solutions more, it occurrs to me that the Clojure solution is also about 20% as readable. Just look at it! You could get lost in that cond statement for eons.

Now my craftsmanship spirit was nagging me all the while I was coding, just begging me to refactor. However, I struggled to find good ways to improve the code. All my typical tricks, extract variable, extract method, didn’t feel right. My hope is that I’ll acquire new tricks to refactor in Clojure from experienced Clojure programmers, perhaps like you. Please let me know if you see a way to improve my code.

Reasons to Attend SCNA

2009-07-17T16:56:00Z

SCNA website

1 - “The list of SCNA presenters reads like Who’s Who of Software Jedi Knighthood” -- Ray Hightower

This is a complete testament to how willing and excited the thought leaders and software masters were to speak at this conference. The creme of the crop in software mastery will be talking about how to raise the bar in our industry. I have never seen a lineup of speakers who put me in such a state of awe since the early XP Universe days. Thanks to all of them for getting together for this conference.

2 - Join software craftsmanship over crap.

Last year Uncle Bob challenged software developers to become professionals. We have spent a year of summits, manifestos, meet ups, and conferences trying to figure out how to move forward towards professionalism with this paradigm of software craftsmanship. The momentum of craftsmanship is only growing.

3 - Software craftsmen all in one room.

The google map of software craftsman who have signed the software craftsmanship manifesto has proven this to be a global community of software developers. It is unique that we have people flying in from multiple continents to participate. I am excited to meet face to face with all these craftsmen whom I know only their ideas and email addresses.

4 - Richard Sennett

A sociologist who wrote The Craftsman, Dr. Sennett has provided a template for studying the habits and techniques of craftsmanship. He touches on everything from extending your concentration to why we choose vocations so passionately. It is a true authority on craftsmanship.