Road Thoughts - Just Do It

One of the most common bits of feedback I get from people after hearing me talk is the idea of 'just do it.' It isn't a crazy, innovative idea of mine, just something that people often like to hear from an external source.

So, you want to start doing something? You would like to start pair-programming or TDD or use continuous integration or quit your job or start up a worm-farm business? Okay, come ask me how to get started. Here's the answer: 'just do it.'

On the way back from the Philly Emerging Tech conference (great conference, by the way!), I stopped at the Laurel Hill Cemetery and did a quick road thoughts where I talk briefly about this.

Enjoy!


Road Thoughts - Just Do It from Corey Haines on Vimeo.

Road Thoughts - Hailstorm!

Well, I just got back from Philadelphia, where I spoke at the Philadelphia Emerging Technology conference, as well as being on a panel discussion hosted by the Agile Philly user group. I had a great time, and I'll write a bit more later. I recorded a road thoughts on the way home, but I also recorded this very special road thoughts direct from the road on the way back to Cleveland. Yikes!

Enjoy!


Road Thoughts - Hailstorm Holy Crapality! from Corey Haines on Vimeo.

Talk at Chicago Software Craftsmanship Group

While I was in Chicago, I was invited to talk at the Software Craftsmanship Group. I spoke for a while on thoughts I have surrounding the concepts of practice. This was a really fun time, and I appreciate 8th Light for hosting these meetings.

Enjoy!


Practice - Corey Haines from 8th Light on Vimeo.

Time to Green Graphs with Gary Bernhardt

At Code Retreat 2, Gary Bernhardt did a presentation on a new thing he's been thinking about: Time to Green Graphs. This is a really cool idea that I think would be an awesome plugin for IDEs, as well as a hook for autospec.

Kudos for LeanDog for hosting. And, yes, we were on a boat!

Enjoy!


Time To Green Graph by Gary Bernhardt from Corey Haines on Vimeo.

Road Thoughts - Apprenticeship

I stopped at the wildwood reservation metro park in Toledo on the way back from Lansing, MI, and put some thoughts down on the Software Craftsmanship Manifesto and its use as a beacon for developers to find a similar-minded community. I focus on my thoughts behind apprenticeship as an effective means to fix what I call the broken 'inherited knowledge model' we currently have.

Enjoy!


Road Thoughts - Apprenticeship from Corey Haines on Vimeo.

Conversation with Paul Pagel

Paul Pagel, one of the owners of 8th Light, was kind enough to host me for a couple days during my most recent trip to Chicago. I'm always happy to be in Chicago, as it is such a great hub for the Software Craftsmanship movement. Paul was the organizer of the Craftsmanship Summit in December, as well as been a driving force on the mailing list.

We recorded this video on Saturday morning, the day after we released the "Software Craftsmanship Manifesto." Paul talks about the motivation behind both the manifesto and also his views on the Software Craftsmanship movement.

Enjoy!


Conversation with Paul Pagel from Corey Haines on Vimeo.

Jay Fields on Pairing

Jay Fields has a great article in InfoQ about adopting pair-programming. I've done a lot of pairing in my time, both with experienced pair-programmers and not-so-experienced ones. I've talked to many companies and people about the ideas behind it. Jay really does a great job of explaining these concepts, and I plan on pointing people to his article in the future. Well worth the read, for sure.

Lunch Discussion with Hashrocket

While I was down in Florida at Hashrocket, Stephen Caudill organized a lunch discussion with me and the Hashrocket employees. Among other things, I gave an explanation of my views of Software Craftsmanship, the XP principles and techniques and also made a totally sweet A-Team reference!

Also, one of their customers, David Cohn of Spot.Us, gives some insight into why he chose Hashrocket.

(While down at Hashrocket, I had the pleasure of doing a video interview with Stephen Caudill. If you haven't watched it, yet, make sure you do; he's got some great ideas.)

Yeah, it is long, but you can just put it on in the background and listen; Pretend it is an audio-only podcast!

Enjoy!


Craftsmanship Lunch 'n' Learn with Corey Haines from Hashrocket on Vimeo.

Conversation with David Chelimsky

During my second tour through Chicago, I got the opportunity again to spend a couple days with David Chelimsky. Due to some timing issues with his project, we didn't have a tremendous amount of time to pair on work stuff, but we wrote some great stuff for RSpec (custom matcher DSL rocks). We finally had time to sit down and have a brief conversation on the morning I left. David had some ideas on open source projects and in-person pair-programming. It is early, before our first coffee, so you can tell we are a bit tired. David has some very interesting insights into his work on maintaining the open-source BDD framework, RSpec.

David's book, The RSpec Book, is in beta at The Pragmatic Bookshelf. I'm working my way through it, so I can say that it is a great tutorial on using RSpec and Cucumber (and other tools) to develop software.

In case you missed it, here is the first discussion we had back in December. We talked about testing, spec-first development and some other thoughts.

Enjoy!


Talk with David Chelimsky (February 2009) from Corey Haines on Vimeo.

A story about 'getting it done'

I had a great time pairing for a day with Uncle Bob, getting a treeview integrated in FitNesse for navigating the pages. We were using the YUI Treeview widget, and ran into an interesting situation. I've related it to a couple people now, and the story always takes the same turn towards 'pragmatism', so I thought I would write it here.

Uncle Bob and I spent a bit of time spiking out the treeview integration, trying to understand what divs were required, how the dynamic loading worked, etc. Once we had a feel for it, we looked at each knowingly: we are at the point where we need to start having tests for this.

Neither Uncle Bob nor I had much experience unit testing javascript, much less test-driving it. I've done a lot of javascript in the past, but I've never taken the time to learn any of the testing frameworks (yes, horrible, gaping deficiency in my skillset, which I am working on improving through practice). Add to that the fact that I'm more familiar with Prototype than JQuery, and the situation gets even more complicated. As is the case, my first inclination is to go find a testing framework. I did a quick google search, saw QUnit was the jquery framework and decided to take a look at it. We set a timebox for investigation (I think it was 15 minutes) and started reading about it. Hmmm.... It seemed complicated enough that it was going to take us more than 15 minutes to get it set up for the first time and start using it. We got to the end of the spike with not much better of an understanding. Since I was only there for a day, we didn't want to spend it just trying to get a testing framework set up. We just wanted to get it done with a minimal of fuss.

This is the point in the story when everyone's ears perk up, since I'm always ranting about what you do when you have to 'get it done.' After all, this is the defining moment for your skills. What you do at this moment is fall back on your techniques. This is when I see a lot of people start throwing around 'pragmatism' to make excuses for themselves. For me, this is the moment when you look at the situation and figure out how to stick to your principles with what you have.

So, instead of just throwing our hands up and hacking away, we took a second to think about what we really needed. For our simple situation, all we really needed was assertEquals(). So, I wrote the following javascript function:



After all, the very basics of testing is checking that two things are the same. Now, there comes a time when you might need a slightly more robust situation (checking floats, for example), but we didn't have this requirement. This took me less than a minute to write. Then I wrote the supporting html:



So, as we wrote new tests, we added them to the list. We weren't able to run them all in a suite, instead having to refresh the page each time and click the next one. But, since what we were doing was fairly simple (we only ended up with 6 or 7 tests), this wasn't a huge problem.

The half hour that we spent investigating QUnit and then writing this small utility saved us much more time than that over the course of the day, as we were experimenting with features later on. And, yes, we even wrote tests for the AJAX calls (stubbing out the jquery ajax request).

Moral of the story? For me, this was a great example of what happens when you spend a little bit of time to dig into what your fundamental problem is and work towards that. Rather than make excuses for our deficiencies (lack of experience with a js testing framework), we figured out the simplest thing that we needed and ran with that. For us, the simplest thing was not just hacking away in an environment we weren't familiar with (jquery ajax stuff, yui treeview). In the end, we got the treeview integrated and working, exactly what our goal for the day was.

Figuring out the simplest thing that you need isn't a skill that comes for free, though; it takes practice.

Stuck between a rock and a hard place

Steve Smith (blog) asked me what I would do in a particular situation, and I said I would give my advice.

That is indeed a rough situation. Let me see if I understand the facts correctly before I say what I would do

• Small business owner/developer decides to move his team to .Net using C#.
• His team is unskilled in writing maintainable systems on this platform.
• He has to do this switch ASAP using the team he has.
• He only has money for a few hours of your coaching time 'here and there' to get his team and product onto the .Net platform.
• He's a friend of yours

Short answer: Run Away. In my experience, there be dragons, and this isn't going to turn out well for anyone.

But, that last point is a stinker. He's a friend, so here is a longer answer.

This sounds familiar. I'm sure that a lot of the people who read your blog and mine have seen this situation. Most of them have probably seen the outcome, too: a system that will very rapidly get to the point of where changes take too long to implement, resulting in the entire system needing to be rewritten. This isn't accepting 'technical debt,' this is accepting 'technical bankruptcy.' In fact, to quote a well-known movie: "You keep using that word. I do not think it means what you think it means." I'd recommend explaining to them what technical debt is truly about (Ward Cunningham has a great explanation here. He coined the phrase, so his word should lend support to your recommendation. Hint: it doesn't mean "bad code, because we don't have the skills to write it better."

Well, this developer/business owner obviously has put himself in a severely limiting position based on most likely some bad choices. Let me outline a couple of the ones that I've seen before that sound like they might align with this situation.

1) Waiting until the last minute to make significant technology changes.
From the urgency in your post, I'm assuming that the switch to the .net platform needs to be done 'ASAP (yesterday, ideally).' So, a developer with '20+ years of experience' decides that it is best to wait until he is forced to move to a modern development environment with his application. The current platform is no longer shipped. Was this a sudden occurrence?
Solution: If your company depends on this product, make sure you keep your eyes on the future of it.

2) Assuming that you (and your team) can just 'pick up' a new technology.
Learning a new technology, especially a new programming paradigm, takes time and practice. I have met very few people who can jump to a new technology and be successful writing business critical applications.
Solution: You need to give yourself and your team enough time to achieve a reasonable level of proficiency in the target platform. This is done by looking forward to where the industry is going, figuring out a plan for where you need to go. Once the plan is in place, begin training your team. The time to bring a coach in is not when you are under the gun and the ship is sinking, but, rather, when you have time to train correctly. Sadly, in our industry, the former is far too common, and the latter is too rare.

3) Expecting that a few hours of coaching 'here and there' will be enough to bring the team forward.
Introducing new concepts to a team in the midst of a rushed product often leads to a less maintainable system than if the team continued with their original approach. SOLID concepts and their applications are often confusing to people when they are first introduced to them. This confusion often leads to misapplication of the techniques.
Solution: Get through the death march with the understanding that code written will need to be re-written. And, please, do not call this 'technical debt.' Call this throwaway code to counter bad decisions. Again, point them to Ward's video to explain what 'technical debt' really means.

But, those are just pointing out the bad mistakes. That's just one aspect of really helping. Since this is a friend, we want to help moving forward.

Since they only have a few hours of coaching, I'd highly recommend putting together a set of focused practices that will allow the team to more rapidly build their skills in the necessary techniques. Some of us in the Software Craftsmanship movement are starting to organize regular Code Retreats that focus on practice. These might be beneficial for your client. Other people are doing similar things.

Another idea: Rather than only talk to (or briefly code with) them about concepts, take the few hours that you have and prepare a set of exercises that they can use to hone their skills. I'm working on a set in Ruby, but you could probably port them to C# with a small amount of little effort.

The important thing is to give them structured forms of focused practice that will allow them to practice, outside of project work, the techniques that make up these concepts.

But, in all honesty, I truly believe they are setting themselves up for failure, and the best thing you can do is help them as much as possible with the realization that, when and if it fails, it will be not because of agile, not because of craftsmanship, but because of poor choices and lack of planning.