I used git a little bit a few years ago, and initially it was a painful adjustment because all my past experience was with centralized repositories like Subversion, Team Foundation, and CVS. Distributed repositories were a paradigm shift, but after some getting used to it really started to grow on
me. I loved home easy it was to create branches and that developers could work on different features in isolation before bringing their code back into the “trunk”. So it was great to get some code up on github, using both the RubyMine integration and plain old git command line tools. I need to spend a little time refamiliarizing myself with the terminology and workflow, but it was a great start.

As far as the kata goes I feel similarly. Did everything turn out exactly the way I wanted? No, but it is a kata. You do it, you learn something, you take those lessons forward, and you move on. Maybe I will do it again in a few weeks and see how the outcome is different. It served it’s purpose in getting me out of my comfort zone and writing code in a new language. It also got me asking new questions and places to take the journey. Some of the things that I wondered about as I was doing the kata

• Does Ruby have the philosophy that there is one “right and obvious” way to do things, ala Python, or is it more Perl-like in that there are a many ways that are acceptable and it is a developer choice. At least according to this page it seems to borrow from Perl in that there is more than one way to do it.
• How do private and protected variables/methods work in Ruby?  Are they often used or are there other patterns that are applied?  I remembered with Python that the notion of “private” was downplayed, at least with what I saw. I am not a Python expert so I may be mis-representing here.
• Are instance variables used much?  In one of my refactorings I noticed that I was passing the same argument to a lot of methods, and decided to keep it in an instance variable. Was that Ruby-esque? Was it habits from .NET creeping in?  Was it the “best” solution

I don’t know the “Ruby Way” yet, so these questions are all the more reasons to start looking at OPC (other people’s code). So it is probably time to fork a Ruby open source project and start playing around with it.

I want to make sure I keep writing code too, so I think I will take a time-boxed stab at Conway’s Game of Life. I had a lot of fun with that at the Global Day of Code Retreat. I want to time-box it because it is something that I could spend a lot of time on, depending on how far I want to take it, and I am not looking for a complete solution but to exlore some different ideas in code. Maybe it’s time to start thinking about bring Rails into the mix too.

All these ideas make me think I should be keeping a formal backlog and continuing with the notion of treating this journey as an Agile project. I use a tool called Rally at work, maybe I’ll use that or investigate another tool. Any ideas or recommendations from the blogosphere?

1. What did we do well
2. What can we improve on
3. What are we going to focus on in the next iteration to improve the process or the product

I am a team of 1 on this journey, so “we” is me.

What Went Well

• Digging the Ruby Koans – I’m happy that I am not just blowing through them to get to the next subject, but asking questions when something doesn’t make sense or surprises me.  I also find myself adding additional tests to experiment with behaviors
• Love playing around in the IRB  -  This also has a lot to do with experimenting and following where my curiosity takes me.
• Got a Ruby environment set – OK, so it is not the shiny new Mac I wanted, but RubyMine on my Windows laptop has been a very low-friction experience.  The Mac will come.  I have a birthday coming up and maybe I will be good to me.

What Can Be Improved On

• Not writing enough code - Although I am learning with the Ruby Koans, I am not writing enough code.
• Making really good progress, but need to dedicate more time – I’m happy with where I am, but the time goes by quickly.  May need to dedicate just a little more time on a weekly basis.
• Haven’t done anything with github yet – One of the goals was to set up a github account.  Technically I have satisfied that criteria because I have an account…an empty account.  That needs to change

• Do the String kata in Ruby – It’s a pretty straightforward problem, one that I have done in C# and C++, and this will get me actually writing code
• Put the String kata in github, committing as new functionality is added.

I am staying with the Ruby Koans for now, I really enjoy the layout as I learn the basics of the language and it’s syntax.  To this point I have covered asserts, the notion of nil (it really is an object), objects, arrays, hashes, strings, symbols, and my favorite…regular expressions.

I have a love-hate relationship with regular expressions.  Unlike many programmers who may deal with a lot of text, in my world of medical devices and laboratory automation I don’t need to rely on regex all that much.  To paraphrase the most interesting man in the world, “I don’t always use Regexp, but when I do, it is a powerful, painful, awful, and wonderful experience….every time”.

Things that I have found interesting or noteworthy about the most recent koans:

• Array slicing and hashes feel a lot like Python.
• The PERL-inspired “flexible quotes” are interesting and easy to use
• I had a WTF moment with the shovel operator “<<” versus “+=”, but I am not alone there.  After Googling around it made sense and this article about the performance differences was a real eye opener.  I imagined “<<” would be faster than “+=”, but wow!
• I want to play around more with heredocs.  Again, nothing Earth-shattering, just not something I have used in my day-to-day programming.  Can see where this would make working with text a lot easier

I was a little confused about Ruby symbols at first.  How do they get “initialized”, how do you use them, why don’t they take an “=”, what can you do with them once you’ve got them.  After some Googling, things were starting to take shape, but I was still not perfectly clear on them.  But wait….

Off to the REPL

NB: I realize if SOPA were to pass as is I could go to jail for this Dangermouse cartoon, but it is such a hack job by me, maybe I should…

I really love the ability to play around with ideas in a REPL.  Verdammelt had an interesting article about using a REPL and TDD and this seemed like a perfect place for some experimentation.  I was able to pretty quickly satisfy my curiousity and questions about Ruby symbols in the IRB.  I thought it was neat how one answer may lead to another question and so on…very exploratory.

Which brings us to the aforementioned regular expressions.  Some people love regular expressions.  Some people can whip a regex out of thin air to find the middle names of everyone with a blue house, between the ages of 38-43, with 2 dogs OR 1 ferret and 3 parrots.  I am not one of those people.  I always liked this joke

Some people, when confronted with a problem, think
“I know, I’ll use regular expressions.”   Now they have two problems.

But interestingly I had an “a ha” moment while doing the Regexp exercises.  It wasn’t some “the skies opened and I know all Regexp syntax by heart now”.  That unfortunately did not happen.  It was that it reinforced this notion of TDD:

A well-written test suite IS documentation.

A well written test suite IS a specification.

I love that about TDD and it is one of the reasons I am having so much fun with the Ruby Koans.  Every test clearly expresses a single, intended behavior.

Stay tuned for a retrospective on the first iteration, and if you have tips on good Ruby resources I would love to hear them.

Lao Tzu said “a journey of a thousand miles begins with a single step”.  So as much as I would like to embark on this voyage on a shiny new Mac, running TextMate as my editor, I will stick a little closer to my comfort zone and start out running RubyMine on my Windows machine.  As a .NET developer, I am pretty entrenched in the IDE experience.  That is not to say I don’t want a shiny new Mac, but I also don’t want to get bogged down as I learn a new language.  The RubyMine experience is very familiar to me since I use Visual Studio with Resharper and for a mere $69 for a personal license it seems like a no-brainer.

So where to start….

I scoured various blogs and the Ruby docs for good places to learning Ruby.  I settled on starting with the Ruby Koans site.  I really like that this tutorial had a test-centric approach.  One of the draws to exploring the Ruby community is that testing is baked into the culture.  The Ruby Koans allowed for a lot of experimentation and I tried to take the approach of not just blowing through the problems, but really asking what are they trying to teach in this lesson.  I tried to cause tests to fail in different ways and added some scenarios of my own to try and investigate further.

Another resource was to just use IRB, the interactive Ruby shell.  Nil is an object, huh?  What methods does it have.  I suppose I could pore through documentation or maybe just…let’s see if this works

irb(main):001:0> nil.methods
=> ["inspect", "&", "clone", "public_methods", "display", "instance_variable_defined?", "equal?", "f
reeze", "to_i", "methods", "respond_to?", "dup", "instance_variables", "__id__", "|", "method", "eql
?", "id", "to_f", "singleton_methods", "send", "taint", "frozen?", "instance_variable_get", "^", "__
send__", "instance_of?", "to_a", "type", "protected_methods", "object_id", "instance_eval", "==", "=
==", "instance_variable_set", "kind_of?", "extend", "to_s", "hash", "class", "tainted?", "=~", "priv
ate_methods", "nil?", "untaint", "is_a?"]
irb(main):002:0>

Good gravy, so simple even a .NET developer like me can do it  I found myself playing a lot in the IRB when I wanted to just try something out.

I got though the basics of asserts, objects, nil, and arrays with the koans, diving over to various websites, StackOverflow, irb, and the Ruby core docs as I ran into questions.  I am using the Pomodoro technique to timebox my activities into manageable chucks and try to stay fresh.

The plan for next time will be to continue with the koans, probably for a while, to build up some core knowledge.  At some point I will dive into the Koans code itself as one of the goals of the last post was to read more code as well as write it.

In my experience, the best way to learn code is to write code, but I also reserved the following books from the library to have around as  references and for tips on style.

• Programming Ruby (aka the pick-ax book)
• Ruby Best Practices
• The Ruby Way

I also want to take a peek at Why’s (Poignant) Guide To Ruby

1. Set Up a GitHub Account – Really?!?!  It is the tail end of 2011 and I don’t have a GitHub account.  More and more it seems to matter less and less what is on your resume.  Show me what you’ve done.  Show me you can collaborate and play nice with others.

2.  Learn Ruby – I don’t mean dabble in Ruby.  I don’t mean write “Hello World” in Ruby.  I don’t mean write C# style code with Ruby syntax.  I’ve done that and it hasn’t mattered much.  Learn to write Ruby style code in Ruby.  Why?  Because maybe it will make me a stronger developer across the board by introducing me to different ways to write code and solve problems.  I also think the Ruby community as a whole are strong proponents of software craftsmenship.  Or at least the ones I run into are, and that can only be a good thing.

3.  Write More Code – The last few years I have spent a lot of energy working with Agile practices, and especially trying to help the teams I am on be more productive and write better, well-tested code through practices like pairing and TDD.  I am very proud of the end results, but a side effect of that has been that I write less code on a day to day basis.  That may require being creative and looking for new opportunities to write code outside of my day job.  But I really miss the challenges of solving technical problems on a regular basis.

4.  Read More Code – Participating in the Global CodeRetreat was a great opportunity to work with a lot of developers, all with different experiences and skill levels.  Being an experienced developer is great, but there is so much to be learned from seeing how other people solve problems.  Instead of just downloading some open source tool that makes my life easier, peek under the covers, run the tests,  I don’t know…maybe even contribute to the project.  At the very least get some new ideas.

5. Get Out of My Comfort Zone – Over the years I have developed a set of skills and practices that work well for me and that I have been successful with.  I wouldn’t say it is easy, but it is a little safe.  I have experience with problem domains I work in, I am comfortable with the languages I use, and I have developed a set of practices that are well ingrained in me.  That’s all well and good, but there is a potential for a lot of growth to be found outside your comfort zone.

6. Buy a Mac - Windows and Microsoft have been good to me, and I have used Windows for work for the past 20 years or so.  I will probably still do my day job work on a Windows machine, but in the spirit of learning new languages and getting out of my comfort zone, maybe it is time to see how life is from the other side.  I could do all these things on a Windows box, but it’s time for a little change.  Plus I can hang out with the cool kids at developer events.

So I am seeing a theme here for 2012.  Hopefully I can make it all happen.

Have a safe and happy new year!

For those not familiar with the CodeRetreat concept, the day was broken up into several pair programming exercises, with a strong focus on Test Driven Development (TDD).  The exercises were centered around Conway’s Game of Life, a simple enough problem to understand quickly, but with a domain that still allowed for a variety of challenges and corresponding implementations.  There were several  languages represented at the Cambridge retreat: Java, Scala, Clojure, Ruby, C#, JavaScript, Python, PHP,  and probably a few others.

The first exercise was a simple pairing exercise with no rules other than to meet your pairing partner and get into te swing of things.  It was a good start up exercise.  I paired with a guy named Mark, and we did the exercise in C#.  We made a few classic mistakes like getting ahead of ourselves with the design, but we did a good job of keeping each other honest and quickly got back on track.  I enjoyed the session a lot, and the 45 minutes went by quickly.

For the next challenge, I wanted to try a different language.  I have been very interested in Ruby and sought out a partner who could give me a good intro to the language.  The exercises were ratcheting up a bit, and the goal of this exercise was to make your code as clear and expressive as possible.  Good naming, clear and concise tests, good design were the goals here, and Ruby did not disappoint in that regard.  You can program cleanly or poorly in any language, I have probably done both in my years of development, but Ruby seemed to allow a clear design in a minimalist style that read very well.  Alex was my paring partner for this exercise and he was very helpful in explaining some of the nuances and conventions in the language.

For the third challenge, we got into an odd constraint.  Your code could not have any exposed primitives.  Excuse me!?!?!  No bools, ints, strings, lists.  Um…aren’t these sort of key to programming…isn’t that why the are called primitives.  But staying in the spirit of the day, this is a chance to try new things and see where the exercise takes us.  Keeping with my goals for the day to try some different languages, I paired up with someone to do some Scala.  Working without primitives was a challenge, you needed to come up with some potentially contrived abstractions, but it got you thinking.  I had seen some Scala at the VT Code Camp, and was eager to see it in action, but unfortunately, Don and I had some start-up problems getting going with Scala, so  I don’t think I saw it at its best.  I was glad I tried it though and maybe I’ll have better luck next time.

During a break for lunch, where we also saw a really wild example of the Game of Life in APL.  I used APL exactly once when I was in studying Chemical Engineering at UMass back in the day.  I had a hairy matrix problem and someone said, you know what’s really good for matrix calculations…APL.  He was right, but wow, it is not like anything I had used before or since.  We all got a good laugh out of the exercise, because of the ease at which the author solved the problem and how unfamiliar it was to our normal lives as developers in other languages.

In the afternoon, I paired up with Abby Fichtner, the Hacker Chick, for an even more challenging exercise.  This time, not only no primitives, but no conditionals either.  That means no ifs, no ternary operators, etc.  This required even more creative ways to solve the problem.  Where as before you could make a decision on the live/dead state of a cell by asking “if the number of neighbors is….”, that was not an option in this exercise.  We decided to make an array of states that we could index into based on the number of live neighbors a cell had.  We banged our heads a lot trying to figure out how to solve a problem without conditionals, but we had a lot of fun and had to think creatively to come up with what might otherwise be a straightforward problem.

Next up was a silent pairing exercise.  In other exercises, the pairs switched often between who wrote the tests and who wrote the code, but in this exercise, one person was the designated test writer and another was the designated implementer.  The exercise was intentionally adversarial, as the test writer was instructed to write tests that poked holes in the design.  It was a lot of fun to see the interaction between pairs, especially the two guys who were sitting across from me.  You could see that it was a real tennis match, with each person returning the volley of the other.  Someone jokingly (I hope) commented that he learned that talking was overrated and he hoped to do it much less in the future.

The last exercise was to do the best design you could, with no other constraints.  I wanted to try Java, so I paired up with Tarish, who kindly helped me re-remember Java.  I learned Java about 10 years ago, but haven’t done much since then.  It’s a short walk from C#, but my brain was beginning to fuse and I don’t think I put my best foot forward with Java.  Tarish was really helpful, and I enjoyed the conversations we had about Agile and TDD as we went along.

We wrapped up going around in a circle, answering 3 questions: what did we learn, what were we surprised about, and what would we do differently.  For me I learned that Boston Software Craftsmanship is a really good group.  If you are in the Boston area and you want to improve your software engineering skills you should check them out.  I was surprised at how much fun I had working with the constraints like no conditionals and how it made me have to think more creatively.  And for what I would do differently, as much as I wanted to try new languages, in some cases that got in the way of fully experiencing the challenges and constraints, so next time I will brush up on languages I am interested beforehand and try to stay in some amount of familiarity/comfort zone.

To sum up, met some great people, programmed in 4 languages (C#, Ruby, Scala, and Java), and thought hard about different ways to solve problems.  Looking forward to doing it again.

I can’t type to save my life.  I’ve been writing software for over 20 years and have managed to get by with hunting and pecking with 3-4 fingers.  And that worked fine, working alone in my little cubicle…until pair programming came into my existence.

I love pairing.  The back-and-forth flow of ideas, the continuous discovery and refactoring, the changing roles between driver and navigator. I think it is one of the greatest improvements in how software engineers work that I’ve seen over my career.  But it sure helps to be able to type.

So I am going to do something about it.  Inspired by an old Corey Haines post I am declaring my own personal Learn to Type week.  Corey’s post has some good links to help you improve your typing skills.  This post had a few more.

So for 30 minutes a day for the next week I am going to try and bring my typing skills up to a respectable, pairing-worthy level.  I’ll keep you posted.

Update: After a week, I have to say it is slow going.  I have been doing exercises from this post, and although I like the lessons a lot I am struggling to complete the lessons in 60 seconds.  At times I fly, error-free, then I think about how well I am doing, then I start to think about what keys are where, and then everything goes hay-wire.

This will take more than a week to learn, but I am committed to seeing it through.  Right now I am still much faster with my 3-fingered typing, but if I stick with it I think it will pay off in the end.

The first session I attended was Dane Morgridge’s talk on ASP.NET MVC3: A Gateway to Rails. I was really interested in this talk, because as a TDD junkie, I was curious if part of the “gateway to Rails” involved embracing testing. I still feel like the .NET community is behind the curve on TDD and BDD, and I wanted to hear Dane’s perspective on making the switch from .NET to Rails. His presentation was very much an overview of the goodness in Rails and ASP.NET MVC3, like convention over configuration and how having a separation of concerns with MVC allows for a more testable system. Afterwards I was able to catch up with Dane between sessions and he showed me a few things he is doing with Cucumber and BDD. I have to say the readability of Cucumber makes it look very appealing and we talked about how BDD tests can be more maintainable than TDD/unit level tests. There is a right time to use one and the right time to use another.

Next up was David Howell’s Tackling Big Data with Hadoop. I knew very little about Hadoop, but had heard a few good things about it and was looking to learn a bit more. David’s talk focused on using Hadoop’s Map-Reduce capabilities to handle large data sets. We also talked a bit about what constitutes “big data”. If you are not familiar with Map-Reduce, check out Google’s 2004 paper on it. David went over the basics of a hadoop cluster and showed how it could be used in a distributed architecture to tackle a big data set. He also touched on how some of the fault tolerance could be implemented using the cluster and distributing the same job to multiple nodes. To wrap up he ran a simplified Map-Reduce demos on a small data sets that was appropriate scaled for the time that we had available.

I would have to say the third session was one of my favorites, Functional Programming on the JVM. This talk was given by Jonathan Phillips and another developer named Jack (sorry Jack, missed your last name), both from Dealer.com. As someone who has spent the last….well lets just say a lot of years doing OO programming, I struggle with the shift to functional programming, especially when state and immutablility come into play. I have been to several functional programming and F# presentations that have left me confused, but 5 minutes into their talk Jonathan and Jack went over closures and recursion as they apply to functional programming and it was like a light going off. Suddenly immutability made more sense. After the overview of functional programming they went into 3 different languages that can be used to do functional programming on the JVM: Groovy, Scala, and Clojure. The used a simple example, comparing the amount and clarity of code that you would write using pure Java versus each of the 3 other languages. They also went over some of the pro’s and cons about Groovy, Scala, and Clojure. It left me with a lot to think about, and I am eager to experiment with all 3 languages.

Another great talk was Free and Open Source Software (FOSS) in the Enterprise by Kevin Thorley, also from Dealer.com. Kevin laid out what you need to consider using FOSS software. What is the community support, how many contributors are there, how robust is it, how easy is it to use and what documentation exists, do you really need it or do you want to use it because you just read some great blog post about NoSQL. One thing that Kevin said really rang true when he said that open source is not free and that we need to understand and accurately assess what the cost is to use and maintain it. Kevin went over how they use MongoDB, RabbitMQ, Spring, and Solr at Dealer.com. Don’t misinterpret Kevin’s statement about it not being free. Obviously they rely heavily on FOSS at Dealer.com, but you have to be honest about why you are using it and what is the cost going to be to your organization to use “free software”.

I give a lot of credit to the guys from Dealer.com for their participation at the code camp. They are a Burlington based company and they had a significant presence at the code camp. It is one thing to say that you are passionate about software, it is another to do something about it. Developers from Dealer.com did 4 of the 26 total sessions. I followed up with a few of them after the sessions and you can tell they are really into the technologies that they were presenting.

The last 2 presentations were familiar ground for me, but I still learned a few things. Vincent Grondin’s talk on mocking and mocking frameworks. Vincent gave a very good discussion of mocking and the two type of mocking frameworks available: those based on dynamic proxies, and those based on the .NET Profiler API‘s. Examples of frameworks based on dynamic proxies are Moq and NMock3. Examples of .NET profiler based frameworks include Telerik’s JustMock and Typemock Isolator. The .NET profile based mocking frameworks have some significant advantages in being able to mock out static methods and even system calls. I have been using Moq (and previously NMock2) and I have had to write custom wrapper classes to work around problems mocking static methods and system calls.

The day wrapped up for me with Josh Sled’s talk on dependency injection. Josh gave a good overview of why you would want to use DI, but also gave an honest assessment of pros and cons of using them. I think any time we decide to take on a new framework we need to understand what the cost is (similar to what Kevin Thorley said). I am a big fan of DI and IOC frameworks, but you need to be aware of what the cost is to using that framework. We touched on a few IOC frameworks that you can use like Spring (Java), Castle Windsor (.NET), and StructureMap (.NET).

All in all it was a great code camp. It is usually hard to justify spending a beautiful late summer day in the basement of UVM, but it worked in this case. I am really looking forward to all the slides being available to I can check out some of the sessions I couldn’t make.

Thanks to Julie Lerman, Rob Hale, and all the other organizers, volunteers, and sponsors for putting together a great event.

Recently our team had a story that was “done” and we took credit for the points in our iteration.  But a few days after the iteration ended there were a few more check-ins against the story.  Nobody was trying to hide anything, it was brought up at the daily stand-up, but were we really done at the end of the iteration?  No.  It reminded me of a great line from the movie The Princess Bride where Miracle Max says

He’s only mostly dead.  There’s a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there’s usually only one thing you can do…Go through his clothes and look for loose change.

Miracle Max - Early Agile Evangelist?

The Agile corollary to that is

There’s a big difference between mostly done and done-done, with done-done there’s only one thing you can do…Go through the backlog and look for new stories.

Being done-done requires that the team understands the story, that there is agreement to how it will be tested and verified.  The story should be demo-able and the product owner needs to be available to clarify questions that inevitable come up during implementation.  It also means that other parts of your software process are followed, e.g. code reviews, documentation, etc.

If your team doesn’t have a common understanding of what done means, you are in for some trouble.  There is a lot of pressure to be done, and nobody wants to take zero points for a story that had a lot of work put into it.  But a false sense of being done is worse.  You may end up building up a lot of technical debt and won’t have a sense of what your true velocity is.

Be honest and open about what your understanding of done is.  Talk about it with others on the team, address it at your retrospectives.  Everyone on the team needs to be in agreement, both in general terms and for individual stories.

The talk was targeted for all the roles on a Scrum team, and my goal was to give a small taste of what TDD can bring to a software project.  I have been using TDD for about 5-6 years, and I have definitely become “test infected”.  I can’t imagine developing production code any other way.

I wanted to stress the importance of working iteratively, and getting through the Red-Green-Refactor loop quickly, adding more and more functionality with each new test.  One of the areas new teams may struggle with TDD is to try and do too much in a single pass through the loop.  If you get bogged down and are in the loop for more than 15-30 minutes you may be biting off too much in this test and should look to a smaller incremental step.

Given the broad spectrum of roles that were at the meeting (Scrum Masters, coaches, QA/test, developers, managers, product owners) I also wanted to show how tests can be used to get the team to collaborate more.  I think tests can be a great mechanism for developers to collaborate with product owners to make sure the behavior is as intended.  There are also opportunities for QA/test to work with developers to understand what is tested at the unit and integration level.  Finally tests are a great mechanism for developers to share knowledge.  When I am looking at a code that I may not be as familiar with, I find the tests to be a great place to start to understand what functionality is provided.  In essence, the tests become an executable specification of the system.

We also spent some time talking about TDD and design, which I know has been something of a hot-button topic lately.  Does TDD guarantee a good design?  Is it a good design methodology?  In and of itself, I would say no.  But what I would say is that TDD encourages good design practices and to do it well, i.e. not have brittle tests, you need good design practices.  I had almost 20 years experience before starting TDD and felt I was a good object-oriented designer.  TDD helped me step up my game in terms of design and developing more modular, loosely-coupled code.  We touched on design practices like SOLID, YAGNI, DRY, separation of concerns, how design patterns like MVC allow better, more thorough testing.

Finally we talked about the challenges of adopting TDD.  Change is hard, and a switch to TDD can be a difficult and frustrating experience.  TDD requires strong design practices.  There is also the battle to fight about writing “all that test code”, to which I always like to ask “How much were you writing before”.  Jim Shore summed it up well when he said that you should expect 2-3 months to make the adjustment.

I had a great time at the Nashua Scrum Club, and want to thank everyone there for making it a fun (and hopefully informative) evening.  I look forward to a return visit soon.