LSSC Video of My Kanban Experience Report

Back in April I was selected to give a Kanban experience report at Lean Software Systems Consortium in Atlanta, and as luck would have it InfoQ had set up a camera in the room I was presenting in. Yesterday, they posted it online: http://www.infoq.com/presentations/Moving-to-Kanban

This was the first time I was recorded giving a presentation, so it's the first time I've seen myself give a presentation. And I must say, I am one of the presenters I've ever seen! OK, maybe not, but it wasn't as embarrassing to watch myself as I thought it would be. Seeing myself at least let me see some things I can improve on. (Dear Lord, Tim...STAND STILL for a second.)

And while I'm throwing some video out, Dave Giard recorded a video interview with me back at Codemash this past January. I finally got around to watching that one, too. For Dave's beer being off screen on one side and my bourbon off screen on the other side, it went pretty well.

Dave's Technology and Friends, Episode 71: http://technologyandfriends.com/archive/2010/02/15/tf0071.aspx

 

 

Large Latte, No Foam, Extra Code Please

A little over a year ago, Code and Coffee was born. After a weekend in Kalamazoo and a good talk with Mike about his little group of Bitslingers in Cincy, Jeffery and I stole borrowed hatched the idea to get our butts out of bed early, hit a coffee shop somewhere, and write some code. Any code would do, but preferably something outside our comfort zone. Code and coffee numero uno saw us working on the Ruby Koans.

It’s moved around Columbus to different places. Started out at Polaris, held in Dublin a couple times, and we’ve had a pretty regular group at Stauf’s in Grandview since last November. I’ve lost track of the number of new faces that have showed up at our little gathering, but there are a few – like Greg and Andrew – who have been to almost all of them.

“Yeah, so what, Wingfield…we know you do this Code and Coffee crap, it’s in your twitter stream more than ice hockey and Hair Band Friday combined.”

OK, ok…my point: Last Thursday, Aug 12th, we had a 23 geeked up, caffeinated coders in 3 locations in two different cities writing code for the fun of it before they went to work. 23 guys and gals in Grandview, Columbus, and Indianapolis. (Props to Scott for getting it rolling in Indy!) 23 people would be one helluva dev team; especially if it’s THESE 23 who care enough to get up and do an hour of coding for fun before work.

What do these 23 people compare to?

• That’s a whole football team plus a kicker
• That’s 10 more people than have ever coached the Chicago Bears
• That’s an entire active NHL roster
• That’s one less than all the sousaphone players in the OSU Marching Band…in other words, it’s all the sousaphone players NOT dotting the I.

That’s a lot of sports references for a bunch of geeks so…

• 23 is the atomic number of vanadium
• 23 is the port used for telnet
• Julius Caesar was stabbed 23 times…that might be a bad example
• 23 is the lowest prime number to consist of consecutive digits. (Back to geekdom!!)

I’ve had a lot of fun at Code and Coffee and can’t deny having 23 people at three locations on some random Thursday brings a smile to my face.

But why stop at 23?

Want to geek it up with fellow geeks? Start a Code and Coffee. Pick a place to meet and a time and hit up twitter. (We use the hashtag #codeandcoffee, it’s worked great for setting up gatherings.) Let’s go beyond 23 folks.

At least to 34 so I can make some Walter Payton references.

45 for a little Archie Griffin.

Then to 61 so I can add Rick Nash to the fray.

Why Not Add Some Ruby?

If twitter is good for one thing it’s starting debates amongst your friends. Today didn’t disappoint as Mike started us off with: “things i miss from rails while i'm doing java: rails.”

It started in the productivity trap, which is going to be subjective to the developer doing the work, so it’s a tough one to measure. Can I do some things faster in Ruby than I can C#? Yes, but the inverse is still true.

One point I need to make is I’ve seen a few of these discussions and often they become Rails v. C#/.Net, which isn’t really a fair comparison because Rails is a web framework. To go apples to  apples, you need to compare Rails to ASP.Net MVC, not .Net in general. You wouldn’t compare WebForms or WPF to Ruby or Python, would you? (You shouldn’t compare WebForms to much of anything…but I digress.)

So, Jon asked a pretty valid question: Why don’t more people switch? Since I come from a .Net background, I’ve really only seen this debated as it pertains to .Net.

For a number of the arguments around the IDE, Intellisense, Static v. Dynamic typing, there are plenty of other blogs that have covered this, here’s a recent one I really liked: Ruby is Scary.

For my quick entry here, I’ll say this…I can have VIM or TextMate open and have a couple tests written before the VisualStudio splash screen has closed. Also, those two tools have yet to throw an “Out of Memory” exception on me, can’t say the same for Studio.

And I don’t really miss intellisense.

On with the show…

On the heels of Jon’s question Bill Sempf jumped in. As a bystander, Bill was very much representing the average .Net dude, and the arguments I’ve heard from the average .Net dude. (Bill has looked into Ruby, we’ve paired writing Ruby. That’s not really the point here, though.)

Ruby, the Average Dev, and the Complex System

@JonKruger: That's not my problem. I just don't think that 80% of the dev teams out there can handle coding in Ruby. (link)

That was Bill’s entry to the discussion, and I’m not sure I can disagree with him. However, I’m going to be snobbish and self centered and say I want to work with the 20%. If you’re in the 80% and can’t code Ruby…or Python, or F#, or any other language you have to learn…I don’t want to work with you. You can stay in “The Enterprise.”

@JonKruger: My point is those stories are told by top-tier devs, and not everyone is one of those. (link)

Again, tough to disagree with Bill’s assertion here. Not everybody is a rock star, and that’s cool. If you’re a budding rock star, you’ll be able to write some effective Ruby code.

In between those tweets were a few others, mainly around supporting complex systems using Ruby. Personally, I haven’t written a large scale application in Ruby, so I can’t lean on any experience here in writing the typical central Ohio “claims app” in Ruby.

What I have done with it has worked well. So my first counter to Bill’s argument on the complex systems: Use it where it fits. Ruby brings a great set of DSLs to the table for testing, web frameworks, and testing. Yeah, said it twice. Year one of Codemash (Jan of ‘07) I listened to Neal Ford talk about DSLs to help write your applications and Polyglot programming. Using Ruby to support your app – to write build scripts, tests, POC web sites – falls right in on the polyglot thing.

On the testing side, I’d much rather read a batch of RSpec tests than a batch of nUnit tests. Cucumber is already helping my current team get through some testing issues. Let me repeat that: I’m using Cucumber in a .Net environment RIGHT NOW to help the team get better test coverage on their application.

Learning a New Language

@JonKruger: There is a difference between learning the language, and being productive in it. (link)

I’m in total agreement with Bill here. Which is why I’m such a big fan of the incremental approach to using Ruby on your projects.

Great place to start: use Rake as your build script. I’ve done this for a couple years now, it’s a great way to dip your toe into Ruby, get comfortable with the language and a few of its concepts without really getting in on your production code. On the .Net side, use Albacore with Rake and you’ll have a build script in no time.

Next up you can start writing some tests in it. That’s a pretty good way to pick up a new language, anyway. And with the nice testing tools with Ruby, you can learn a new language and ease some testing pain.

But, the main point here, don’t be afraid of picking up a new language. How many do you know already? If you’re a web developer, you probably already know Javascript, CSS, HTML, C# (or some back end language), a little SQL, and a healthy dash of XML. Picking up another one isn’t going to be too difficult.

Essence v. Ceremony

I first heard this from Neal Ford, possibly at eRubyCon a couple years back. But, Stuart Holloway had a great blog post about it prior to when I heard Neal speak.

To me (and many others), Ruby gets to the essence of what you’re after quickly. I find myself working within it’s idioms easily, not fighting them constantly with adapter patterns, dependency injection, and ORMs. I find that my tests flow naturally from the various testing tools I use in Ruby, and the code that makes those tests pass benefits from that.

So, to Bill’s point, maybe Ruby isn’t ready to have average devs write big, complex, “enterprise” systems in it. But, it is ready to support what you’re writing today. Right now. Why not give it a try?

Unless you’re afraid of learning…

3 Things to Help That Presentation Go Better

I recently gave two presentations at Codestock. One on Kanban that I’ve given a number of times and is well rehearsed, and another on IronRuby that I’d never presented before. I had given a similar talk, but a good bit of this one was new. Since I hadn’t practiced the IronRuby talk too many times, it didn’t go as well as I’d had hoped.

There’s the first sign I was going to have trouble, I hoped it would go well. The Kanban talk I knew would go well, not so much with the IronRuby talk. I had some time issues in preparing, had a number of other events I was was participating in, but none of that mattered to those people in the room with me in Knoxville while I did an under prepared presentation.

Here are three things you can do to save yourself the same fate I had in Knoxville.

1. Un-busy those slides!

Yeah, drop the bullet points, the animations, the cool stuff that PowerPoint or Keynote will let you do and just keep it simple. I mean, who’s telling this story? You or some software program that just needs you there to hit the “Next” button?

I was recently at a national/international level conference and a fairly well known speaker was giving a talk, but this person’s slides had all kinds of images and animations and bullet points. They had crammed so much info on each slide that a number of their headings were lost in the curtaining surrounding the screen. As an audience member I had a poor user experience, and I can’t recall the topic of the talk because I was so distracted by the horror that was on display in their slide deck.

Simplify. One image per slide is a technique I use often. Use that image to support what you’re talking about rather than BE what you’re talking about. Keep the animations low, one or two per slide is plenty. You don’t want to distract your audience, you want them listening to you.

The last point on un-busying your slides, I’m sure a few of you are thinking, “But when I upload my slide deck, nobody will know what the main points of the talk were.” That’s fine, put the supporting points to the slide in the speaker notes, then a downloader will have a good idea what you were talking about…in the presentation they should have attended. (Because you were that awesome!)

2. Practice, practice, practice!!

Give your presentation to the wall of your office a few times. Set up a few of your kid’s (or your own) stuffed animals and regale them with the wonders of TSQL. Give it to some colleagues in an informal lunch and learn. But, practice it a number of times. You want to be comfortable with the flow of the presentation and the points you want to make on each slide.

You can add speaker notes to help you through, and jog your brain on some points you’d like to make, but you want to practice enough that you’re comfortable to give a good talk without those notes. Because…

Let’s say – hypothetically – you own a MacBook Pro and an iPhone and you’re going to use the wonders of the Apple Corporation to help you give a presentation. You’re going to use the phone as your presentation remote and it’ll show you those bullet point, memory joggers mentioned above. And because it’s all Apple, all the time…IT’LL JUST WORK! But – again, hypothetically – something is wrong with the wireless network and for some reason the phone doesn’t want to connect to an ad hoc network on your laptop. What then? What of those memory joggers? The notes? Well, you will have practiced enough that this will barely even slow you down.

3. Practice those code samples

Yes, more practice. But with good reason.

Live coding can make or break you…it usually breaks me. I’ve bored enough people to tears with my live coding, that I rarely do it. I have some colleagues that are awesome at live coding demos. Somehow they’ve mastered the art of saying one thing and typing another. I don’t have that gift…just like I don’t have the gift of being able to hit a fastball, the gift 4.3 speed, or the gift a 103 MPH slap shot. But, I digress.

Practice those coding samples. I mean, as developers were in this to code anyway, just do the same code over and over so you can give the presentation without a hitch. I read a great line the other day, and though it applied to development in general, it definitely fits here: Novices will practice until they get it right, experts will practice until they never get it wrong. When it comes time to do a code sample in front of 40 developers, you’re going to want to be an expert.

That’s all there is to it

So, in review…

1. Keep it simple
2. Practice the presentation
3. Practice the code samples
4. And, um, have fun!

Yes, it’s a bit of work to put on a presentation. But when it comes time to deliver that presentation, the people watching you are giving up part of their day to spend with you. Respect those people and that hour of time of theirs that they’re giving to you.