Internet Architect by day, environmentalist by night: Jim Schwartz @ imason.
Home » What We're Thinking » Jim @ imason
In my 6+ years in the software development business, I’ve used a variety of techniques for performing developer knowledge transfers. When I hold a knowledge transfer session, I like to set my own objectives (What am I hoping to get out of the session?), familiarize myself with the objectives of my audience (What is my audience looking to achieve?), know the audience’s skill level (If I move quickly, will they be able to follow?), and I like to be familiar with the logistics (Have I booked a training room? Do I have sufficient hardware? Software is installed? Do I have Admin privileges?)
When your audience is large, the technique is much different than when the audience is small. It’s more difficult to completely engage a larger audience, so the key is to do hands-on training to ensure your audience is following along. I’ve done sessions that weren’t hands-on, but they were far less effective than the hands-on sessions, and are usually a result of time/logistics constraints than anything else.
To date, my most effective developer knowledge transfer session involved choosing 2 or 3 small feature enhancements (Or bugs), and using a “Pair Programming” approach to develop these features. This obviously works best in a pair (i.e. training 1 other person), but I think it can also be effective for training up to 3 developers. Using a meeting room on a projector, each developer would take turns writing some code. This keeps them engaged and when they aren’t writing code they stay focused because they need to know what is happening for when it’s their turn to write the code.
I feel that this is the absolute best way for new developers to learn about the code, and it’s the most rewarding way for the developer(s) who wrote the code to showcase his/her code. In addition to the learning benefits, you are also using your time efficiently by actually addressing a new feature or existing bugs. If you’re on tight deadlines, this approach allows you to keep the project moving forward while transferring knowledge at the same time. The last benefit of this approach is you can incorporate a code review into the session by getting an objective viewpoint from the developers you are transferring the knowledge to (Assuming the recipients are experienced enough to have constructive suggestions).
In summary, the benefits of hands-on knowledge transfer are as follows:
· Productivity in that the project keeps moving forward (Tight project deadlines are a reality in our industry)
· Hands-on learning for the recipients (Make sure to use proper source control in case something goes wrong J)
· Simultaneous code-review (Find all those divide by zeros)
· Better focus from the participants (Nobody falls asleep)
While working on my .NET State Machine workflow today, I ran into an issue: I wanted to send an e-mail to a user every XX days to remind them to finish filling out a form, and I wanted those e-mails to continue being sent until the form had been filled out.
At first I thought this would be a simple While Activity with a Delay Activity timer inside it, but a Delay Activity has some limitations: I originally added it to my StateInitialization Activity, but it can’t be used inside a StateInitialization Activity because it inherits the IEventActivity interface. This also means that you can only use a Delay Activity as the first Activity in an EventDriven Activity, which prevents you from putting a Delay Activity inside a While loop.
So I took a quick look at other people running into the same issue and found this user group discussion, but I didn’t see any viable solution for repeating the Delay Activity indefinitely.
So to solve this, I added a new EventDriven Activity to my State Activity and set the Delay Activity as the first Activity in the EventDriven Activity.
Then I added an IfElse Activity to check if the form had been filled out or not. If the form is filled out, I change the state to “CompleteState”. But if the form hasn’t been filled out, I set it back to the current state which will re-trigger the EventDriven Activity, thus re-starting the Delay timer.
It will continue this loop until the form is filled out, sending an e-mail every time it executes. This is exactly the functionality I was looking for, but the approach to accomplish this was slightly different than I had expected.