James Carr

When it comes to working in the software industry, I think I can best sum up what a majority of developers and teams do by simply quoting Pink Floyd from the song Breathe:

Run, rabbit run
Dig that hole, forget the sun
And when at last the work is done
Don’t sit down
It’s time to dig another one

I think that verse goes quite well with what I kind of view as the default behavior of developers when they stand beneath an overwhelming amount of work that is ahead of them on a project. It’s quite easy to “hit the ground running” and work as hard and quickly as possible, kind of brute forcing their way through it. The end result can truly mean forgetting the sun and leaving all manner of holes in the codebase with a rushed, “the sky is falling” feeling continuously looming over them while working on multiple tasks at once.

Sustainable pace is very important because if you don’t adhere to it you’ll often find quality will suffer. Working nonstop will burn you out in the long run which can be seen either by silly defects or sporadic performance. Additionally, by maintaining a pace you’ll also have a better opportunity to manage your relationship with your customer and enjoy a rich communication channel with them rather than succumbing to rushed, last minute conversations over instant message in the eleventh hour with them waiting for each new deploy to “see if you fixed it” (and believe me, being in that situation can really suck).

Add slack to your iterations, estimate work before committing to it and keep your work in progress limited rather than trying to tackle 900 things at once. Only do what you’ve committed to for the iteration, and if you get everything done use the slack time to improve the environment or even improve relations with your customer by going over the existing and planned features with them. Don’t take on the next iteration’s work early, instead schedule stories to work on during slack time that can make future work simpler.

For long you live and high you fly
But only if you ride the tide
And balanced on the biggest wave
You race towards an early grave

True knowledge exists in knowing that you know nothing.
- Socrates

As those of you who read my blog often know, I recently made a career jump to a contracting firm to consult at different large scale organizations. To my dismay, my first assignment has been more as a developer than as a coach/scrum master, but I felt this would also be a good opportunity to observe and understand how to coach effectively. I might even experiment with seeing how well I could help improve practices from the trenches.

You see, I thought I knew all there is to coaching after being in an agile environment for three years and seeing a lot of good and bad approaches. The contrast between that and my current workplace has been profound… I’ve often been swift in pointing out rotten practices, often citing a lot of the good practices that I’ve experienced work well and know to be right. I’ve also found myself sometimes written off when I vocalize my observations.

Anyway, while I was walking my dogs this afternoon it hit me… coaching isn’t about being right, it’s about providing options and helping the team discover better practices.

Yesterday during our morning huddle one of the developer’s mentioned that on the story he was working on he had achieved 97% code coverage and this got me thinking a bit about something that’s been on the tip of my mind for awhile. Now, I cannot speak for the developer at my huddle because I haven’t seen his test and I can assume that they’re well written, but I often have heard through my career reports of good code coverage and have seen instances where code coverage was used as a bad metric in the worst possible way.

Read More »

Something I have heard in the past is the bemoaning about injecting a dependency just for the sole sake of being able to test the use of that dependency, and while reading email today I saw that someone built a “handy utility” for replacing dependencies without having to make a setter or constructor. While they saw this as a great way to bypass code created “just for testing” I disagree on the reason that Test just quite simply are not Tests.

When you are doing Test Driven Design (note that I didn’t say Development) you are not just creating an exhaustive suite of unit tests to test your code and you’re not “testing everything that could break”, if you are you are doing it wrong. Rather, by test driven design you are describing your design… you are describing the API, how it behaves, how it works. Most importantly, you are using your tests as examples of how the system under test works in a given situation and using the examples to drive how your system is designed!

As such, using Inversion of Control or Dependency Injection to provide the dependencies to your System Under Test is in no way, shape or form creating needless test code… I will tell you right now that if you are creating protected setters to inject dependencies you are misunderstanding Dependency Injection and need to re-read up on it a bit. The way I see it you should have a system that is composed of two kinds of objects… objects that have new littered all over to create objects and objects that do things (sometimes with dependencies provided to them). With this being the case, you don’t want objects that do things and have the new keyword all over the place.

I’ve seen a lot of code written that uses multiple constructors, one that takes a dependency and one no-arg constructor that creates the dependencies it needs itself. This is a general example of code that one might complain is playing lip service to the tests around it, but my solution is do away with the no-arg constructor. You’re injecting at the wrong level. Either do one of the following:

• Use a Dependency Injection framework like Guice, Spring, or PicoContainer
• Push the dependency creation to the client
• Organize code into modules, with the module definitions creating and wiring the dependencies

Just my random thoughts on it… with all the confusion of Test Driven Development being focused on Testing, you can see why I’ve been really preferring Behavior Driven Development for the aspects that BDD is often called “TDD Done Right”.

Dependency Injection is about design, which happens to make you design easier to decouple from dependencies and therefore easier to provide Mocks,Stubs,Fakes,or Spies to describe how the system uses those dependencies.

Recently I discovered an interesting blog thanks to Tim Ottinger’s comment on my TDD Anti-Patterns post, Agile in a Flash. It looks like they’re putting together a comprehensive book plus flash cards about Agile, and from the few posts I’ve read it looks very interesting. Check it out!

Whew… looks like my “Week of javascript TDD frameworks will really turn into a month of ‘em. Fine by me though, I like options. For a bit of randomness, I’m going to try out jqUnit. jqUnit is a TDD framework that takes quite a different approach… it is structured much like jquery is and tests are laid out in a jquery kind of way. Although it depends on jquery to run, your SUT does not have to have jquery as a dependency. Anyhow, let’s take a quick dive into the dirty details and then get started.

The Dirty Details

Basically another xUnit framework, but the syntax is radically different from any framework I’ve seen, xUnit or BDD. instead of your usual “assertXXXX” or spec syntaxes, it simply uses yep and okay . Most importantly, this is the framework used by jQuery to test itself.

Read More »

First let me apologize for the delay in my posting. My intention was to post about a javascript testing framework each day, but the last couple of days I got a little stuck trying to get inspec to run.That coupled with the other things in life that compress my time I was just unable to make any progress! I finally decided to give up on inspec as it’s kind of specific to a certain domain (ServerJS) while my experiments have been rooted in the test driving of client side behavior. So, to move on, I’m going to do todays example using Screw.Unit!
Read More »

For the first installment of my Week of TDD and BDD Javascript Frameworks I’m going to cover JSSpec. First I’ll cover some of the specifics and then jump straight into a demo of using it.

The Dirty Details

JSSpec, as the name implies, is a Behavior Driven Development framework based on the popular rspec ruby framework… as such it borrows heavily from rspec’s structure and functionality, using a function named “describe” to start a spec and values are evaluated by passing them to a function named value_of which returns an object containing methods for performing assertions on the value. For example:

  value_of([1,2,3]).should_contain(2);
  value_of(name).should_be("James);

Now for the other details:
Read More »

I’ve been doing a lot of ruby on rails work lately, and in absence of TextMate on my linux laptop I was searching for something good to use. Eclipse with RadRails is okay, but sometimes it can be a heavy weight (and random long startup times and random “initializing java tooling” bogs me down). So I tried just revisiting my roots and using vim, which worked well enough, but felt uncomfortable in the whole dev cycle.

SO I searched the net and found an article on how to Pimp Gedit. Coupled with MultiTerminal, rails development has been a breeze.

Oh… and rspec and cucumber ran with autotest rocks!

Some of you may have attended the MidMoXp usergroup which I began organizing on behalf of CARFAX in September of last year. Although the usergroup always had very good meetings and even a couple notable speakers, it’s always suffered from on again off again scheduling, mostly in part due to my own rather haphazard, sometimes conflicting schedule.

Luckily, the on again off again scheduling will be gone as the group will no longer be solely organized and put together by yours truely… in other words, if I fall off the face of the earth, the next meeting will still take place.

But, that’s not the only news, there is much more activity afoot! When we met to plan the next meeting, we discussed several topics, and a specific question came up.

Why cater only to the eXtreme programming?

Which is a good question… only one organization in town (that I know of at least) does XP, while most might just be doing a few of the practices. By focusing just on XP, perhaps the group is a bit too narrow. We then decided perhaps it’s best to broaden the scope to include all things agile, but again, why stop there? There are quite a few people in town I know of who have no interest in agile, but they are interested in some of the agile practices or software development in general.

Which is why the group will be undergoing quite a bit of evolution. It’s no longer just focused on XP or agile anymore, but Software Development Best Practices. The topics will be a mix of technical, hands on activities (we will be organizing tutorials and coding dojos) with process related practices. You’ll still find a lot of agile related stuff, but as best practices versus promoting one methodology or another.

Our next meeting will be December 9th at 6:30 P.M. at CARFAX’s Columbia, MO data center. A co-worker of mine will be giving a presentation on Kanban boards with hands on exercises illustrating some of the advantages of using Kanaban boards to communicate progress. Hope to see you there!