Uncategorized | Journeyman

Quick ‘n Dirty

May 8, 2010 § Leave a comment

Programmatically creating symbolic links between folders

I was creating some new folders for upcoming projects. I got tired of launching a new command prompt and typing in long folder paths for mklink to create symbolic links. So I whipped up a quick and dirty tool to make this process easier. Yes it is ugly, but it works so its good enough for now. If you want the source code and/or the executable, feel free to download the zip of the Visual Studio 2010 project via the link below.

Download the Visual Studio 2010 Project for the “Create Symbolic Link” tool

Kicking It Old School

November 8, 2009 § Leave a comment

Sometimes, you just got to do it yourself

Have you ever had to resurrect an old code base because the business needs some new functionality added? Of course you have. If you haven’t, wait. If you have, then you understand the pain you have to go through to get the new features added. The hard part is not adding the features, it is verifying that the changes do not introduce defects in the existing code. If the code base is old and without a test framework to support it, you are likely stuck with endless manual testing and a few prayers to back you up.

That’s the situation we found ourselves in recently. We had a new major feature to add and no test framework to support our efforts. We tried to leverage a few frameworks including Google Test, but found that we were spending a large portion of time troubleshooting incompatibilities with libraries. Eventually I concluded that we had to build our own test framework. We wanted to use an established test framework, but all we needed was a way to perform simple state-based, confirmatory tests, so I felt we could get by without one.

I spent a couple hours last Saturday afternoon prototyping and came up with the following code to kick start our framework. Since I wrote the prototype I have added UI to present the outcomes & smart pointer support, so it looks like this code will grow to fit our needs.

If you are itching to build your own custom C++ test framework, feel free to build off of this code. I used Visual Studio and the Boost libraries to built it.

   1: #include "stdafx.h"

   2: #include <list>

   3: #include <algorithm>

   4: #include <iostream>

   5: #include "boost/ptr_container/ptr_list.hpp"

6:

   7: class TestContract {

   8: public:

   9:     virtual std::string GetName() = 0;

  10:     virtual bool RunTest() = 0;

  11: };

12:

  13: class SingleTest : public TestContract

  14: {

  15: public:

  16:     std::string GetName() {

  17:         std::string name ("test 1");

  18:         return name;

  19:     }

  20:     bool RunTest() { return true; }

  21: };

22:

23:

  24: class TestRunner

  25: {

  26: public:

27:

  28:     void AddTest(TestContract* test)

  29:     {

  30:         Tests.push_back(test);

  31:     }

32:

  33:     void RunTests()

  34:     {

  35:         for (    TestsIter = Tests.begin();

  36:                 TestsIter != Tests.end();

  37:                 TestsIter++)

  38:         {

  39:             executeTest(*TestsIter);

  40:         }

  41:     }

42:

  43: private:

44:

  45:     boost::ptr_list<TestContract> Tests;

  46:     boost::ptr_list<TestContract>::iterator TestsIter;

47:

  48:     void executeTest(TestContract& singleTest) {

49:

  50:         std::string name (singleTest.GetName());

51:

  52:         if (singleTest.RunTest())

  53:         {

  54:             std::cout << name.c_str() << ": passed" << std::endl;

  55:         } else {

  56:             std::cout << name.c_str() << ": failed" << std::endl;

  57:         }

  58:     }

  59: };

60:

61:

  62: int _tmain(int argc, _TCHAR* argv[])

  63: {

  64:     SingleTest* pSingle = new SingleTest();

  65:     TestRunner* pTestRunner = new TestRunner();

66:

  67:     pTestRunner->AddTest(pSingle);

68:

  69:     pTestRunner->RunTests();

70:

  71:     return 0;

  72: }

“But…we do that already”

May 19, 2009 § Leave a comment

The benefits of visual, accessible tools.

I gave a presentation last week to our PD organization on Kanban. I am by no means an expert on the subject, but my team had been using it for a couple weeks with success. I thought the larger team would benefit from an introduction to the framework.

One aspect to Kanban is the team board. It is similar to the Scrum team board, with a few modifications such as capacity and a focus on task flow. Here is our Kanban team board which I showed in my presentation. The picture is a couple weeks old and it has changed since then, but the basic concepts remain the same:

After spending most of the hour long presentation outlining Kanban and how it worked, a co-worker spoke up and said “But…we already do this”. He was not specifically referring to Kanban, but to the activities involved with it. The example context I was using at the time was on defect resolution. In hindsight it probably was not the best example since it limited the scope of what Kanban could provide, but it did lead to the question above which forced me to think from his perspective.

It was a good statement and I am glad he made it.

His statement centered around the following points:

We already assign defects to the right team members
We do reassign defects to balance capacity between team members
We have an email notification system in place when the state of a defect changes (e.g. ‘verify this fix’ & ‘the defect is closed’)

On the surface Kanban appears to reinvent the wheel, at least the outcomes of the practices stated above. Like many things in lean and agile development, sometimes the benefits can be spotted when you look outside of the activity itself and focus on the leading and trailing effects of the activity.

Here are some of the benefits as I see them compared with our processes as I understand them today:

1) In a few seconds I can see the status of my team. Specifically, I can look at our Kanban board and see blocked tasks, overcapacity on a team member or members, under capacity issues, any new tasks that entered the board, and any tasks that have been recently completed. No spreadsheets, websites, or databases. Just one look over my shoulder. It is simple and effective.

2) I can watch other team members adjust the board as it happens. In other words, I have more opportunities to respond to a change as it happens. On our team I have done the following:

Congratulate a team member on completing a difficult task.

Ask why a task is suddenly blocked and if I can help.

Ask a question about any new task I see.

Spot trends and potential issues.

3) The team organizes its own tasks, without the help of management. We take responsibility for who does what. We have a limited subset of prioritized tasks we need to address in our backlog. We pull from this backlog to start working on new tasks. This triggers management to fill in the backlog with replacement tasks. No meeting needed. We only need to involve management if we need guidance or insight on a task.

Assigning and reassigning tasks takes less than a few seconds. If it is a defect (which we track using an external tool), we do not need to assign it to the team member that is fixing it until it is actually fixed. This way a task can move between team members with no overhead.

Also, having the board in front of us allows any team member to add new tasks in seconds.

4) Notification happens when an item enters or leaves a column on the board. Since we have a limit on how much work we can focus on at any given time, we immediately notice the change. This is a boon for me because I try to use my email sparingly. I find wading through the 30+ daily emails to be distracting. One less email means one less email I have to find. One glance at the board and I see if my solutions have passed testing and is considered done.

All is not roses with Kanban. We are still wrestling with the right columns and trying to discover a good way to track certain issues. We also have not explored how it could work with distributed teams. At this time I will say, for our team, the benefits have far outweighed the inconveniences.

For some people, what we do currently may satisfy them and that is ok. Every team needs to figure out which tool it wants to use to accomplish its efforts. Personally, I find Kanban to be more convenient and easier to use.

This is how we Scrum – The Daily Scrum

March 13, 2009 § Leave a comment

A picture of three monitors is worth a thousand words.

For our daily Scrum, we gather around my computer at 1:15pm. I dial in to a pre-arranged phone conference and setup my monitors to display key information about our project.

The left monitor displays our sprint burn down chart. The middle is a video feed of our remote contributors. The right monitor shows our sprint task board.

We have two people on the phone. They are two members of our QA team located in Tucson. The video feed is an Office Communicator video conversation with the audio turned off. We use the phone conference instead of the webcam microphone because is much clearer and allows local team members who are working from home to dial-in and participate in the stand-up.

We host the burn down & task board on a SharePoint site so that anyone working remotely has access to the data.

We repeat this arrangement for each daily Scrum in our sprint.

This is how we Scrum – The Planning Meeting

March 9, 2009 § Leave a comment

From storming to performing.

After reading and responding to questions by people who are curious about Scrum and want to implement it, I thought I would write my teams experience with Scrum, starting with the planning meeting we had today.

Here is a little background about our project:

Project length:	1 year
Size of the team:	8: 3 QA, 3 engineers, 1 team manager, 1 project manager.
Fixed release date:	2nd half of 2009. Sorry no specifics 🙂
Sprint length:	2 weeks. Monday = planning. Friday = demo & review
Length of the planning meeting:	1.5 hours. Used to be 3.5 hours, but over time the daily stand-ups keep us informed and reduce the need to discuss the tasks in detail. The prioritized backlog also helps us focus on a few subjects at a time)
Who attends:	Everyone attends the planning, stand-up, demo, & retrospective meetings.

Here is how our planning meeting progressed:

The team manager gives a project status overview.
- What does our product burn down chart look like?
- Are we on track?
- Are there any upcoming external influences on the project?
- Some light discussion on how we interpreted the Product burn down.
We then capture the teams availability using half days as our unit of measure for the next sprint within an Excel spreadsheet.
Then we review any tasks that were not completed last sprint.
- What are the next steps for these tasks?
- Do we need to add tasks to the sprint to complete them?
- Should they be moved to a future sprint?
- Assign the tasks to team members, estimate the days to complete them, and reduce the appropriate team members availability for the remaining tasks.
Look at the next highest priority item in the product backlog.
- Create and assign tasks to work towards completing that item.
- Estimate and reduce the available time of the appropriate team members.
Repeat step 4 until each team member is fully allocated for the sprint.
Now we break and begin working on our tasks.

How to sniff your code

March 23, 2007 § Leave a comment

Code Smells are symptoms of source code which point to potential problems. Popularized by Martin Fowlers book ‘Refactoring‘, the subject has gained real traction in the software industry over the past few years.

While code smells are well defined, identifying these symptoms in source code is usually a subjective activity. Sometimes an experienced engineer could look at code and ‘feel’ that something is wrong with it. For the inexperienced engineer, identifying code smells may take more sleuthing.

Here are a few activities which should make you ‘feel’ like there may be something wrong. If you find yourself fulfilling these activities, you may have sniffed out a code smell:

Activity #1: You have to scroll to continue reading

How many times did you have to page-down to reach the end of the method or class? Does the code you are looking at spill beyond your view?