Winging It

Speaking at Lean Software and Systems Conference

noreply@blogger.com (Tim) — Thu, 18 Feb 2010 02:22:00 +0000

I am more than honored to have been selected to speak at the Lean Software and Systems Conference in Atlanta in April. I’ll be presenting an experience report on my projects using Kanban over the last year and a half.

The presentation will obviously focus on my experiences, so very little theory or how-to about Kanban here. Given the subject of the conference in general, there probably isn’t a big need for a how-to on Lean software, anyway. So I’ll share successes and failures, and the collaboration with other members of the team to improve the process for different projects.

If you’re in the greater Atlanta area April 21-23, try to get to this conference. Many of the innovators in Lean Software will be speaking and there will be a significant number of people applying this in the real world. I’m almost as excited to be attending it as I am to be speaking at it!

Setting Job Change Goals

noreply@blogger.com (Tim) — Tue, 12 Jan 2010 13:30:00 +0000

Having just gone through a job change, I thought about sharing one of the bigger aspects of my job search process. When this process started for me – and don’t be fooled, it is a whole process and not one taken lightly – I set four base goals that my new (or current) employer had to meet.

I was given this idea while listening to Ken Auer speak at SCNA this summer. Ken was telling of when he decided to start his own company and one of his mentors said, “Set four goals for yourself, and only one of them can be monetary.” That hit home with me at the time: only one can be monetary. It was simple, and in regards to your career plainly obvious, but actually hearing it made it hit much harder.

1. Can I effect change?

I’ve spent the last 5+ years living agile development and working with XP development practices. I’ve been involved with Book Clubs and started Code and Coffee. I’ve picked up four different build servers, enjoyed development in ASP.Net MVC, and done a cannonball into the Rails pool. Can I take all this knowledge and use it for good instead of evil? Can I get a new organization on a path of continuous improvement?

2. Will I get to continue to push Agile/Lean and work with good technology?

I’ve put a lot of time into Lean and Kanban over the last year and a half. Both learning it, molding the process on various projects, then speaking about it to about anybody who’d listen. I want to keep on that course, because I think I’ve only started to scratch the surface of what Lean can bring to an organization.

Additionally, will I continue to get to work with cool technology, or better, be involved in the decision making process on what technology we’ll use? The phrase, “Right tool, right job,” means a lot to me.

3. Cool people to work with.

I don’t want to be a one man dev team as the member of a one person dev team is never wrong. I want to be around people that I can continue to learn from, that will push me as much as I can (hopefully) push them. And, I want to have fun. It seems simple, but for many years of my IT career it hasn’t felt like work because it’s fun doing the job I do. A lot of that has to do with the people I’ve worked with in the past.

4. $$…can I get what I’m worth?

One of the four has to be about money – I don’t do this for free, after all.

Market value was one of the toughest things to determine. Different people value different skills at different levels. If you’re in the consulting game, you have to have a salary that your bill rate will support. And the downward pressure on bill rates the last year is no great secret.

The unspoken goal – family time.

This is one I never put on paper because it’s the first thing that concerns me while thinking about anything with my job and my career. I’ve been extremely lucky to have a wife and two boys who have supported me as I started speaking and being gone more weekends with code camps, give camps, and conferences. So, the length of the commute to any office becomes a big deal. In an interview don’t hit me with, “We have a mandatory 45 hour work week,” because you’re taking almost another day per month of my time away from my family.

If you’re in a position where you’re starting to poke around to see what might be next for you, take the time and spell out what you want. Talk it over with your significant other, with some close friends, and forge ahead. Writing it down makes you stop and think about where you really want to go.

At least it did for me.

Career.Next

noreply@blogger.com (Tim) — Thu, 07 Jan 2010 13:30:00 +0000

When you start a new job, that first day is one of the most exciting you have while you’re there. You’re busy getting settled in, meeting new people, learning new ways of doing things, and eventually fitting in and finding your place. For me, that day was June 21st, 2004 and the new company was Quick Solutions Inc.

However, on that first day, you don’t start thinking about when the last day will be. But with most careers that last day on a job is out there somewhere. Eventually your career leads you on to something new, something more challenging, maybe something you never expected back on that first day. That’s exactly what has happened with me, and that last day at QSI that I never really expected will be January 8th, 2010.

To say I appreciate the opportunities granted me while I was at Quick would be a rather large understatement. I’m still in awe of some of the people I worked with over the years at QSI. Most everybody assembled in our app dev group was extremely talented and extremely passionate about technology, continuous improvement, and sharing what they knew. It was exciting to go to work most days because of who was going to be sitting at the desk next to you.

So what is next? I’m off to Reflex Design & Technology to help them build a development team. Actually, on day 1 I’ll BE the dev team - Lord help them. I’m more than a little excited to be stepping into this role with them. (Yes, if you’re doing the date math in your head, I’ll be at Reflex for two days then I head for Codemash.)

Again, many thanks to the folks I worked with at QSI. There’s no way I’d be ready to step into the role I’m taking without all that I’ve learned from all of you over the last five plus years.

I’m sure at this point many of you are asking, “Why did he leave?” That’s not easy to answer. It’s a very long and complex process I went through to arrive at this decision. But, I managed to sum it up in just two words…

Lotus Notes

Five Days with My MacBook Pro

noreply@blogger.com (Tim) — Sun, 03 Jan 2010 19:00:00 +0000

With a few changes headed my way in the coming new year, it was once again time to get some new hardware. I took the leap and opted for a MacBook Pro. (2.66GHz/4GB/320GB/15” so not the biggest, baddest one.) Here are a few of my initial leaving-Windows-and-Dell thoughts.

I can say after five days that I’m pretty sure I made the right move. There are a few things I’m struggling with in the switch, mainly my fingers going to the correct keys. Years of hitting CTRL on a windows keyboard has me hitting the fn key on the MBP, which doesn’t do much. Getting used to the Command key will take some time, but the oddest keyboard issue I’m having is hitting the B key. The reach is apparently shorter because I’ve put a lot of spaces where there should be a B.

On the flip side, it didn’t take me very long to get used to the multi-touch functions on the track pad. Having an iPhone doesn’t hurt, but the two, three, and four finger operations didn’t take long to become comfortable with. Scrolling through blog readers, articles, and Tweetdeck is a lot easier.

Installing applications is a lot easier, and a lot quicker than on Windows. To be fair, I haven’t installed a lot of huge apps, but the fairly large ones I did install went really quickly. The only real side-by-side comparison of installation I have is Tweetdeck, and it was a fraction of the time getting it up and running on the Mac. Most apps are just download, mount the image, drag to applications, unmount the image, and run it.

Now on to one of the bigger reasons I was after a Mac: Ruby on Rails development.

Rails on Windows was painfully slow at times. I tried all kinds of stuff to get my specs to run in less time than it took me to go downstairs and brew a cup of coffee. After copying the git repo of one of my sample apps over, I ran the specs and it reported .7-ish seconds. And it actually WAS .7-ish seconds. Not the 45 seconds of dead time at the command prompt while it fired up servers and stuff then reporting .7-ish seconds when it was done with the tests that I was used to. I’m already looking forward to doing some more of this.

Before I start sounding like a total fan boy, it hasn’t all been awesome. There was a 2 hour fight with an iso and some printer drivers to try and get my printer at home to work. Still haven’t got it to work, so I gave up and grabbed Brendan’s netbook to print off what I needed.

I’m also not enthralled with only having 1440 x 900 resolution. But, I’m getting old and my eyes would get tired staring at the hi-res Dell I had before, so maybe I should not worry about this one too much.

Also, couldn’t find any decent blog writer that lived up to Windows Live Writer, so this is being written in Live Writer in my Windows VM. (Bootcamp + VMWare Fusion + Win7 is freaking awesome. Looking forward to some .Net dev when I get Studio installed.)

Suffice it to say, the positives out weigh the negatives so far. I’m sandals-to-work away from swallowing the blue pill with the Apple logo on the side of it. :)

Beware Your Buffering

noreply@blogger.com (Tim) — Wed, 23 Dec 2009 02:30:00 +0000

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:

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.
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

noreply@blogger.com (Tim) — Thu, 10 Dec 2009 13:30:00 +0000

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

noreply@blogger.com (Tim) — Sat, 14 Nov 2009 17:47:00 +0000

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

noreply@blogger.com (Tim) — Wed, 21 Oct 2009 13:15:00 +0000

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

noreply@blogger.com (Tim) — Mon, 31 Aug 2009 12:00:00 +0000

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

noreply@blogger.com (Tim) — Sat, 25 Jul 2009 00:00:00 +0000

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

noreply@blogger.com (Tim) — Fri, 03 Jul 2009 16:00:00 +0000

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

noreply@blogger.com (Tim) — Tue, 16 Jun 2009 12:00:00 +0000

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…

noreply@blogger.com (Tim) — Thu, 11 Jun 2009 00:39:00 +0000

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.”

noreply@blogger.com (Tim) — Mon, 08 Jun 2009 12:00:00 +0000

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

noreply@blogger.com (Tim) — Sun, 07 Jun 2009 13:00:00 +0000

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

noreply@blogger.com (Tim) — Mon, 18 May 2009 03:00:00 +0000

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

noreply@blogger.com (Tim) — Mon, 18 May 2009 00:00:00 +0000

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

noreply@blogger.com (Tim) — Tue, 28 Apr 2009 12:00:00 +0000

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

noreply@blogger.com (Tim) — Sat, 18 Apr 2009 16:50:00 +0000

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

noreply@blogger.com (Tim) — Fri, 10 Apr 2009 12:00:00 +0000

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

noreply@blogger.com (Tim) — Thu, 09 Apr 2009 12:00:00 +0000

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

noreply@blogger.com (Tim) — Tue, 07 Apr 2009 02:13:00 +0000

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."

noreply@blogger.com (Tim) — Tue, 24 Mar 2009 18:22:00 +0000

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

noreply@blogger.com (Tim) — Tue, 17 Mar 2009 23:52:00 +0000

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

noreply@blogger.com (Tim) — Sat, 07 Mar 2009 01:47:00 +0000

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!