Beware Your Buffering

In a twitter discussion that was centering around some Kanban joy, the point of buffering came up. I offered a bit of twitter-esque advice, meaning it was short, could be interpreted as terse, and lacked the detail it needed. As any good friend would do, Jim called me out for my 140 character bit of guidance.

So, in more than 140 characters…

Be careful with your queues on your Kanban board. (I say queue here, because a buffer is just the queue for the next step.) By definition, any queue is waste. It’s a step in the process where something is waiting, therefore value isn’t being provided to your customer.

Can queues be used effectively? Yes. Quite effectively, but you have to stay on top of them. In reality, there has to be some queuing going on to give a pull system something to pull. In practice, those queues need to be as small as you can keep them to keep things flowing.

My tweet that started this mess was that I’d been burned by buffers on more than one occasion. Here’s one nasty one where the queue wasn’t a help, it was hiding the real problem.

We had a project where our developers far outnumbered our testers. This isn’t an unheard of scenario in the world of software development, but we handled it badly on our Kanban board. We ended up with not one, but two buffers between the dev team and the QA folks. The true, root cause problem was we had a resource problem because we needed more testers. Instead, we masked it with some queuing.

The biggest problem was that we lost our short feedback loop from development to demo. Early in the process, we’d complete a feature and it would demo within a day or two. As the project progressed and the developers’ momentum took off, the testing team was backed up and the feedback loop grew. Bugs were sitting open longer, code complete features waited to be tested, and the churn began.

Our solution was to swarm the test queue to get it lowered. Having a dev or two help get some testing done got our backed up test queue fixed, but it put devs in a testing role which I’m not a big fan of doing. (Devs are notorious for making sure something works rather than looking for ways something could break.) Also, this solution was very temporary as the queue naturally filled back up once the dev team was back in high gear. The actual solution: add a testing resource. Our full queues told us that, but we didn’t listen too closely for a while.

In the end, some buffers and queues are inevitable in many situations. However, make sure to do the following:

1. Make them as small as you can, maybe half the size of the queue limit of the step that the buffer is feeding. Adjust as necessary, but don’t keep increasing it as it fills up.
2. If you need to increase its size, ask why a couple times to clear it up. If the answer is, “Because we need more room!” then look at the next step and see why it’s backing up your process.

So, back to what started all this…buffers can bite you in the butt as they tend to mask the issue rather than solving it. Make sure your buffers aren’t hiding a bigger problem.

Rails Study Apps

I’m trying to pick up some rails in my spare time. Been plugging away at my pet project when I can, which leads to a lot of googling while I do it. If one of my known Rubyist friends is at a Code and Coffee session, I spend a fair amount of time picking their brains and pairing up to learn what I can in an hour or so.

That all works pretty well, but at my pace I’ll be forever getting my Ruby code to look less like C# and more like Ruby. So, as Steve blogged recently, why not find a few Rails apps to read? So, I hit up my twitter friends: http://twitter.com/timwingfield/status/6464205602

I got three pretty good responses, and finally got time tonight to pull them down and take a quick look at them. I don’t have a lot of info on any of them, but I did browse the source to get a feel for what was going on.

Radiant CMS

http://github.com/radiant/radiant

This one was recommended by Dugald Wilson. Decent amount of code here to look at, and uses RSpec for the test framework. This one definitely fit the bill for what I was after.

Spot.us

http://github.com/spot-us/spot-us

I got this one as a tag team recommendation from Scott Walker and Matt Darby. This is a non-profit company doing Community Funded Reporting and is coming from the folks at Hashrocket. More RSpec out of this project, and again a fair amount of code to pour over.

Redmine

http://github.com/edavis10/redmine

The third one came through Ben Wagaman. This one uses TestUnit instead of RSpec, but still some decent reading. I’m going to have to dig into the tests a bit more on this one, though, because the file names aren’t jumping out at me as model/controller/etc type tests. But, that’s the point of this exercise, to see what other folks are doing.

I’ve got a little flying and a lot of driving ahead of me this weekend, hopefully I get some time to dive deeper into what each of these apps is up to, and get some more Rails code under my belt.

If you’ve come across a few more open source Rails apps out there, please drop a link in the comments.

ASP.Net MVC: A Step in the Right Direction

A link to Doug Copestake’s article “ASP.Net MVP: A Step Backwards?” was forwarded to me, and it made some short rounds on twitter. I read it and had a comment underway and thought, “This is WAY to big for a comment, let’s blog it!” So here we are.

Off the top, I’d like to give a tip of the hat to Doug for stepping outside his day to day and taking a look at ASP.Net MVC. It’s very easy to hide behind FUD and just blow off something different. Additionally, his initial findings are pretty much on par with most other folks happy with WebForms who take their first look at MVC.

The MVC framework definitely provides simplicity and separation of concerns to web development. It allows you to only write the code you need to write to get the job done, and it allows you to work with the framework. Views become very small and very specialized, controller actions mature to be very thin, and it’s all easily testable.

This has made my work with the MVC framework extremely successful. Since everything is easily testable, as we refactor the code to clean it up or add new functionality, it all flows very easily.

Control reuse comes from veteran WebForms developers quite often. But if we again point at simplicity, how many of those drag and drop controls were written to cover more functionality than you need? You drag a grid control out and use 15% of it’s power because its made for everyone. Yes, you can write your own application controls to do exactly what you want, but you can do that in MVC, too.

Another point to control reuse is the leveraging of more javascript frameworks to do many of the things that the WebForm control suites do. In jQuery UI alone, you’ll get tabs, accordion panels, sliders and other UI elements, all with out that “server side” part that is so prevalent in WebForms. The win there is in more than just lighter weight controls, you gain a much better user experience. (And who doesn’t like happy users?)

The spaghetti code point Doug makes is quite valid, though I think that’s not a factor of one framework or the other as much as it is the person writing the code. The Glen Vanderburg quote, “A bad developer will move heaven and Earth to do the wrong thing,” applies to all languages and frameworks. The person with the keyboard under their fingers is responsible for keeping their code clean, not the framework developers, but I digress.

Spaghetti code in the views is a big sign that you’ve done something wrong. Even before moving to Spark, if you see lots of server instructions in your views, it’s time to stop and think, “What can I do differently here?” Same can be said of your controllers. If you’re used to writing a 50 line page load method in WebForms, turning similar code into 50 line controller actions is a step in the wrong direction. I guess the main point here is instead of relying/hoping for the framework to do the work for you, the onus is now squarely on the shoulders of the developer to keep his or her code concise.

Doug’s last point is very true, though: if you have a lot invested in WebForms in your current situation, there’s no real reason to switch away from it. Switching for the sake of switching to anything usually isn’t a good move.

That said, you can easily run WebForms and MVC in the same web application. If you have a little something to add to the project that can stand on its own, I’d say a look at MVC is in order.

This definitely would have been too long of a comment… :)

ASP.Net MVC v. WebForms

This question seems to come up a lot in discussions around these two ASP.Net frameworks. Just this past weekend in Cincy at the MVC Firestarter, it came up a number of times.

So, on the way to work this morning, I was listening to Hanselminutes 184, and the question was FINALLY given an answer by Scott Hunter.

If you care about separation of concerns, testability and tight control of your markup you should go with MVC. If you’re an enterprise developer and just want to get something out there quickly then use WebForms.

That’s paraphrased, I may have gotten the MVC reasons in a different order, but that was the point made.

Scary that “Just get it done,” is the main reason to use WebForms. I’ll stick with my “slow” TDD and long term maintainability in MVC and steer clear of WebForms where DDD apparently stands for Drag, Drop, Deploy.

I forgot what the M in MVC was for

What brought me to this conclusion was my reading up on a little Rails. I finally took the dive. I’ve been avoiding Rails for a while in favor of just learning Ruby. Steve loaned me “Rails for .Net Developers,” and the research was underway in earnest.

On page 89, the light bulb went off. But not for Rails so much as for how I’m writing my ASP.Net MVC apps. Here’s the bit that got me:

• Models are the classes that represent your business domain and that are responsible for communicating with your data. In Rails, this means the tables in your database.
• Views represent your presentation layer, for example, HTML and JavaScript.
• Controllers are responsible for connecting the models and views and managing the flow of the application.

That reads pretty straightforward to me. Hell, I’ve stood in front of groups of devs on more than one occasion and said, “Views are what gets rendered, controllers marry up the views with anything they need from the model, and the model is everything that’s not a view or a controller.”

So, what’s been going wrong? I’ve been putting way too much business logic in my controllers.

The structure of most of the MVC apps I’ve worked with is a typical .Net program structure. We’ve got a core where our business domain lives, and some type of ORM set up to talk to the database. From there, we expose that domain up to the UI through some simple domain services.

The issue comes when I consume those services. I’m using my controller actions to marry all that up and present it to the UI. I think my “excuse” to this point has been that I have two models: My domain model, which I’m accessing through my domain services, and my presentation model, which lives in the Models directory in the ASP.Net MVC structure. My controllers have to care about two places to get their information to provide to the views. At the least I’m violating the pattern and at worst I’m likely repeating myself somewhere and creating a future maintenance issue.

I think I can see where this happened, too. Think back to the Bad Old Days of dealing with Web Forms, and the cubby code behinds that came with it. In order to avoid the 197 line PageLoad method, I would have a lot of little one-off methods scattered about the code behind file. Switch over to MVC, and it seemed perfectly normal to have a similar structure. Alarms should have gone off when I had 5 classes in the Models directory but 18 methods in one controller class.

But wait, there’s more!

While perusing some code on my current project, I came across the [NonAction] attribute decorating a couple of controller actions. Re-reading that…I had NonAction decorating Actions. That has a certain “Jumbo-Shrimp” feel to it, doesn’t it? I suppose the non-action could fall under “managing the flow of the application” from above, but I’m thinking any non-actions might need to be refactored into the model.

Moving forward on my MVC apps – of any flavor, Ruby or .Net – I think I’ll move to a much thinner controller model in favor of loading up the model with business logic. Though I thought I knew the pattern fairly well, I didn’t practice what I preached.

Kanban At XPUserGroup – July 29

This is a bit short notice, but I just found out about it last week. (Thanks to Kevin tweeting about it. :) ) But, I’ll be presenting my “A Little Bit of Lean with Kanban” this coming Wednesday for the XPUserGroup here in Columbus. The meeting will be at OCLC at 11:30, I’ll begin my presentation at noon. (Directions and room info at OCLC.)

I didn’t plan on doing much speaking before leaving for vacation on August 1, but here’s one more session on Kanban. We really can’t spread the word enough about Kanban, so why not give one more a few days before I head south?

I’m also giving a short presentation on the 7 principles of Lean Software development next week…but you have to be an employee of Quick Solutions to see that one. (Get hired by Tuesday to see it! :) )

CodeStock Recap and Kanban Talk Slides

I had a great time at Codestock this past weekend. I didn’t get to many sessions, but I did go to a number of open space sessions (have some work to do on my blog) and the normal “hallway” sessions that never disappoint.

My talk on Lean and Kanban went really well. There were only a couple seats left in the smallish room we had, but that lead to a much more interactive discussion. The slides are available to download, with some notes in the deck.

To answer a couple more questions from the group, here are a couple of the resources I mentioned in the talk:

• Core Ladas blog: http://leansoftwareengineering.com/
• Implementing Lean Software Development by Mary and Tom Poppendieck

Coming soon will be Agile Zen. I’ve taken a peek at the beta, and it’ll be quite a tool in helping people and teams do lean development. Sign up for their mailing list to get notified when it comes out.

IndyNDA Recap and Covering the ModelBinder

I want to thank all that attended my MVC presentation in Indy last week. I had a great time speaking, and even though I left a portion of my code sample out (model binders, which I’ll cover below), I thought it went well and I got some good questions during and after. I apologize for leaving it out of the talk, but I get to write a little blog post about it.

A couple housekeeping things before I cover the ModelBinder part I missed.

Off the top, the slides and source code from last week are all zipped up for your downloading convenience. (The code through SVN is also available on Codeincubator.)

During the post talk talking, Dave asked me about a grid option in MVC. One we’ve been using is Flexigrid. It will do paging and sorting on its own, and will call back to your controller on its own for a little JSON. The big gotcha here is it runs on an older version of jQuery, which bit us in the butt on Friday on our project.

The blog post that contains the code and explanation…well better explanation than, “I copied and pasted and it worked,” on the partial views is on Steve Sanderson’s blog.

Now on to the part I forgot…

ModelBinder

I’m still feeling bad for not sharing this part. I got a question about it after the presentation, and that’s when I realized I totally forgot the edit page, which was going to demonstrate the ModelBinder. (Among other things, like the FluentHTML controls.)

If you have the code form above, the files in play here are InventoryController.cs and Edit.aspx. AssaultItemEditModel.cs is the object passed, but it’s just a property bag.

For the Reader’s Digest version: the ModelBinder works on the premise of convention over configuration, so the naming of your fields matter in that they have to match the property names of the object you want to bind to.

For the example I missed, we had the edit model that we wanted to bind to:

public class AssaultItemEditModel
{
    public virtual int Id { get; set; }
    public virtual string Type { get; set; }
    public virtual string Description { get; set; }
    public virtual int LoadValue { get; set; }  
}

The view had the form fields hooked to that edit model through the Fluent HTML controls from MVC Contrib.

<% Html.BeginForm("Save", "Inventory");%>
    <h2>Edit <%=Html.Encode(Model.Type) %></h2>
    <%=this.Hidden(x => x.Id) %>
    <ul class="details">
        <li><span>Type: </span><%=this.TextBox(x => x.Type) %></li>
        <li><span>Description: </span><%=this.TextBox(x => x.Description) %></li>
        <li><span>Load Value: </span><%=this.TextBox(x => x.LoadValue) %></li>
        <li><%=this.SubmitButton("Save") %></li>
    </ul>
<% Html.EndForm();%>

And finally, the controller method that’s going to process it all. Rather than taking in the standard id, it takes in a model object to which it will do all the Request.Form for you and hook the form values up to the object properties.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Save(AssaultItemEditModel item)
{
     //do save
     var assaultItem = new AssaultItem(item.Id)
         {
             Description = item.Description, 
             Type = item.Type, 
             LoadValue = item.LoadValue
         };

     Service.SaveAssaultItem(assaultItem);

     var message = "Item saved successfully.";

     return this.RedirectToAction(x => x.Index(message));
}

Don’t mind my extra step on newing up an object with the id as a parameter, that’s due to the way I hooked up Fluent nHibernate at the start. Basically, to generate my maps from my domain objects, the id gets a private setter as convention. So, to get the right object to save, I had to set up the constructor to take an id argument. I cut some corners to get the demo app out the door. (John, you may hit me with, “Quicker does not equal better,” as soon as you read this.)

The other way around that is to not use my domain objects in my views, but that’s another discussion.

Under the hood where the magic happens, I haven’t dug too deep. But, I use this daily and it works swimmingly. You don’t even have to take in the model the view is bound to, just have the form fields match the model you’re taking in. I don’t recommend doing ad hoc model binding, in practice we set our edit model as a child of the view model.

I feel bad that I didn’t get this up on the screen, because it’s some fun stuff to show off.

Now Batting Leadoff for CodeStock…

I am honored to have been selected to speak at CodeStock and will be delivering having my Kanban conversation in the great state of Tennessee. I’m really looking forward to this as I didn’t make CodeStock last summer, and it looks like a great two day event. The good folks that have organized the conference have slotted me in one of the opening sessions on Friday, so we’ll get our Lean on early in the conference.

There are a number of sessions I’m looking forward to, and since mine is over early I should get to a bunch of them. But, as with any regional conference, I’m looking forward to the hallway sessions as well.

If you’re thinking about going, go get registered, it looks like it’s going to be a good time.

“But WebForms did that FOR me.”

While working with the model binder the other day, the statement in the title was made by one of the guys on my team. It’s not an unreasonable statement, but I think it spells out an important distinction between traditional ASP.Net WebForm development and using the new, shiny ASP.Net MVC framework.

The point in question was in posting an object after edit, the id didn’t automatically come through. The model binders do some magic under the hood, and it’s welcome magic in my opinion as I’ll gladly leave Request.Form back with Classic ASP. However, you still have to tell the model binder the whole story, it’s not done for you anymore. (Nor was it done for you before WebForms.)

Solution to our little problem: Stash the object id in a hidden form field. (Yes, I know, right click and view source and there’s my object id.) Once looked down upon in WebForms development…well, other than that one GIANT hidden form field called “ViewState”…the hidden field looks to be making a quiet comeback.

Basically, if you want the model binder to find all the bits to your object, you have to make it available when the page posts. So, it needs to be in the form somewhere.

Personally, I don’t see this as a step backwards, but I grew up in the salad days of request/response. Having to provide that info so you can get it back seems normal. The flip side is also true: if you don’t need it, you don’t have to add it.

The more I work with ASP.Net MVC, the more I fall in love with it.

Back to Indy for NDA

A few weeks back, I made my first trip to speak in Indy at the Indy Code Camp. I had a great time, met some new people, and got invited back to speak at IndyNDA on ASP.Net MVC.

So, this Thursday, June 11, if you’re in the greater Indianapolis metropolitan area and want to learn a little MVC, then I hope to see you at IndyNDA.

Presenting in Findlay this Tuesday

I can’t believe I didn’t get this blogged sooner: I’m presenting “Care About Your Craft: Adventures in the Art of Software Development” in Findlay this coming Tuesday, May 19th.

I’m looking forward to heading up to Findlay for this. I met a few of the FANUG guys at Indy Code Camp this weekend, so I’ve got a few hecklers already primed.

Indy Code Camp Recap

For the first time in my short speaking career, I stepped over my imaginary Microsoft Line and out to another region…alllll the way to Indianapolis. I’ve driven to Memphis to talk, and stay in my region, but never the whopping 3 1/2 hour drive to Indy to see the good folks over there. After this trip, I think I’ll step over the imaginary line a few more times.

First, a big thanks to Dave Leininger for putting on a great event. There were over 200 people at the event, and it seemed all were enjoying themselves. Dave drew speakers from 5 states for the Indy Code Camp, so tip of the hat for getting the word out.

The hallway sessions are always good, but I missed out on a few running Jeff to the airport and back. (And not finding the airport right away didn’t help.) But even with my limited hallway track time, I still met some new folks and talked shop with some familiar faces.

I’m already looking forward to my next foray over the imaginary line that is the western border of Ohio. (Maybe a trip east is in order? :) )

Code and Coffee

After a great day at Kalamazoo X, and a conversation with Mike Wood about his Bitslinger idea in Cincy. Jeff and I had a few hours in the truck headed south to work out something for Columbus, so Code and Coffee was born.

OK, we hatched the general idea…meet at a coffee shop on Thursday mornings, write code. I came up with the name and bought the domain. :)

The idea is straight forward: Show up at our coffee shop of choice, bring a laptop, pair up, and have fun writing some code.

Check out http://codeandcoffee.info/ and join us if you can.

CODoDN Follow Up

First, big thanks to everybody that attended my talk on Kanban at Central Ohio Day of .Net. It was a lot of fun talking with everybody, no matter how many times I got side tracked.

The first request from the talk was a link to Corey Ladas blog. Corey has some great stuff in there, but start with the scrumban post.

Here are my slides. The slides themselves are just to support the talk, but there are notes on each slide.

Two Talks at Indy Code Camp

I am honored to have been selected to give not one, but two talks at the upcoming Indy Code Camp on May 16th.

I'll be presenting Care About Your Craft: Adventures in the Art of Software Development, and A Little Bit of Lean With Kanban. Both these talks are a lot of fun and get good audience participation, so it should be fun.

The Indy Code Camp is typically as much code as you can crank out, and they have a max of 3 slides request for most talks. But, I'm in Track Five: Beyond Lines of Code...which is a good thing, as both talks have way more than 3 slides, and 0 lines of code.

What I'd Do Different

In my last post I mentioned a few things I'd like to do differently in my next new dev project where we utilize Kanban. I sat down with our PM, Elizabeth, and we did kind of a mini-project retrospective, and what we could do differently from the Kanban side of things to help things flow along better.

The first thing we thought would help would be to get better info on the cards, and to treat the cards as Minimal Marketable Features. Across the top of the card we'll put the feature number, name, and its time estimate. In the middle of the card, the description and any task breakout that's needed. Across the bottom we'll stick with the WIP start and end dates, and the cycle time will go between them once it's complete. The back of the card we'll put actual developer and tester times, and then once complete total that and put it on the front of the card under the estimated time.

This will accomplish a few things for us. First, on the dev side of things, it gets that task card breakout thing out of the way and allows us to track the features across the board as a single entity. Secondly, it gets more project management info clearly on the dev card, which makes it much easier for people not knee deep in the project daily to keep tabs on what's going on.

The second thing we thought should be implemented the next time around is an extension of the board, to the left. Our board for this one had a bullpen column where features were in holding waiting for the tasks to breakout. From there, they moved into the backlog, and into work in progress.

Our idea here is to break that bullpen column out into another Kanban section where discovery, design, and estimation takes place. Once that is complete the feature can wait in a "Ready for Dev" status and be pulled into the backlog column on the development Kanban board when the set trigger point is hit.

Elizabeth and I went back on forth a bit on where the bullpen board would reside. Initially I wanted to see it isolated from the dev team so they could concentrate solely on the dev tasks at hand. However, Elizabeth's persuasive abilities (strawberry cake with white icing may or may not have played a role here) led us to the conclusion that it should all be one board. This allows the developers to be aware of what's in the pipeline coming at them, lest they relax a bit too much at a critical point in the timeline. And, it allows the dev side of the board to pull from the bullpen as features are estimated and ready to go.

Finally one last thing we thought we'd employ would be different sized cards for different sized features. If we can't get all features to breakout into a similar estimate range, which is a very real possibility, then maybe get two or three ranges and denote them with different sized cards on the board. This would allow for different cycles to be tracked based on feature size, and a quick look at the board would tell you what type of features are moving through the system at any given time.

I think these changes to our approach will help the next new dev project where we employ Kanban. We used it successfully before, but I think this will help get more features into done with less friction for the whole team. Which means cards will get put in the envelope above this lovely lady's picture in a shorter cycle. (Whiteboard drawing courtesy of Dan Shultz.)

Kanban Lessons Learned

After seeing success with Kanban in a production support environment (part 1, part 2), we decided to give it a try in a new development situation. This project was a mix of new development and working with an inherited code base to implement some existing features differently.

Because of this situation, we ended up with a mixed bag of features. At the onset, we decided to break these features out into tasks, and we would track both across our Kanban board, as shown here with a snapshot of our Work In Progress section.

Features were broken into tasks and grouped together in the backlog. Once a feature went into WIP, it's tasks moved below into the Task Breakout section and were worked there. Once all tasks were completed, they were once again compiled back into a feature and went into test as a whole.

What we tried to accomplish here was to keep the concept of a MMF while still breaking the work into smaller, more manageable units. What ended up happening was that features themselves became secondary to almost full task development, however we were tracking features through the system for our cycle time. Early, heavy task features that focused more on the business model skewed the cycle time higher, and later UI tweaking features sent it lower. As such, our cycle time diminished quickly as the deadline drew near...a good thing, but I don't think it was totally attributable to the team's momentum.

I think we failed here in poor estimation of what lie in front of us when we started. A good bit of this is the situation we were in at the onset where we were under pressure to start getting things moving right away, and we didn't give much credence to estimating later features very well. That wasn't really a Kanban issue, and we should have known better. The excuse is we had very little time to ramp up on the discovery side of things when we got the project, but it would just be an excuse...we should have known better.

One final area where we had some issues was in reporting where exactly we stood in features completed. We were fairly visible on this project, and had a lot of interest in our success by the due date. (OK, what project doesn't?) While you could look at the board and see what was being worked at any given point, due to the lack of good feature estimation up front, it was hard to see where we were in the big picture. In the latter half of the project we stole ourselves a project manager, and she did a bang up job of getting that information worked out, but she did struggle in figuring it out. Again, I think she had trouble due to the lack of good estimation up front.

It wasn't all pain and suffering as we moved our cards across the board.

One good thing we got out of the board was it was easily changed to fit our constantly changing team size and make up. We started out as three developers, and ended as four developers - two different than the original three, one PM, and one QA person. Being able to walk up to the board and change the queue limits on feature WIP, task development, and features in test made things flow quite smoothly as the project moved along. It did a good job of identifying a few roadblocks and getting them out of the way, as well.

As noted earlier, our cycle time did drop as we neared the due date. Part of that was due to the smaller features coming through later, but there was a good bit of momentum on the dev team, too. Morale stayed fairly good as we kept moving things into the done envelope at the right side of the board.

I still think we were successful with Kanban in this situation, but clearly I think we need some refinements around how we did it on this project. I'll save those ideas for my next post.

"Houston here. We're looking for somebody to blame for your problem, 13."

Fix the Problem, Not the Blame
It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.

--The Pragmatic Programmer

I highly doubt that was the response to Jim Lovell after the line, "Houston, we have a problem." However, in our world of software development it still seems to be the first reaction to any issue that comes up.

I know in projects past, I've been a huge offender of looking for, "It's not MY fault," rather than fixing the problem at hand. Todd even nicknamed me Blameosaurus on one project because I got so good at looking for the blame. So, I'm not exempt from my own post here.

I've been a consultant for one company or another for over ten years now, and we're constantly thrown into burning buildings to get something working. There are a plethora of issues on day 1, and all too often those of us on the team spend too much time bitching about the issues and not enough time rolling up our sleeves to get things squared away. So, day 2 rolls around and we're in the same boat, and the same problem still exists.

That said, sometimes there is a right time to track somebody down that created a problem. Don't do it as a way to shame them, but rather for more clarification. Who knows what the situation as like at the time they made the error, and maybe it's a good time to help somebody learn something new.

I feel I'm still an offender of whipping out the blame thrower a bit too often, but I'm making a conscious effort to quit and move on with the solution.

Some April Kanban Talks

I'm happy to have been selected to two conferences in the region to share an hour or so of Kanban, and my experiences with it.

The first will be at Central Ohio Day of .Net on April 18th in Wilmington. This is a great little conference that combines the forces of the dev communities of Dayton, Cincy, and Columbus for a day of geeking out. In addition to the great sessions they have lined up, there will also be Open Spaces. If you've got time on a Saturday in the spring, this is a great gathering at a great price...free!

The following Saturday, April 25th, I'm going to trek north and present at the Kalamazoo X conference. This is the first year for this conference, and it looks really interesting. It's focus is on the non-tech side of development, so there will be lots of dev process, design, and user interaction type talks. All the stuff we need to know without opening up our favorite IDE. As an added bonus, this place is in Kalamazoo for a required stop.

That will keep a couple Saturday afternoons busy in April for me. Now, if a certain local hockey team can keep the Saturday evenings busy...

COALMG Kanban Talk Follow-up

I would like to thank everybody that attended my Kanban talk at COALMG on March 5th. There were some great questions, a good discussion, and judging by the tweets on Twitter afterward, it got some wheels turning. I'm glad the talk got some of you thinking about things you can look into.

As promised to Jeff, here are my slides: A Little Lean With Kanban.

The disclaimer on the slides: They meant to support the presentation (I have totally bought into the Presentation Zen approach to presenting), so on their own they don't say much. However, my notes to each slide are there, and that should provide some value. Also, even though I used pptPlex for the presentation, if you don't have that they'll still work fine in Power Point.

Also, I love feedback. That was the first time I gave that presentation in that form, and welcome any suggestions you may have. I already got a few from Comrade, James, and Amanda over post-talk beers that will be folded in to the next iteration.

And all you guys named Jeff that bailed on the post-talk beers...for shame!

A Weekend With pptPlex

Some time last fall I believe, Jeff introduced me to pptPlex from Microsoft Office Labs. It does some pretty neat tricks with your slide deck. To me it appeared to be Deep Zoom for Power Point. (And let's be honest, anything to spice up Power Point is a good thing.)

So, I've got a new presentation to put together, and thought now would be a good time to give pptPlex a try. I wasn't disappointed, it does make moving through your presentation more fun. To get it to work there are a couple special slide types it uses, and a different way to launch the deck, and that's about it.

The first special slide is the section divider slide. It has a title and some grayed out text on it. You drag it into the deck at the point you want a section to start, add the title, and done. That section will exist until pptPlex finds another section divider slide. This groups your slides by however you'd like, and applies the title from the section divider slide to that group.

The second special slide type is a canvas slide. This slide ends up being the canvas for the whole presentation. There are a few pre-made ones you can use, and also two custom options. Basically, the layout you choose determines how your slide groups are arranged on the canvas. I ended up using the advanced custom option, which wasn't too hard to lay out. Lots of typical dragging and dropping to get the layout like you want it. Took maybe 10 minutes to get my six sections all set up like I want.

Both the section and canvas slides appear on the new pptPlex portion of the ribbon. Also on that menu are the new options for launch that will start your presentation up in pptPlex mode rather than in traditional Power Point mode. The first of "From Overview" is the one that will start your presentation from the canvas, and is the one I think most people are going to use.

Now for the downsides I ran into...

First issue I came up with was that it didn't work with my presenter mouse. I've got the Microsoft Wireless Notebook Presenter Mouse 8000, and no dice with it doing anything in presenter mode. A little searching on the web turns up that pptPlex doesn't yet support that mouse. HOWEVER! It will support use with a Wii remote and an xbox controller. +1 to each for cool factor, but I'm trying to be practical here and still give a presentation.

My solution to this ended up being mapping the two side buttons on my mouse to the left and right keys on the keyboard. It's not the ideal solution, but it will cover 90% of what I'll need to handle during a presentation. There will be a couple of gotchas with this, but it should get the job done.

The second issue I came across was that once you've published your slides to the pptPlex output, you lose all your animations. I don't use animations a lot, but a couple places they would have come in very handy for effect. However, the pptPlex FAQ lays out that they just didn't have time to get that in for this release. (Yo, MS, add one more guy to the team and task him with mouse integration and animation!)

Overall, I'm digging the product. I think it'll help with a lot of my presentations, and I'll probably refactor any of my old ones to use it. The cool factor it brings makes the above two hurdles tolerable.

Besides, a sensor bar and a bluetooth card form my laptop will have me running a Wii controller in no time!

Goals for 2009

I got tagged by Jeffery back in January for this, and since there's nothing I should do today that I can't put off until tomorrow...

Professional Goals

1. Speak 12 to 15 times: I spoke 12 times last year, covered three different states, and had a heck of a time. Why no big increase here? Because realistically speaking (pardon the pun), that was plenty with everything else that goes on with job and family.

2. Present "Care About Your Craft" at least 5 times: I gave this one a couple times last year, and would like to give it more. It's a great talk that covers a lot of things developers can do outside of their syntax of choice to be better developers.
3. Upgrade the MVC talk and samples: When I wrote my goals out at the beginning of the year, I put this one on here because I'm a little behind on my MVC. But this week, I started in on a project that was going to leverage it, and found out just how far behind I am. So, I'm already underway on achieving this goal.

4. Create a new presentation: This one will be taken care of thanks to being invited to speak on Kanban at COALMG in March. (I've procrastinated this post long enough that one goal is reached! w00t!)

5. Write a sample app in Ruby: I need to work on my Ruby some more.

6. Contribute to an open source project: I need to do this, as well. Need to find the right one to contribute to, though. Maybe combine this with goal #5.
7. Get the blog better organized: Had this one on the list for a while, but I keep putting it off. Should I install Grafitti? Should I just run with Blogger? I need a new design no matter what engine I use. Thankfully, I've got a few friends who are willing to help out on all points, should be fun.
8. Write 35 blog posts: 3 posts a month should be doable. Though it's already February and I'm behind my pace.
9. Read 12 books: A book a month...like above, I'm aleady behind. On my list, though, are to re-read the Pragmatic Programmer, finish Implementing Lean Software, and to get through Uncle Bob Martin's Clean Code.

Personal Goals

1. Fix my office to be more usable: Wendy and I don't have the best layout to our home office, and we both need a little space of our own in there.
2. Get better lighting in our basement: We have two choices for lights during movie watching - harsh flourescent lighting, or none at all.

3. Budget our vacations better: We've got two trips planned already, and we tend to say, "Screw it! We're on vacation!" when we go to buy something while we're out seeing the world. (Usually Disney World.)
4. Clean up our finances: I'm waiting for a year when this ISN'T on my list of goals.
5. Lose weight: Like #4, I could use a year without this one on the list. Thankfully I'm starting '09 lighter than I was in '08, but could still drop a few more pounds.

Speaking at COALMG

I have been selected to present on Kanban to the Central Ohio ALM Group on March 5th. This will kick off my 2009 speaking tour, and I get to open it with a new talk on Kanban. I'm really looking forward to this talk because I've seen the advantages of Kanban first hand.

So, if you want to learn a little about Kanban, what it is, and how to get started with it...or if you just want to heckle me...drop by the Microsoft offices on Polaris Pkwy March 5th.

Codemash 2009 thoughts

Another Codemash has come and gone, which means there are more than a few recap posts out there, so I'll add mine to the pile.

The biggest take away for me this year was the sheer number of people I got to talk to, shake hands with, and bend an elbow with. In past years, that group has been basically limited to the other Quick folks that were up there or a small circle of people outside of Quick that I knew. This year, though, that number was much larger. I can easily attribute this to two things.

First, I got out and about in the community more in '08 than in past years, including a few speaking gigs around the region. I got to hang out for extended times with new colleagues from Cincy to Grand Rapids and a lot of places in between. That made for a lot of familiar faces while strolling around Kalahari.

Second, and this is probably the larger of the two: Twitter. I started in on Twitter last year after Codemash and before I headed to Mix, and it showed at this year's edition of Codemash. The number of people I could talk with in person because we'd had a few conversations on Twitter made starting those conversations much easier.

For the content itself, I was really impressed with the Pre-Compiler. This was the first year for the extra day, and I wish they'd have spread that material over the whole conference. I found myself wanting to be in three places at once on Wednesday. I ended up with a morning of Ruby with Joe and Jim, and an afternoon of Lean and Kanban with Dave Laribee.

For the full conference, I was all over the place. Some open spaces, some sessions, some hallway conversation, some recovery time that we don't need to discuss here, etc, etc. I took in Venkat's second session (skipped the Scala one), made sure I saw Mary Poppendieck, saw Laribee's DDD talk, and a few others.

Open Spaces I was really looking forward to on the heels of all the news from DevLink and what Alan Stevens did down there. I got to two, one on pair programming and one on branding yourself. I submitted one, but thanks to the snow and the room changing a couple times my turnout was five other people from Quick. We decided we could cover this at another meeting and headed back out into the sessions. So, overall I was a bit let down with the Open Spaces, but I think good content in the sessions combined with good content in the Open Spaces makes for some tough choices. Alan runs a slick Open Space, though. The ceremony is kind of cool. [Insert essence v. ceremony joke here]

My mini-speaking part in the show was when Jon Kruger, Steve Harman, and myself gave some first hand experiences with Kanban in the QSI vendor session. We ended up with a decent turnout and went 10 minutes over our allotted time taking more questions. I thought it turned out really well.

So, another Codemash behind me, and another kick in the butt to start the new year. Top of the list, clean up the blog. In the branding open space I learned that using the default theme from .txt turns people off...thank goodness I use the default blogger theme, instead. I'm going to get Graffiti installed and get a better look for it.