Robert on Software Development

Learning as I Go Along

One of the things I’ve always loved about working in this industry is the “breathing room” we give ourselves to figure things out on our own. Depending on the project or tasks, we’re able to draw on our experiences and knowledge to tackle problems of all sizes. To make things even better, we’re allowed—even expected—to acquire new knowledge at a blistering pace. And one great way to do that is to simply try.

Such as it has been the past few months as I built a tool in Visual Studio 2008, C#, and Windows Workflow. This tool, which I’ve mentioned here before, was created to serve two purposes: first, to help me keep my skills current and learn something new (namely .NET 3.0 and Windows Workflow) and second, to help simplify and automate the process of performing my weekly change management duties.

The work I’ve put into this project has resulted in a significant leap forward in my WF and .NET skills, as I had hoped and expected. The interesting side effect is that it helped me refine my change management process, showing me the areas where improvement was needed and where steps could be completely eliminated. The creation of the Windows Workflow was the catalyst for those changes. Through my technical trial and error, I was able to sort of redesign the process. From a certain point of view, the process changed to suit Windows Workflow, but the way WF is designed ensures that there’s not a tie-in between the process and the WF used to represent it.

The differences between the first iteration and the most recent iteration of the application are astounding. When I began this project, I didn’t use TDD or agile methodologies or any of that stuff of which I often sing praises. I sort of just jumped into it, learning as I went along, making mistakes and correcting them. Even in this late iteration, I’m finding things that need to be improved, bugs that need to be fixed, features that need to be added.

What struck me as the most curious product of this endeavor was the discovery that while my process became less rigid, the workflow for the process became practically ironclad. Each step in the workflow depends on the step preceding. While I had successfully decoupled the process as done by hand, I had created a monster of an inflexible beast that simply performed the steps in a predefined order, with no room for change or improvement. In other words, I had done it all wrong. Once I reached a point where I realized that the RFC documents absolutely had to be in the source folder before I could start working on the review because my application required it, I completely understood that I had shifted the inflexibility from my work to my workflow.

Thus, even as I feel like I’m near completion, I know that I have more work to do. The plus side is I have a working product that does what I need it to do, albeit inflexibly and unable to handle exceptions. That’s for future iterations, work that I am quite looking forward to.