Robert on Software Development

I am the proud owner of a new HP Pavilion tz2500 tablet PC. When I first got it, I had mixed feelings. I had wanted a tablet PC for a long time, mainly because I felt it could enable some positive behaviors toward notetaking and managing the plethora of ideas and projects I have. But when I first started using it, I couldn’t figure out how it was supposed to benefit me. I knew it was good, I knew it had possibility, but I had no idea what I should be doing with it. I saw the value of the possibilities but did not have an approach to the follow-through.

Most ideas and plans work out that way, don’t they? Something swims around in your head and you know it’s awesome, but when it comes time to make it happen, it’s just not there. This happens to me all the time. In fact, that very issue is what led me to the tablet PC in the first place.

Today I felt pretty frustrated with my decision. I began to find reasons to dislike my new tablet PC. It’s too heavy. The screen is glossy. There’s too much silver. I wanted to lay the blame for returning the computer on something that was wrong with it and not me.

I relayed these concerns to a good friend and colleague, who happens to be a tablet PC owner (a different model). He showed me how to use my tablet PC. He relayed its strengths, situations where it could prove valuable, things I hadn’t thought of. He helped me understand its value and reinforced my original reasons for getting the tablet PC. He told me about some great software. His opinions and assistance allowed me to accept the computer’s shortcomings (which I admittedly knew about before I bought it) and embrace its real potential.

Every innovator needs a validator, someone who can tell you when you’re wrong and when you’re right. Someone who can help you mold an idea into something real. Someone who is honest and forthcoming with opinions. If you look back on some of history’s great innovations, you’ll see a lot of partnerships (Brin and Page, Gates and Allen) and a lot of adversarial relationships (Edison and Tesla, Microsoft and Google). That’s the balance that allows us to trumpet our accomplishments, defend our decisions, and change our approaches. It forces innovation while celebrating it.

I’m writing this post on my tablet and after finding some really good applications for it, I am in love. I look forward to taking advantage of its full potential and using it to unleash some of my most persistent and longstanding ideas.

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.