Wednesday, June 24, 2009

CT Code Camp Recap

I attended the second CT code camp on June 13th at the New Horizon's center in Hartfort, CT. Ostensibly it was a research trip for the code camp we're organizing for VT this fall, Sept. 12. However, I love going to code camps because of the educational value and networking opportunities they present. As I've previously posted, I've been to a few of the code camps held in Waltham, MA - so I was excited to have a slightly different experience.

The venue for this code camp was a well appointed learning center with plenty of rooms of varying capacity. Each room had projectors, lots of tables and chairs. At the Waltham camp most of the seating lacks a table, so it was nice to have a place to put my notebook (rather than balancing it on my knee). One thing I noticed by its absence was the wide hallway at the Waltham location. The hallways at the New Horizon center seemed more narrow. Maybe it was just the 150 or so people moving through them, though.

I encountered the registration area as soon as I entered the building. It was nice to see Dennis Perlot's smiling face at the desk. I met Dennis at the New England User Group Leadership Summit in May. He and S.B. Chatterje run the CT .NET user group and this code camp. The registration packet included the session schedule, list of donors and a copy of Windows 7 Release Candidate.

The entire event was extremely well run. My only quibble was the lunchtime activities, focused on job fair like sessions such as resume writing and networking skills, went on longer than I would have liked. I'm sure this is a result of my being comfortable with those topics - I just would have preferred to have at least one technical session going on concurrently. But as I say, that's a quibble. The entire experience was well worth the trip and I hope to make additional CT code camps.

I've created separate posts for 3 of the 4 sessions I attended. I'm not bothering to post about the 4th session because I had to leave early and my notes aren't complete. My session specific posts are:

.NET Troubleshooting in a Production Environment - Polina Cherkasova

jQuery – Why You Want It & How to Use it in ASP.NET - Dave Bush

Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, 3 Best Practices - Dan Mezick

CT Code Camp Recap: Part 1

.NET Troubleshooting in a Production Environment - Polina Cherkasova

This session was a review of different strategies for identifying problems that are discovered after software has been deployed to the production environment. Polina categorized the severity of issues from unexpected behaviors (e.g. code working as designed but not as the user believes it should) through complete application failure (i.e. smoking crater where the server used to be).

One of the strategies to diagnose a problem was to have the production environment run in debug mode. However, this approach results in an application that is not identical to the production build and can skew the results. Besides, the problem may not be something which can be reproduced at will.

Polina spent a fair amount of time advocating for using an on-the-fly debugger. The debugger she was using was AVIcode ART ( It was about 3/4 of the way through the presentation before I realized Polina worked for AVIcode. So her advocacy made sense in that light. Her demo was compelling, though. I liked the fact you just configure the application to monitor the application (without having to code additional instrumentation into the application) and it can report on a variety of conditions with varying thresholds of sensitivity.

Another strategy is using application logs using tools such as log4net, Entity Library, Event Log, nLog, etc. This approach allows for information to be retrieved at run time but requires development effort and usually only deals with handled exceptions. Missing from her analysis was coding robust event logging into the application. Doing this will provide the person diagnosing a problem with additional information for identifying what lead to the problem being researched. However, like error logs, this requires development effort and getting the signal to noise ratio right can be a challenge (so only events which are truly helpful are captured).

CT Code Camp Recap: Part 2

jQuery – Why You Want It & How to Use it in ASP.NET - Dave Bush

With the release we're currently developing at work we've been using jQuery more and more. Put me down in the fan column. I really, really like it - but I'm still a newbie to it in so many ways. So when I saw there was going to be two sessions about using it I figured attending one would be a good idea. I'm glad I made Dave's talk. It was chock full of demos. I'll admit that even being a relative newbie it took a few samples before we got to examples I hadn't seen, though.

The best parts were some of the best practices he provided. For example, Dave suggested linking to the jQuery library hosted on Google's servers rather than serving it up on our own machines. Many sites do this and it leverages the browser's caching to improve performance.

An interesting point Dave made was to point out there is a difference between jQuery's document.ready event and the document.onLoad event. The document.ready fires as soon as the page is parsed enough where all JavaScript can be executed while the document.onLoad fires when the page is done rendering. Knowing the difference between the two can be instructive when trying to decide which event should be referenced when code needs to run.

Dave suggested making sure we apply VS2008 SP2 so we can have Intellisense when coding jQuery statements. Step by step instructions on how to do this are available on Scott Guthrie's blog here.

Another revelation, and one which I will surely be sharing with my peers at work, was a throw away line Dave had talking about a JavaScript library that forces IE6 to behave like IE7. I wrote that down with the intention to research it because of our requirement for continued support of IE6. Anyway, a quick Google search resulted in this blog post talking about the IE7.js library. It's still just a lead at this point... but I intend to follow up on this soon.

Dave's blog is

CT Code Camp Recap: Part 3

Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, 3 Best Practices - Dan Mezick

I'm not sure how to write this session up. This was by far the most compelling session I attended. Dan is a dynamic speaker, his points are sound and I found the approach to development he described very appealing. There was so much content presented during the session I'm not sure any blog post I can write could do it justice.

The session was an overview of Agile and Scrum. I've never worked in a development group that embraced
the agile approach. Many of the teams I've been on have conducted what they called "Scrum" meetings, but those meetings didn't match what Dan was describing - let alone the process that was supposed to accompany it!

What was fascinating about Dan's presentation was it was more about team dynamics and interpersonal relationships than it was about the development process exactly. The same techniques being described could apply to any team trying to complete a number of tasks in support of an end goal. The whole process being described was very empirical in how the project's progress is being tracked. One example of this is to hold off making a decision until the "last responsible moment." I LOVE this concept. The idea is that as more information comes in we can make a more informed decision. If a decision is made early on it is human nature to not reverse that decision - even in the face of additional evidence. By delaying the decision to the last responsible moment we're increasing the odds that the decision being made is as fully informed as possible. I'm hoping to adopt this in my daily work as application designs are considered.

Another example of having a project managed by evidence had to do with project schedules. The idea of backing into a release date, for example, appears to be completely abhorrent in this system. By identifying the release date early the team exposes itself to "inattentional blindness" which is a phenomenon where people don't see something that's there because they are paying a lot more attention to something else. In the case of the release date, the team becomes so focused on the scheduled release date they are unable to perceive changes or events that had they been perceived would lead to a change in the release (either schedule or scope).

The 3 Roles

Dan described an appropriately organized team as consisting of 3 roles: the product owner, the Scrum master and the team.
  • The product owner is the individual responsible for collecting and elaborating the project requirements and putting them into the product backlog (see the 3 artifacts). This individual is the interface with all the stakeholders who are interested in the resulting product (e.g. management, sales, marketing, users, etc.).
  • The Scrum master is the individual (and it is an individual - one person, singular) responsible for product backlog - they own and prioritize it. The Scrum master is not a traditional project manager. Their job is to "patrol" the product boundery to ensure no requests are coming into the product backlog that are not appropriate for that product. By having this be an individual the product backlog prioritization is not subject to the conflicting whims of multiple individuals
  • The team is self-organized. The team participates in the product design. They decide on a subset of the product backlog that will be addressed in a particular sprint. A good rule of thumb is to have +/- 5 to 7 people on a team. No one who is allocated less than 50% to the project is considered a team member. "Committed people" are >= 50% allocated, everyone else is merely involved.

The 3 Ceremonies

The process Dan described is punctuated by a few types of meetings (there are always meetings, right?); Sprint planning meetings, daily Scrum meetings and project retrospective meetings.
  • Once the Product Owner has put all the requirements, requests, bugs into the product backlog and after the Scrum master has prioritized the backlog it's time for the team to meet. The purpose of the meeting is to decide what can be accomplished in the next development period. These development periods are 2 - 6 weeks long and are called "Sprints". In the sprint planning meeting the team identifies which sub-set of the product backlog can be accomplished in the sprint. The team must pick off the top of the product backlog (ensuring priority work is being done) but they decide how many of the items realistically can be completed. Other stakeholders can attend the sprint planning, but it's the team's meeting. Also, remember before I mentioned the team is self-organized? This is part of what that means. It's worth noting that by making the decision about what to work on this way, the team is delaying decision until the last responsible moment. The product backlog is as mature as it can be, so the team is committing to the truest priorities possible.
  • Once the sprint is underway it's important for the team to meet daily to provide an update on progress. This is the daily Scrum meeting. Each team member reports what they accomplished the prior day, what they intend to accomplish that day and what (if any) obstacles are in the way. The reason the meeting is daily is to prevent "cognative dissipation." The idea is if I say I'm going to do feature 1 today, and nothing is in my way, the team is going to notice if feature 1 isn't finished (or at least had progress) tomorrow. If the scrum were held weekly, well, who remembers what they worked on a week ago let alone what commitments a peer made? Having the ongoing, consistent knowledge might prompt one of my teammates to find out what problems I might be having. Again, this is the team's meeting. Other stakeholders can attend - but they better stay out of the way...
  • Once the project is complete it's time to reflect on what worked well, and what needed improvement. That's the project retrospective meeting. These meetings might expose some hurt feelings and raw emotions. On a mature team these can be worked out. The goal is to improve the process for everyone so the team, product owner and scrum master can do better the next time around.

The 3 Artifacts

There are three documents
  • By now you probably have a good idea of what the product backlog is; it's a prioritized list of each feature, enhancement request and bug that is to be incorporated into the product. Normally the list is dynamic. Requests are made, bugs reported and the product owner adds all that to the product backlog. The Scum master prioritizes the product backlog and the team provides estimates on level of effort for each item on the product backlog. However, once the sprint is underway the product backlog is static (at least as far as priority goes). If requests/bugs come in they can be added to the bottom of the stack, but nothing gets prioritized to the top. That's because while the sprint is underway the team is working off the sprint backlog.
  • The sprint backlog is the result of the sprint planning meeting. It's a mini-product backlog of what the team will be delivering in the sprint. Because this is what the team has committed to deliver, and that commitment was made at the last responsible moment, it is unacceptable to change the priorities of the sprint once it has begun. That's why the product backlog is static during a sprint.
  • A burn-down chart is a graph that shows work to be done on one axis and time remaining on the other. Dan showed some examples. Google can help you find examples, too.

The 3 Best Practices

Unfortunately, by the time we got to talking about the best practices, Dan was out of time. He threw up a few slides and pictures to communicate the ideas, but I'm just going to provide some links which will cover the topic more completely.
  • User Stories are a way to capture user requirements.
  • Planning Poker is a technique teams can use to provide estimated levels of effort for items on the product backlog.
  • Scrum Board (a.k.a. task board) is a tool used to reinforce the work being done. This is the only thing I've been able to implement in the immediate aftermath of the code camp. My whiteboard has been converted to track the tasks on which I'm currently working. One of of my teammates likes it, too, and has started using one. I expect we'll use one for our team in short order.

Final Thoughts...

Dan's blog is at

Wednesday, June 10, 2009

An Excellent Post About JQuery Selectors and ASP.NET

I had to share this blog post by Dave Ward about optimizing performance when trying to get jQuery to select the correct element as you work with ASP.NET.

Tuesday, June 9, 2009

I'm So Excited (and I just can't hide it)

I'm one of a handful of people trying to launch a code camp in the Burlington, VT area. We just received confirmation on the venue and can now start asking people to hold the date. It's going to be on Saturday, Sept. 12, at the UVM Business School.

There's still a lot of work to make it happen but I can't tell you how thrilled I am that we have a venue and date.

Small reminder for JavaScript development

Sometimes we need reminders about the basics. In reviewing some JavaScript code this morning I came across a function that builds some html on the fly by concatenating values together. What people have to remember is the smaller the JS file is the faster it will download. So rather than doing this:

scratch = scratch + "<a href....";

you need to use the built in += operator, thusly:

scratch += "<a href....";

The function in question had the first approach 12 times. Using the built in += operator I was able to reduce each statement by 9 characters. That reduces the function by 108 characters overall.

So the lesson is use built in functionality because little things can add up.