Treetown Agile Adventure

Pair Programming Harmful? Says who?

2012-03-06T07:41:00.002-05:00

There's been a lot of attention on Twitter to an article by Jon Evans at TechCrunch that takes a fairly broad attack on the agile practice of pair programming, only to advise readers to use their best judgement about it. I find the piece to be a sensationalist attack on a practice that the author doesn't seem to understand. He cites the ineffectiveness* of "brainstorming", which pairing is nothing like; and the dangers of allowing people to hide and let others do the work, which good pairing actually mitigates. Even if you grant his, in my estimation, weakly-supported hypothesis that it harms superstars, it completely misses the accelerated learning and distribution of knowledge that pairing affords agile developers and newbies. The article also misses the natural instinct that we developers have to work on what we find fun and interesting, even if it's not trying to solve the business problem at hand - how many times have you seen a cowboy rewrite working code because s/he didn't like it or because it was a prime candidate for a flashy new technology? Waste like that doesn't happen in good pairs. Neither does finding yourself at the end of a couple of hours having achieved little besides some web surfing, a few personal calls, and having reduced the size of your inbox? Or haven't we all seen great, creative solo work, that isn't what the business needs?

Evans doesn't acknowledge that pairing is a skill that takes practice to get good at, and for some developers getting good at it requires some people to step out of their comfort zones. Rather than his arguments against pairing, I'd like to see an article discussing personal challenges that pairing poses for some developers and the courage that it will take for them to become good pairers, if they want to avail themselves of the benefits of pairing.

* This claim may not even withstand scrutiny: http://bobsutton.typepad.com/my_weblog/2012/01/why-the-new-yorkers-claim-that-brainstorming-doesnt-work-is-an-overstatement-and-possibly-wrong.html

A New Big Visible for the Card Wall - State Change Criteria

2012-03-05T09:06:00.001-05:00

I have a team that's just starting agile. During Sprint 0, we decided on a Definition-of-Done, but the team also wanted a way to make the criteria for moving a story card from one column on the wall to another big and visible. Being new, they thought it would help them to see, as they move a card from one column to the next, what had better be complete at this stage. If they had missed something, they have a chance to catch up before they actually move the card. We came up with yellow boxes that sit on the physical boundaries between columns on our card wall (see right). I'm calling them State Change Criteria (since there's already been a CCC since early XP days). The team left room to hand-write new criteria as their understanding grows and their process improves.

We came up with two more big visibles (not shown) that address the flow of "defects". One says: "In-sprint defects are moved back into Sprint Backlog." This is to remind the team that we don't track problems with in-play cards, we just fix and finish them within the sprint. The other says: "Escaped defects are written as new user stories and moved back into the Release Backlog." This is to remind the team that the Product Owner may choose to prioritize new functionality above fixing the defect.

Trying to get .Net Metrics Computed and Displayed with Jenkins

2012-02-02T14:58:00.001-05:00

I'm helping a .Net team stand up Jenkins as their CI server. The build steps we have so far are building a solution and running fxCop against the debug build. Using the Jenkins Violations Plugin, which supports fxCop, we can display a nice trend chart and have hot links to drill down and see the violations in context.

My next goal was to run metrics that my team agreed on, specifically Cyclomatic Complexity and Coupling. I was hopeful because Visual Studio 2010 can already compute them. But I found out that Visual Studio's code metrics can't be called on the command line.

Fortunately, I found Visual Studio Code Metrics PowerTool 10.0 for that purpose. There's lots of information already out about using it: Jeff Bramwell has a blog post about the PowerTool and Cameron Skinner wrote one about it.

Unfortunately, the Violations Plugin doesn't support the xml output, and the PowerTool doesn't have an option to output to HTML. Fortunately, though, Skinner also wrote a post that provides an xslt and a .css file that will turn the results into HTML.

So my next step was to make a build step that runs a command-line tool to apply the transform. I couldn’t figure out or find enough documentation on msxsl.exe, but I found this CodeProject project and it works. (Anyhow, it would only take a few lines to write your own in C# because you can use calls from MSXML.)

Now I need to figure out how to use the HTML report in Jenkins. I'll investigate the Jenkins HTML Publisher Plugin.

Why Pair Program?

2011-12-14T20:33:00.000-05:00

Pair programming is one of the agile engineering practices that developers give me the most pushback on (probably second only to TDD). Here are some of the reasons I give for why we pair program:

progress (driver) and research (navigator) instead of progress or research (solo dev)
may avoid the need for code reviews, which can be contentious
second set of eyes, catches silly mistakes
less thrashing between QA and dev and back
less time wasted down rabbit holes, as navigators offer perspective
less time wasted on non-work distractions
keep each other honest on practices like code quality, TDD, checkins
reduces a team's bus factor, a significant business risk for IT projects

I'd like to write more about some of these, but I'm not sure when I'll get to it.

Refactoring - Is It Only Removing Duplication?

2011-11-17T18:23:00.000-05:00

Today a colleague was looking for a TDD poster that showed Red-Green-Refactor with detailed emphasis on Refactoring. We found a diagram that simply said "refactoring = removing duplication". This got be thinking about a post by JB Rainsberger in which he said: "...if you master removing duplication and fixing bad names, then I claim you master object-oriented design." (If you see this, JB, do you still make this claim?)

There are lots of kinds of duplication, and JB's assertion makes sense to me especially when I think about the kind of informational duplication (as opposed to code duplication) that DRY is intended to avoid.

After Agile Coach Camp 2011

2011-09-25T21:32:00.000-04:00

I spent this weekend at Agile Coach Camp in Columbus, Ohio. It was my first open space conference, and I loved it! Learn about Open Space unconferences on Wikipedia. I won't even try to explain it.

Friendship, community, sharing, equality, questions, suggestions, personal revelations, self-examination, laughter, fun - I received all these things and more. Zee Spencer summarized some of the sessions here, and I'm sure there will be others. There's a picture of the sessions board showing most of the Saturday sessions.

You can get a small taste of the amazing energy of the event by reading the #accus hashtag on Twitter.

In 2012, Agile Coach Camp will be in Minneapolis. If you can, you owe it to yourself to go.

Advice for someone wanting to get (back) into software development

2011-09-09T20:33:00.001-04:00

I was talking to a friend today who was doing software development several years ago but has been unemployed for a while. He asked if I had any ideas about what he might to to get back into software.

(An an aside, Patrick Welsh already wrote a great piece about why people should consider a career in software)

Here are some of the thoughts I gave my friend on how to get (re)started in the industry:

- If you don't have work experience to show on your resume, create relevant non-work experiences and structure your resume to show them.

- If you're not already on Twitter, set up an account and use the search function to find experts in the areas you are interested in. Follow them.

- Attend groups/events where people who do what you want to do gather. Ask people questions about what they do. Ask what blogs they read and who they follow on Twitter.

- Start learning web programming, throw up a website, publish the code on someplace like github, and keep updating it. One place to start might be: http://railsforzombies.org/

- Expose yourself to new languages and technologies: ruby, scala, functional languages, automated testing, continuous iteration ...

- If you're not currently working, ask about an internship someplace you'd like to work at, even if it has to be unpaid.

- Be helpful - volunteer for anything related to your targeted field. People remember/like you better if you've helped them. Less cynically, it gives people a chance to see who you are and what your attitude and skills are.

- Don't get hung up on getting/finishing a degree if you don't already have one, especially if it would take away from getting real life experience.

- Read this book about managing your software career:
"The Passionate Programmer: Creating a Remarkable Career in Software Development" by Chad Fowler

- Consider reading this book about agile software development:
"The Art of Agile Development" by James Shore

Finally: Don't follow my advice without deciding for yourself if it makes sense for you. Ask other people about it as well.

Coding in the Clink IV - my second coding retreat at Marion Correctional Institute

2011-06-25T23:28:00.005-04:00

On Saturday, I attended Coding in the Clink IV at MCI. It was great to see the inmates again. We all agreed they have made great strides in their learning since the last time we worked with them in March.

This was my second time spending a day programming with inmates at MCI. The first time in, I got to have my stereotypes blasted. As I said in my previous post about Coding in the Clink, one thing that struck me most was how similar the day was to a full-fledged CodeRetreat on the outside.

This time, I was reminded all day of just how careful I need to be when pairing with or coaching a less experienced developer. If I'm not careful, it's easy for me to press ahead with my own ideas and simply explain to my pair what I'm doing. That doesn't always leave my partner room to struggle with ideas, and in that moment I'm not letting them succeed in solving a problem or explaining something to me or probably other ways.

On the outside, while pairing in this way is not what I strive for, a little bit of it isn't necessarily a disaster. Unless they are in way over their head, most devs I pair with will assert themselves and claim their role a partner, even when I'm not sharing well that day. When that happens, I often "wake up" and start "playing nice" again.

But in prison, inmates are predisposed to not assert themselves to outsiders. Dan Weibe mentions it in his post "But-but there are CRIMINALS in prison!":

...The program is seen by the prisoners as a very good thing, and any attack on it ... could get the whole program ejected ... [and] life would immediately become very dangerous for the offending prisoner. Everybody knows this...

Here's the part that illustrates why I have to be extra-careful to be a good pair in the prison:

... in some cases the normal give-and-take of pairing can be hamstrung when a volunteer and a prisoner pair together because the prisoner strains to be pathologically accommodating.

To some extent, I let myself fall victim to that this weekend at CitC IV. I still think the inmates that I paired with had good experiences this time, but I would have liked to offer them more. Looking back to my first visit to MCI, I was better pair/coach that day, doing a good job at things like:

meeting the man where he is
inviting him to try things
asking him some questions that he knows the answer to
asking him harder questions so he has to stretch himself to come up with an answer
making small suggestions when he's stuck rather than giving answers
putting aside my desire to make progress in the code in favor of getting to know my partner a little and facilitating his learning

Now that I've spent some time thinking about this, I feel prepared to be the kind of coach/pair that I know I can be at the next CitC. I just wish the institution could accommodate more than one event like this per quarter.

Coding in the Clink - CodeRetreat III at Marion Correctional Institute

2011-03-28T00:00:00.003-04:00

Since Dan Wiebe already did a great job of summarizing today's "Coding in the Clink - III" CodeRetreat at Marion Correctional Institute (MCI), he suggested I blog specifically about the two sessions I participated in.

I paired with Wes in the first cycle. He has programming experience "on the outside". Not only was he disappointed that we had to use Eclipse instead of IntelliJ, he was further disheartened that we had to work on a generic workstation that didn't have his Eclipse template(s) on it. But he got over all that quickly and we had a blast (and got some work done). Wes and I were yukking it up so much that another insider asked us to keep it down. (Wes is known in the group for his loud enjoyment.) Wes did most of the driving. I mainly suggested ways for the tests to drive the code and offered ways to break his ideas into smaller TDD steps . Wes was great about this. He feigned frustration at my suggestions while making it clear that he appreciated me keeping him "honest". It seemed to help him take a break from the all-too-common block of "I've already got it designed in my head, how do I write it with tests first?" I did occasionally contribute to our design, mainly by suggesting tests that I thought would cause interesting problems. One suggestion I made seemed to lead us down a rabbit hole, but Wes and I made the best of it by turning it into real refactoring practice (when our tests were green).

After our first session, the inside guys and we outsiders pulled our chairs into a rough circle and discussed the morning. The insiders really seemed to appreciate the learning that happens in both directions, even in pairs that have significant skill differences. One said he liked being a triple because he had the resources and perspectives of two other programmers instead of just one.

A quick anecdote about lunch: we were served "brunch" food (eggs, sausage, English muffin...) and a couple of the insiders made a point to say that we shouldn't think they eat like this all the time, that this is a nicer meal than they usually have. And overhearing them, a nearby corrections officer ("CO", never "guard") answered something like: "Don't listen to them, this is no better than what they always eat". I'm not sure what was behind this exchange. It was the only thing I heard the whole day that could even remotely be taken as playing for sympathy. Otherwise conversation was just about like what goes on at CodeRetreats on the outside: insiders asked us about what other languages we've used, they told us about their past computer experience, and two told me at lunch about a job they both worked on with a private company in Arizona from inside MCI. (I tip my hat to those guys - telephone was the only way they were allowed to communicate with their civilian colleagues, and one of the colleagues didn't initially want to work with men in prison.)

During the second (and last) cycle of the day, I was in a triple with Larry and Dave (I think). Dave was much more comfortable than Larry, and seemed to have more experience. This cycle, I was especially aware of being a coach, maybe because Larry wasn't as quick to see where Dave was going and was less assertive with his ideas than Dave was. I found myself pulled in two directions - on the one hand, I was drawing Larry out by asking him to suggest tests or suggesting that he implement code to make Dave's new test pass. On the other hand, I wanted to encourage Dave's enthusiasm and ideas. The conclusion I drew from this cycle is that I think inexperienced developers probably shouldn't be in triples unless they are very outgoing and ready to take risks. If I'm coaching someone who is shy or inexperienced or both, I'd like to be able to give them my full attention as a paring partner.

It seemed like everyone, insiders and outsiders, had a great experience. More than one insider spoke of what he learned. We worked about 9:30 to 3, so if you figure we had 30 minutes for lunch, we only had about 5 hours. Most people seemed to think that this was too short a day. Apparently, they usually have until 4:00 but were cut short today because of scheduling of other outside programs.

Many thanks to Dan, Jo Dee (Dan's "prison boss"), the COs that accommodated us, the insiders and the other six volunteers. I'd very much like to do this again.

#RubyOnRails and partial forms

2011-02-20T16:13:00.005-05:00

I'm working on some exercises in the Ruby on Rails Tutorial book. I noticed a lot of duplication in my new and edit views, so I thought I'd try and make it more DRY. I knew I'd need a partial, but I hadn't written one for a view yet.

I'd heard good things about the #RubyOnRails IRC channel, so now was a good time to try it out. I had to download an IRC client for my MacBook, and chose Colloquy. In almost no time, I got enough help to implement my partial. (If you aren't familiar with it in Rails 3, you can see my solution here.) I don't know why it tripped me up so much. I finally got the second argument right in the form_for correct and used it as a local variable in the submit line so that the button has the right text. And all my rspec tests pass.

gist vs pastie

2011-02-20T15:43:00.006-05:00

I started another post (which I'll finish at another time) about using the RoR channel on IRC to get help with creating a form partial to eliminate duplication in my new and edit forms. I started writing about gist, saying it was like Pastie, and then I started looking at the difference between the two. There are enough similarities and differences to be worth an entire post, so here it is.

Gist is associated with your github account. Gist allows public and private pastes. Other gist users can clone or fork your code using a url that is created for each paste.

Pastie doesn't require a login, so it's nice for quick-and-dirty. Pastie claims to have a bot that you are supposed to be able to access right inside IRC. You send it a public message, it private messages you a link, you click the link, paste your code, click OK and the bot is supposed to announce the link to your paste to the channel. Unfortunately, I'm told it's never worked.

Pastie does have a nice feature for Rails developers ~~that gist does not~~: Ruby on Rails syntax highlighting. Apparently it has C# syntax highlighting too, but it's only mentioned in the blog.

I plan to stick with gist for now, because of its connection to guthub.

EDIT: I didn't realize that gist not-only has syntax highlighting for lots of languages, it will auto-detect based on the filename extension that you give your paste (for example, this partial that I will discuss in my next post.) Now I'll stay with gist for sure.

Success with Reflector.NET

2011-02-04T23:10:00.006-05:00

At my day job, we had a custom application in the field, a one-off, that a long-time customer had recently requested an important change for. The trouble was that we didn't seem to have source for it, and no one could remember who in our company had written it. All we knew was roughly when it was written (a few years ago) and that it was probably written with C#.NET.

So I ran RedGate's .NET Reflector on the hope of maybe getting some usable source code. I'd poked around inside assemblies before, but I'd never disassembled an executable to generate code. My hopes were exceeded - I have a very usable C# project now, with meaningful method names and so on! Here's how I did it (I'm sure this story has been countless times, but I enjoyed doing it, so I'm presenting my experience.)

I launched .NET Reflector and it asked me to pick a .NET framework to load default assemblies from, but I just clicked Cancel. File | Open ..., browse to my application, click open. After briefly poking around inside my app, I clicked my .exe in the tree and selected Tools | Disassemble, making sure that C# was selected in the language combo box on the toolbar. Then Tools | Export. Reflector wrote out a couple .cs files (Global.cs and AssemblyInfo.cs) and then prompted me for the location of an assembly that it could not locate. Fortunately, the field engineer had included that assembly with when he gave me the executable to experiment on. So I browsed to the assembly and clicked OK.

(Side note: I'm actually writing about this as I repeat the process at home, for a second time, from scratch. I hadn't taken sufficient notes at work to be able to write this post. The first time I did this, I skipped the step telling Reflector about the assembly. What that cost me was that while this second time reflector knew about the enums that were defined in the DLL, it didn't the first time. I had to find them by inspecting the method prototypes, using DevStudio's object browser, reading error messages in the code, and knowing generally what the app was supposed to do. It wasn't a lot of extra work, and I enjoyed my sleuthing but I'm glad to know that Reflector can do it for me.)

Reflector went on to write a Form1.cs, two .cs files that I recognized as containing functions common to many of my company's products, a .resources file, and a .csproj file. Things were starting to look good.

The .csproj opened fine in Visual Studio 2003. The first thing I noticed was that even though I had told Reflector where the referenced assembly was, the reference to it in the project was wrong, so I easily fixed that. Next I opened Form1.cs and was welcomed with the familiar WinForm layout of the app I had started with. Crossing my fingers, I started the solution building. 74 build errors, but many of those were duplicates. This might not be too bad.

There were ten or more errors of the form:

'System.Environment.CurrentDirectory.get': cannot explicitly call operator or accessor

on lines like this:

string str = Environment.get_CurrentDirectory();

That's not the model that .NET uses for getters! Changing the line to:

string str = Environment.CurrentDirectory;

got it to compile without even a warning. There were also setter lines I had to fix, like this:

Environment.set_CurrentDirectory(WorkingDirectory);

which became:

Environment.CurrentDirectory = WorkingDirectory;

And then there were the lines that looked to be assigning delegates:

objFMon.add_ReceiveCodes2(new __CCodeMonitor_ReceiveCodes2EventHandler(this.objFMon_ReceiveCodes2));

which I fixed in this way:

objFMon.ReceiveCodes2 += (new __CCodeMonitor_ReceiveCodes2EventHandler(objFMon_ReceiveCodes2));

Another example of this type of error was was:

FAULT_CODE fault_code = this.m_aryFaultCodes.get_Item(i);

which became:

FAULT_CODE fault_code = (FAULT_CODE) m_aryFaultCodes[i];

There were about 25 errors of the form:

Method 'MyApplication.Form1.Form1_Load(object, System.EventArgs)' referenced without parentheses

that referred to a line like:

btnAck.Click += new EventHandler(this, this.btnAck_Click);

I changed that one to:

btnAck.Click += new EventHandler(btnAck_Click);

I'm not sure what inspired me to think that the signiature was wrong except, perhaps, the vague feeling that the handler already knows that I'm giving it a method on 'this'.

Including all the delegates, there were about a dozen that I fixed by changing them from the function style to the property style.

Interestingly, Reflector didn't do a great job getting the number type right on a value given to a switch statement. I got this error:

A value of an integral type expected

on the first line of this switch statement:

switch (num2)
{
case -1f:
base.WindowState = FormWindowState.Minimized;
goto Label_0474;

case 0f:
base.WindowState = FormWindowState.Normal;
goto Label_0474;
}

because num2 was a float. Notice that Reflector added "f" after the integer values in the case lines. Searching upward in the code, there didn't seem to be any reason for num2 to need to be a float, so I changed it to an int and got rid of the "f"s. I had to do this for a second switch statement as well.

It wasn't hard to figure out that I had to cast several returns from ResourceManager.GetObject as Image or Icon as in this case:

base.Icon = (Icon) manager.GetObject("$this.Icon");

The following line called a function familiar to me, with my company's SpecialRead function. I knew that returning zero was a success code, so I was confident that I could replace null with 0.

if (SpecialRead(specialHandle, ref retValue, ref this.retLength, this.lenBufferInt16) == null)

There were 10 or 11 of those that I fixed.

This error had me stumped briefly:

Resources 'MyApplication.Form1.resources' and 'MyApplication\Form1.resx' have the same manifest resource name

'MyApplication.Form1.resources'.

But after a brief trip out to google, I decided to try deleting the .resources file. That seemed to do the trick. So with the compile and link errors gone, I cautiously pressed F5. I was disappointed when I got:

An unhandled exception of type 'System.Runtime.InteropServices.COMException' occurred in MyApplication.exe
Additional information: COM object with CLSID {XXXXXXXX-YYYY-ZZZZ-MMMM-NNNNNNNNNNNN} is either not valid or not registered.

I was missing a COM object that needed to be registered.

So I took what I had built to the original engineer. His laptop was fully configured to run the product. Sure enough, my app ran successfully on his laptop. He sent it off to the customer to see that it runs the same in the field as the original. If it does, then I'll make the original requested change.

UPDATE: After we shipped the executable I built, another engineer found the original source code, in a remote, nearly neglected corner of our version control system. It's possible that the code in version control is not as current as the (now lost) code that was used to build the original exe I was given. So my next task will be to compare the two sets of source and see if I can determine if one is newer that the other

I'm hot on Rails, git, and CodeRetreat

2011-01-25T22:02:00.008-05:00

Now that I'm back from CodeMash, where I attended an overview session called "Rails 3 from A to Z", I'm excited about taking a deeper dive into Rails. My first exposure to Ruby was the excellent Ruby Koans PreCompiler session at CodeMash 2010. I didn't complete all the koans at that session, and I didn't follow up and finish them afterward (although I was bitten again by the koan bug when I helped Dianne work on her Scala Koans PreCompiler session during Six Weeks of Scala), but now that I've completed Rails for Zombies, I'm totally going to go back and finish the ruby koans. Maybe before that, I'll finish another Ruby tutorial I started, TryRuby.org. It leads you through lessons and has you enter your answers at a command prompt. After that, I will probably go on to RailsTutorial.org (as recommended at the end of Rails for Zombies.) They have a free tutorial book online and they sell a pdf version and tutorial screencasts.

And after that, I've found a series of interesting articles on programming Rails on Apple's website:

- Using Ruby on Rails for Web Development on Mac OS X

- Customizing Rails Applications on Mac OS X

- Deploying Rails Applications on Mac OS X

And somewhere among all that, I'll want to learn the Twitter API, as I have an idea for a site related to Twitter.

Another CodeMash 2011 session that I've taken to heart is the awesome Git Immersion. While my department at work uses Subversion, I've started keeping my experiments in a git repository. And since so Ruby (and other projects) use git and/or github, it will be good to be familiar with git.

And finally, I'll be attending the 2nd Anniversary CodeRetreat in Ann Arbor this Saturday, Jan 29. This will be number 5 for me. Come join us!

On Giving Useful Feedback

2010-12-04T09:42:00.003-05:00

Successful agile teams do well, in part, because of the types and amount of communication they use. One place where communication is most important and comes with significant risk is giving "constructive criticism" or "corrective" feedback. I've noticed two patterns of feedback that don't work well: indirect or soft feedback, focused on not hurting the recipient's feelings and unnecessarily frank, or even blunt feedback given with little regard for the recipient's feelings. The first pattern tends to communicate insufficient information and the second pattern, while containing full information, is not presented in a manner that that is often met with defensiveness.

A friend told me about a pattern of giving feedback that I think does a good job of avoiding the pitfalls of the first two patterns. I didn't ask him where he learned it, and I could only find one reference to it: http://bit.ly/dEwGw4 The pattern is called "what-what-why" and it works like this:

Tell what you didn't/don't like or what you think didn't/doesn't work well
Tell what you would like instead
Tell why you think your suggestion would be more effective

For example:

I don't like how our team is spread out and in individual cubicles
I'd like it if we moved into one room and sat at a cluster of tables
We'd "overhear" important information and there would be fewer barriers to asking each other questions.

Or:

One thing that didn't work for me in the retrospective was when you would say something before someone else was finished speaking
I'd like it if you allow other people to finish their point and then add yours
I think the meeting would flow more smoothly and everyone would that they would get their chance to be fully heard.

There are a couple things I really like about giving feedback this way. First, it makes it clear that this is what I don't like and what I want instead. If I were to instead say: "You know, it might be better if you let people finish their point..." or "Don't interrupt people...", I'm not really owning that this feedback is coming from me. Second, it focuses on the desired benefit instead of focusing on anything about the person, making it less likely that they will take what I am saying personally and become defensive. And finally, I don't have to spend a lot of time thinking about how I am going to give feedback or worry much about how the person might take it. As soon as I see something that I'd like to be different, I can give the what-what-why and address the issue right away. This is great because communication is most effective when it happens early.

I recognize, however, that not all feedback is intended to cause a different outcome. Sometimes someone is doing something that I like or that I think is working well and I want to let that person know. In that situation, I use a "what-why" pattern:

Tell what you like/liked or what you think works/worked well
Tell why you like it or think it works well

For instance:

On the story wall, I like how you've given each team member a tag that they can put on the story that they are working on.
Not only does it let everyone know what everyone else is working on, but it's a good way of reminding people to only work on one story at a time.

Like what-what-why, this pattern lets me own that this is my viewpoint, it focuses on the process and outcome rather than the person, and it's a template that lets me communicate as soon as I recognize that I want to.

If you try what-what-why or what-why, I'd be interested to hear your results. Do you have similar feedback patterns that you find useful?

Another Thought on Certification

2010-10-24T16:57:00.012-04:00

Yesterday at 1DevDayDetroit, Virender Ajmani gave a very interesting talk about Google Map mashups. (If you missed his talk, check out his blog or download his slides.

Besides his very interesting content, he mentioned something that else that caught my attention - the Google Qualified Developer program. It's a different approach to the question of developer certification (which I know is a hot topic in the Agile world in general and at the Agile Skills Project in particular). Google's program is free, and it focuses on accomplishments, references, community participation, and knowledge. If you become certified, you get a badge for your blog.

To be certified in a particular Google API (Chrome extensions, Maps, etc.), a developer must earn at least 3000 of the available 5000 points towards that API in any. She/he can earn points in the following ways:
- showing proof of their work (working code) - up to 1000 points
- providing references (from paying clients) - up to 1000 points
- demonstrate community participation - up to 1000 points
- take the online exam - up to 2000 points

What I like about this approach is that no one type of mastery is enough to earn certification. For instance, a developer who aces the exam can not be certified without other evidence of their competence.

I wonder what an Agile badge in this style would be like.

There are already Scrum exams. Perhaps taking one of them would earn some points. There would be a cap on how many points could be earned through exams, and exam points might expire after a certain time.

I'm not sure how working code is necessarily any indication of someone's skill in Agile, so I think we'd have to come up with something else.

Attending certain classes might be worth points. I know there's been a lot of talk about how taking a class doesn't necessarily mean a person learned anything, and I agree. So perhaps any given class would be only worth a small amount, say 200-300 points, and it would only count if you had taken the course in the past year, and only 1000 points could be earned by attending classes.

Certainly some Agile developers could provide references from customers, and capping the number of points from references would reduce the chance and affect of quid pro quo referrals. Developers who don't have professional references could earn their points in some of the other ways.

And maybe book quests or webinar quests could provide a few points, perhaps with a fairly low cap.

I know there's a non-trivial amount of administration that would be required to manage a program like this. Please join the discussion on the Agile Skills Project Google Group.

Scrum Developer Certification is Now Real

2010-09-08T23:16:00.005-04:00

Just over a week ago, I got the following email from Chet Hendrickson:

Hello ADS Course Participants,

The mechanism for applying for the Scrum Alliance Scrum
Developer Certification is now available. The Agile Developer
Skills course you took with us satisfies the Basic Developer Skills
portion of the certification requirement. If you also hold a
Certified ScrumMaster (CSM) certification you may now apply for the
CSD.

The application can be found at:
http://www.scrumalliance.org/resources/1809

So whatever your view about the value of certification, it's happening. As for me, I'm not a CSM, so I won't be applying for a CSD any time soon.

Thoughts on my experiences at the second Scrum Alliance CSD course.

2010-05-19T00:46:00.007-04:00

Dave Nicolette recently blogged about how he has joined the ranks of the Certified Scrum Developers, by being a CSM and completing the Scrum Alliance CSD course taught in Cleveland by Ron Jeffries and Chet Hendrickson. I took the same course one week later in Ann Arbor. Unlike Dave, I'm not a CSM yet, so I don't qualify as a Certified Scrum Developer - I'm not going to weigh in on the pros and cons of "certification".

Even though the CSM was offered the two days immediately before the CSD course, I chose to only take the CSD course right now. My current focus is on improving my development skills, and the CSD course fits right in with that. It was a great opportunity to practice TDD, Pair Programming, and Scrum under Ron and Chet's observing eyes.

Unlike the Cleveland class, the Ann Arbor only had a few "known" participants. Present were Rich Garzaniti, a long-time eXtreme Programmer and member of the Chrysler Comprehensive Compensation project (C3) and Nayan Hajratwala, agile and lean coach and speaker. Dianne Marsh, co-founder of SRT Solutions, was also present, although she does not specifically focus her work on agile. The rest of us are seasoned developers with agile experience that ranged from never having done TDD to actively learning TDD outside of work and in the early stages of trying to introduce small agile practices into their workplace. I'm a long-time developer, involved in the Agile Skills Project, a rabid Code Retreat attendee, but I have little agile experience on the job.

Like the Cleveland class, we had difficulty with infrastructure that held us back, and as Dave said, that's not unexpected. Still, one team spent basically an entire 4-hour iteration (the course only scheduled 3 iterations in all) on infrastructure problems. The team I was on only spent half of an iteration on infrastructure problems (Without Nayan's familiarity with Maven, Hudson, Eclipse, and FitNesse, I suspect it would have also taken us a whole iteration too). In our class retrospective, we decided that there was some merit in having infrastructure issues as part of the class, as it gives a taste of what it really takes to set up tools for an agile project. We also decided that whatever steps are taken to reduce such issues, there will always be some, and they may provide enough learning.

In contrast to Ron's assessment that the Cleveland class produced the least results he'd ever seen (the CSD course is based on Ron & Chet's ADS course), Ron said that we, the Ann Arbor class produced the most "done" code he'd ever seen. In Dave's blog post, he gives an extended analysis of his class's results. I won't be discussing our results in that level of detail. Briefly, I attribute our success to having executed agile practices well. Here is a list of some things I think we did well:

Sprint planning meetings that involved a PO
TDD that focused on results and had a good balance of strong assertions and deferring to the other partner
Frequent Pair Rotation
Communication between pairs
Hourly Standup Meetings (remember, iterations were 4 hours)
Retrospectives that produced actual to-do items for improving our process
Doing the things from our retrospectives that we said we'd do
Lots of time with Ron & Chet as POs.

While we certainly were not immune from making assumptions about stories, we did ask a lot of questions about the cards during our planning meetings. When the Ron or Chet gave high priority to stories that we thought would take a lot of time, we suggested other stories that we thought would generate some value more quickly or we requested that some stories be split. We were conservative with our commitments.

Additionally, I think the goals the Ann Arbor participants had for the class were well suited to creating "done" stories. While I think Rich and Nayan wanted to refine their already strong agile craft, the rest of us seemed to be experienced developers who either want to become agile or to become more agile. While Nayan seemed to play a dual role as contributing developer and coach on my team, I think we all took responsibility for delivering quality results and improving our process.

All of that is not to say that we didn't have our share of problems. We realized late in the course that we would have saved some time talking in circles if we had drawn simple design ideas on a white board. Additionally, my team might have been able to show more value to the POs if we had implemented fewer file operations and left IO as an abstraction. In our code review, our team found some early design decisions that would have caused difficulties later, were we to have continued developing the product.

There's an old saw that says we learn more from failure than we do from success. That feels true for me regarding this course. I'm struggling to find any real "gems" of learning. For me, the biggest benefit of the course was the practicing - practicing technical tasks and practicing improving our process. Since I don't pair at my current job, the course gave me a good chance to look at how I pair and think about ways that I can be a better pair. And I did learn to use FitNesse and Hudson, which I had not used before.

And finally, I left the class with a renewed hope for our profession and my career. Being in a class of developers who seem really committed to delivering value and improving their craft was tonic for the pain and exasperation that I've experienced in past projects that had all the classic failures.

My Venture into JBehave via Conway's Game of Life

2010-03-29T21:39:00.007-04:00

Having used Conway's Game of Life (CGoL) at several CodeRetreats* to practice Test Driven Design (TDD), I thought I would revisit it when I took my first steps into Behavior Driven Development (BDD) with JBehave.

I downloaded JBehave 2.5 and refreshed my memory of the GoL rules:

Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any live cell with two or three live neighbours lives on to the next generation.
Any dead cell with exactly three live neighbours becomes a live cell.

What I love about using GoL for learning BDD is that the rules are practically already written as Given-When-Then scenarios. Just minor tweaks (including changing to the US spelling of neighbor) gave me:

Given a live cell with fewer than two live neighbors, Then the cell is dead.
Given a live cell with more than three live neighbors, Then the cell is dead.
Given a live cell with two or three live neighbors, Then the cell is dead.
Given a dead cell with exactly three live neighbors, Then the cell is alive.

All that's missing is a "When". All 4 rules have the same "When", which is "When I calculate the next generation". Taking that into account, I get:

Given a live cell with fewer than two live neighbors, When I calculate the next generation, Then the cell is dead.
Given a live cell with more than three live neighbors, When I calculate the next generation, Then the cell is dead.
Given a live cell with two or three live neighbors, When I calculate the next generation, Then the cell is dead.
Given a dead cell with exactly three live neighbors, When I calculate the next generation, Then the cell is alive.

Since any given rule could only have 9 different cases (0-8 alive neighbors) I decided that, rather than deal with the logic of "less than"/"fewer than"/"exactly", I would spell out every specific condition that meets a rule.

JBehave expects scenarios to have separate lines for Given, When, and Then. Rule #1 can be completely expressed as:

Scenario:
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead

Scenario
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead

I've written the variables in the scenario in bold here. That will become more clear later. I inserted "Rule 1" into the given just to make it easier to know what rule I'm on when a scenario fails.

I wrote scenarios for every condition for all 4 rules (it came out to 18) and put them in a file named "i_can_calculate_the_next_generation". JBehave requires scenarios be named all lower case with words separated by underscores. You can see all the scenarios and all the source code in my github repo for this project.

(If you're a Windows developer and you don't like the idea of files without extensions, I found a blog post that showed a customization that allowed JBehave to read ".scenario" files instead of files with no extension, but I decided not to bother with that for this first experiment.)

Once I have my scenarios written, it's time to code. JBehave requires that the class corresponding to the scenarios be the same words, but camel-case, and without underscores, so I created ICanCalculateTheNextGeneration.java

The entire class is:

import org.jbehave.scenario.Scenario;

public class ICanCalculateTheNextGeneration extends Scenario {
public ICanCalculateTheNextGeneration(){
super(new RuleEngineSteps());
}
}

Now for the meat of the code, starting with the implementation of RuleEngineSteps:

@Given("Rule $ruleNum: $aliveVal cell with $aliveCount neighbors")
public void aliveOrDeadCellWithPossiblySomeAliveNeighbors(int ruleNum, String initialLiveState, int numberOfAliveNeighbors){
ruleEngine = new ConwayRuleEngine();
cell = new Cell(initialLiveState.equals("alive"), numberOfAliveNeighbors);
}

@When ("I calculate the next generation")
public void iCalculateTheNextGeneration() {
ruleEngine.CalculateTheNextGeneration(cell);
}

@Then ("the cell should be $resultingAliveState")
public void theCellShouldBe(String expectedAliveState){
String actualAliveState = "alive";
if (!cell.isAlive()){
actualAliveState = "dead";
}
Assert.assertEquals(expectedAliveState, actualAliveState);
}

Look for a moment at how variables are used between the scenarios and the code. Remember I had: "Then the cell should be dead"? Look at the corresponding @Then in the code:

@Then ("the cell should be $resultingAliveState")
public void theCellShouldBe(String expectedAliveState){

Whatever I want as variable in the scenario, for example dead above, I name a variable starting with "$" in the attribute line and use the same name (without "$") as the parameter to the method.

Cell.java is basically only setters and getters. ConwayRuleEngine.java is where the business logic lives (Excuse the pun). Initially, CalculateTheNextGeneration() will do nothing.

When I run ICanCalculateTheNextGeneration.java as a JUnit test in Eclipse. I get a red bar. In the console I see:

(i_can_calculate_the_next_generation)
Scenario:
Given Rule 1: alive cell with 0 neighbors
When I calculate the next generation
Then the cell should be dead (FAILED)

and other failures. All that's left is the implementation of the business logic, which I'll leave as an exercise for you. (Or you can look at my code).

Once I got my code working, I refactored it. I've tried to reduce duplication and make the code very clean. I'd appreciate any comments you have.

Finally, I invite you to check out the Agile Skills Project, a non-commercial, community-based project which aims to establish a common baseline of the skills an Agile developer needs to have, skills possibly including TDD and BDD.

---------------------------
*A plug for CodeRetreat if you're not familiar with it: Patrick Welsh and Corey Haines have created a kind of one-day coding dojo that gives software developers who want to improve their craft a chance to practice agile skills like Pair Programming and TDD. We do 40 minute iterations on Conway's Game of Life, have mini-retrospectives, throw out our code before the next iteration, and have a retrospective of the whole event at the end of the day. CodeRetreats have been held in Java and Ruby (that I know of) and in several countries. If you haven't been to one, I encourage you to go to one.

Why do we Pair Program?

2010-03-03T21:44:00.013-05:00

One of the most controversial agile practices has to be Pair Programming. Matt Wynne has a blog post that lists several personae and why they don't want to pair program. It's a preview of what he presented at Agile 2009.

Other people have written about the benefits of successful pair programming, which is an after-the-fact analysis. Right now I'm going to look at why we pair program, which is about intention

I recently started thinking about why we pair program. What is our intention in using this practice? I came to the conclusion that Pair Programming promotes many of the Seven Skill Pillars named by the Agile Skills Project.

Pillar: Collaboration
Pair programming is specifically listed as a skill of the Collaboration pillar, but it also supports Collective Ownership by preventing silos of knowledge (technical or domain knowledge) from forming.

Pillar: Technical Excellence
Working directly with another developer reinforces good development practices, and two sets of eyes on code lets fewer mistakes make their way into the product.

Pillar: Self Improvement
Pair programming sets a tone for a culture of continuous learning by creating ongoing opportunities for co-mentoring.

Pillar: Supportive Culture
The transparency around each developer's skill level that comes from programming in front of each other gives a developer an opportunity to be tolerant and encouraging, knowing they will receive the same treatment in return.

Pillar: Confidence
By supporting each other in the practices of Continous Integration and Test-Driven Design, and by having a design and implementation that is jointly created, a pair can know they are producing quality code.

CodeMash Precompiler Session # 1 - Ruby Koans

2010-01-16T17:24:00.010-05:00

As I mentioned in my last post, I recently returned from CodeMash 2010, where I attended two PreCompiler sessions. For the morning session, I attended "The Ruby Koans, Learning Ruby One Test at a Time with Joe O'Brien and Jim Weirich" which taught Ruby syntax and how to write tests in Ruby. (Joe also gave an excellent and extremely popular talk called: "Refactoring the Programmer"

The word "koan" comes from Zen Buddhism. As I understand it, Jim and Joe called their talk "Ruby Koans" because of their unique style of teaching that relies as much on mystery and intuition as it does on rational thinking.

Jim has asked participants in the CodeMash session to show the koans to someone else, so I encourage you to look at them. You can try the koans yourself as follows:

(1) Have a working version of Ruby:
- Windows: Install from: http://rubyforge.org/frs/download.php/66871/rubyinstaller-1.8.6-p383-rc1.exe
- Macs: OS X comes preloaded on Macs so you are ready to go.
- Linux Users: Use apt-get, or whatever is appropriate for your system

(2) Download the Ruby Koans and install into a working directory:
- http://cloud.github.com/downloads/edgecase/ruby_koans/rubykoans.zip

The file README.rdoc is a text file that explains the concept, tells how to get started, and gives contact information.

To set up for the exercise: unzip the koans, open a command-prompt, and cd to the directory containing the koans. The exercise starts at the most simple level possible, but if you complete the koans, you will learn most of the Ruby syntax and see examples of how Ruby behaves at edge cases.

To start the exersise, give the command:

ruby path_to_enlightenment.rb

You should see the following result:

Thinking AboutAsserts
test_assert_truth has damaged your karma.

You have not yet reached enlightenment ...
is not true.

Please meditate on the following code:
./about_asserts.rb:10:in `test_assert_truth'
path_to_enlightenment.rb:28

The line " is not true." gives a hint as to why the test failed.
The line after the "Please meditate..." line tells what line of code the test failed on.

Looking in the file about_asserts.rb around line 10, we see:

def test_assert_truth
assert false # This should be true
end

In Ruby, def/end declares a method, and the word: "test_" at the start of the method name declares it as a test. The comment is a hint from Joe that the test fails, in this case rather obviously, because it is asserting false. So this koan demonstrates the a test in its simplest form, one that asserts a boolean condition. If you change false to true and run "ruby path_to_enlightenment.rb" again, that test will pass and the error you will see:

Thinking AboutAsserts
test_assert_truth has expanded your awareness.
test_assert_with_message has damaged your karma.

You have not yet reached enlightenment ...
This should be true -- Please fix this.
is not true.

Please meditate on the following code:
./about_asserts.rb:16:in `test_assert_with_message'
path_to_enlightenment.rb:28

So now the test_assert_truth test passes and the test_assert_with_message test is failing. The code for the second test is:

def test_assert_with_message
assert false, "This should be true -- Please fix this"
end

and we see where the "This should be true..." message comes from. Joe has now shown us what an assertion with an error message looks like. Again change false to true, rerun the ruby command and you'll see the next failing test.

The koans go on to present illustrations of control statements, hashes, scope, strings, arrays, inheritance, iteration and others language details. I don't think anyone at the PreCompiler finished all the exercises during that session - I sure didn't - but it's clear that I will know a lot about Ruby syntax when I do.

Finally if you have questions about the koans, you can reach Jim at his website http://onestepback.org/ or @jimweirich on Twitter. Or you can reach Joe at his website http://objo.com or @objo on Twitter

Back from CodeMash 2010

2010-01-16T16:39:00.004-05:00

I just got back from a great experience at CodeMash 2010. This was my first CodeMash, and it will certainly not be my last. If you're a software developer and you've never gone to a CodeMash, I can't recommend it enough. (If you're a developer and you've already gone, I don't have to say anything because I know you'll be going back.) Besides all the technical goodness, there was lots of fun!

If you're not familiar with CodeMash, its home page describes it as a unique two (or optionally three) day event:

"... that will educate developers on current practices, methodologies and technology trends in variety of platforms and development languages such as Java, .NET, Ruby and PHP. Held [in] January, at the lush Kalahari Resort in Sandusky, Ohio, attendees will be able to attend a world-class technical conference amid Ohio's largest indoor waterpark.

There were also sessions on career development, TDD/BDD, Agile/Lean/Kanban methodologies, dynamic languages like F# and Scheme, development for mobile platforms like iPhone and Android, and too many more for me to list here. See the session list for more, and for detailed writeups and presenter bios.

This year, there were three keynote addresses and loads of software-development-related sponsors, the likes of Microsoft, Amazon, Compuware, RedGate, and ComponentOne gave talks, demonstrations, held raffles and gave away lots of swag.

But some of the most valuable experiences come from talking with other developers in the hallways, between sessions, at open space meetings organized by participants based on their interests, in the Coding Dojo room, and at the cocktail party.

I mentioned that CodeMash is two or optionally three days. They call the optional third day events, held the day before the official conference opens, the PreCompiler. The PreCompiler Sessions are 4 hour, hands-on, interactive labs. That's not to say that if you only attend the main conference you won't have a chance to sit down at a machine and try somethings out, but interactive sessions at the main conference are shorter (only about an hour) and tended to be less in-depth.

I attended 2 PreCompiler sessions, "The Ruby Koans, Learning Ruby One Test at a Time with Joe O'Brien and Jim Weirich" and "Practical T/BDD - Half Day Hands-on Lab with Phil Japikse"

I'll tell about these in subsequent blog posts.

Grand Rapids CodeRetreat ... but it's in Ruby

2010-01-11T14:18:00.006-05:00

I'm a big fan of CodeRetreat. Besides being a fun day, it's a great way to practice agile things like: pair programming, supportive environment, software craftsmanship, TDD, retrospectives, courage, and so on. I think they are great events for both aspiring Agilists and experienced Agilists.

I read Jeremy Anderson's blog post about an upcoming CodeRetreat in Grand Rapids. I was all set to go when I read that it will be held in Ruby, and since I haven't used Ruby, I was discouraged. As much as I'd like to try it, I'm not sure how much time I'll have in my schedule before then.

Then I found TryRuby. It offers an interactive Ruby prompt and a follow-along tutorial, right in your browser! And there's another tutorial I found, Ruby in Twenty Minutes .

So I guess I'll have to revisit the sessions I planned to attend this week at CodeMash 2010 and see if there are beginner Ruby sessions. Perhaps, between them and some extra work during downtime, I'll pick up enough Ruby to feel comfortable attending the Grand Rapids Code Mash next month.

What is agile communication?

2009-11-23T12:28:00.004-05:00

In thinking about some things for the Agile Skills Project, I realized that agile teams communicate differently than non-agile teams.

It seems to me that agile communication aims to be:

public (vs private or secret) [public within the entire team, not public as in news media]
early (vs delayed)
spoken, preferably in person (vs email)
free from judgment (vs assigning blame)
osmotic (vs selectively broadcast)
flat (vs hierarchical)

A significant enabler of agile communication is the Supportive Environment Agile Pillar.

What characteristics of agile communications do you notice?

Why we say: "No Best Practices"

2009-11-16T09:27:00.004-05:00

I came across an great article from 2005 titled: No Best Practices and it reminded me that there was some discussion about the term "best practice" at the recent 1DevDay event.

Besides speaking to reasons why we say there are no best practices, James Bach gives a nice list of "simple, honest alternatives":

“Here’s what I would recommend for this situation.”
“Here is a practice I find interesting.”
“Here is my favorite practice for dealing with {x}.”
“{Person X} attributes {practice Y} for his success. Maybe you’d like to learn about it.”

as well as a list of answers to common replies to his argument, replies like:

“I don’t mean ‘best practice’ literally. I’m just suggesting that this is a damn good practice.”
“When I said this practice is a ‘best practice’ I meant it was best for a certain context. But pretty much everyone in the industry shares that context, so what’s the point of talking about context?”
“This practice represents a consensus among industry leaders.”
“Lighten up. It’s just an expression.”

It really helped me get clear about why we say: "No Best Practices".

My (growing) Agile Booklist

2009-11-15T23:55:00.003-05:00

In no particular order, here are the agile books currently in my bookcase:

Practices of an Agile Developer, by Venkat Subramaniam and Andy Hunt
Clean Code, by (Uncle) Bob Martin
Refactoring: Improving the Design of Existing Code, by Martin Fowler
Test Driven Development: By Example, by Kent Beck
Working Effectively with Legacy Code, by Michael Feathers
Agile Principles, Patterns, and Practices in C#, by: Martin C. Robert & Martin Micah

CodeRetreat 12-5-09 LeanDog

2009-11-15T23:16:00.005-05:00

I'm looking forward to attending CodeRetreat 12-5-09.
It's a free event, sponsored by and held at LeanDog. If you aren't familiar with the idea of a Code Retreat, as promoted by my friend Patrick Wilson Welsh, take a look at his description here.

Briefly, it's an event where agile software developers get together and pair program several solutions to a practice program, with the goal of honing our craft and furthering learning and discussion (Think software kata.) The event hits 5 of the 7 agile skill pillars proposed by the Agile Developer Skills Project:
* Collaboration
* Supportive Culture
* Confidence
* Technical Excellence
* Self-Improvement

I attended the previous LeanDog CodeRetreat and it was great! Lots of talented developers, great practice and learning, tech talks and a party-like atmosphere.

LeanDog's location is amazing. Their website describes says:

Our office is floating in downtown Cleveland right next to the U.S.S. Cod (a WWII Submarine), the Burke Lakefront Airport, and the Rock and Roll Hall of Fame. We are located on a converted steamship, the Keasarge, that was formerly known as Hornblower’s Barge and Grill. The restaurant setting remains and offers open spaces that are perfect for practicing Agile. Our location gives a great view of the skyline of the city we support.

We'll be coding in Java again, but if you want to learn or practice pairing and you don't know Java, don't let that stop you. That was my situation last time and it was still a great experience!

CodeMash 2010

2009-11-15T21:37:00.012-05:00

I've registered for CodeMash 2010
January 14-15, 2010 in Sandusky, OH

There are several agile sessions scheduled:

- Agile Iteration 0 by Ken Sipe
- An Agile Toolchain for Flex RIAs by James Ward
- Credit Crunch Code – Time to Pay Back the Technical Debt by Gary Short
- Domain-Driven Design: An Introduction by Barry Hawkins
- Seeing Constraints, Kanban Explained by Jon Stahl
- Testing the Enterprise by Leon Gersing and Charley Baker
- User Stories: Closing the Agile Loop by Barry Hawkins

Wednesday is an optional Precompiler session(full registration required to attend). The agile topics that day are:
- Practical T/BDD - Half Day Hands-on Lab by Phil Japikse
- Test Driven Development: From Concept to Deployment with Leon Gersing (all day)

There are loads of sessions that aren't specifically about agile but look great anyhow. According to the CodeMash site:

More than 45 sessions will be held, spread across the following tracks:

* Architecture: SOA, W3C Standards, WS* Implementations, Interoperability and all things 30,000 foot or higher.
* Desktop Development: Standalone Applications, Fat/Smart Client, Client/Server and all things running local on Windows, Mac or your favorite Linux distribution.
* Web Development: Web services, Ajax, frameworks, and all things related to the browser.
* Methodologies: Anything pertinent to how modern development methodologies help build software faster, cheaper, and with less grief.
* Mobility: All things mobile: platforms, devices, content distribution, social networking, community building, and anything else used in conjunction with those devices which have little screens.
* Languages: What's new and cool in languages such as C#, Java, PHP, Python, PHP, Ruby? Of course there are other languages which we've omitted from this list for reasons of space but don't mean to offend their feelings.

and since one of the seven pillars is Self Improvement, why not attend and check out what interests you or what you think might help your team? And the cost for the conference is very low (see below.)

Details:
CodeMash 2010 will be held January 13-15, 2010 in Sandusky, OH at Kalahari Resort, America's largest indoor water park

Early Bird discount $175 until Nov 30
Regular $220 until Jan 7, 2010
Procrastinator $300

1DevDay Detroit

2009-11-15T20:51:00.005-05:00

Yesterday, I attended a great event, 1DevDay Detroit. It was put on by the Detroit Java User Group, generously hosted at ePrize, and sponsored by too many companies to mention here. The day was amazingly affordable ($40) and, I think, a great success - especially given that it is a new event. There were a few minor hiccups, mainly around timing talks, but they didn't impact the overall quality of the day.

While 1DevDay was not specifically an agile event, there was much agile activity, including:

- Venkat Subramaniam's excellent and funny keynote, "Facts and Fallacies of Everyday Software Development"

- Chet Hendrickson's talk about the Agile Skills Project, a non-commercial group created to quantify skills needed by agile software developers and identify valid means of assessing skills, trainings, and books.

- Nayan Hajratwala's interactive session on refactoring legacy code with no tests and gradually adding and increasing test coverage to the codebase.

There was also a twitter hashtag, #1devday, where participants posted thoughts and comments. Check it out to get a picture of what the day was like.

Just as fun was meeting and talking with other developers, many of whom are using at least some agile practices.

I'm already looking forward to next year's event!