Robert on Software Development

I decided to spend some quality time working on the Windows Workflow application I wrote to support the document workflow that is such a crucial part of the weekly Technical Review Board that I run for change management. The first couple of iterations of the application were pretty simple: it would take an Excel document as an input, along with some fields set by the user (date of the agenda, which RFCs to review [by number]), and then output an agenda along with a formatted Excel document to make reviewing the RFCs a little easier.

But there were still too many tasks done by hand. I knew more could be automated: extracting the RFC detail from the list into the agenda, creating the PDF packet, emailing it to everyone. Ideally, the application would have only one human step: actually reviewing the RFCs. So it would go through the process of bringing documents together, pause while I do my thing, and then resume with more creation and sharing of information.

I’m not quite there yet. It’s a side project so I can’t put too much time into it, but I do have a rough design in mind and, like so many little prototype one-off applications, this one will grow into an essential tool for this role.

And now for some interesting technical tidbits. I rewrote the Office integration piece to make it more stable and less resource-intensive, so I implemented the Excel and Word automators as Singletons, using a pretty simple IAutomator interface. Since I had started working on the Excel automator before the Word one, it had grown into some pretty gnarly code, while the Word automator was clean and well-designed, the product of experience. I stripped out a lot of unnecessary code, implemented the interface, and ensured only one instance of the Office COM objects were instantiated. I also added much-needed Marshaling code to release the COM objects when the whole thing was done. It’s pretty standard stuff as you move an app from simple prototype into more useful (and shareable) tool.

One thing that caught me up though was that the workflow kept spawning two copies of Excel. I couldn’t figure out why. I had thought that the Singleton pattern would ensure that wouldn’t happen, but what that ended up doing was skewing my attention from the root of the problem. I finally discovered that I stupidly called the Initialize() method twice, spawning that extra copy of Excel. I couldn’t find the bug because I thought I was smarter than that. As tools get more powerful and languages add more features, we easily get caught up in that stuff, forgetting the basic principles.

My computer math teacher in high school taught me skills that I still use today. One of those is the pencil test. With the pencil test, you literally use a pencil to point at each line of code on your screen, reading every bit of code one line at a time until you find an error. It made for some interesting debugging, but in those days of GW-BASIC, it was all we had. And that “pencil test” is what helped me find my silly Excel COM bug today.

The joy—and pain—of software development can only be summed up so simply.

Years ago, when I first started working in the IT business at a small electric company in Texas, I had a coworker named Jim. Jim was in his 60s and had been an electrical engineer all his life, which in 1994 added up to about 40 years. He was enormously respected for his understandably dizzying knowledge of electrical engineering, especially when it involved transmission lines and substations.

My interaction with Jim was a support role. The electric company had computers on every desk, loaded with Microsoft Office and AutoCAD for the engineers. Jim would try to figure out how to solve his own IT support issues, and it usually resulted in things getting worse. For example, one day he called me and said that his mouse was moving around on his screen too fast. I sat down at his desk and instantly realized that his mouse pointer acceleration was set to the maximum. I guess he had been playing around with it and set it too high. Typical engineer!

Jim used the same greeting with everyone he saw during the day: “How’s your day going?” It always resulted in the same canned replies, like “fine” and “great.” I didn’t realize the philosophical implications of Jim’s question until much later: what am I doing and what I have accomplished so far.

Today I have evaluated 11 change requests for technical errors, changed the enterprise architecture diagram for a solution assessment, and fixed a bug in the C# code for my workflow application. That’s what I’ve accomplished so far.

But what am I doing? How is the rest of my day going? How can I ensure I’m giving my customer a maximum return on their investment? What can I do to ensure that when I get home, I can tell my fiancee that I’ve had a good day?

The answer has two parts: first, how can I track what I’m doing, and second, how can I know when it’s done. To-do lists, notes in OneNote, task list in Outlook, sticky notes on my monitor, Follow Up tags on my emails, or a mental list just a few of the many ways people track the ever-expanding list of Things to Do. I’ve tried them all. I settled on using different tools for each job. I use Excel to track the change requests I’m reviewing. I use Outlook to manage the tasks associated with following up with change builders. I use OneNote to track the lifecycle of certain documents that undergo a lot of changes from meeting to meeting.

In information technology, the management of Things to Do has wide-reaching influences and often requires a substantial investment in tools and people. Everything from the business processes to the schedule to the project manager to the people doing the work has to be meticulously tracked, verified, and managed. This is one of the cornerstones of good IT governance.

Hats off to you, Jim, wherever you are now.