The Wire. Down to it.

If you’re a big Critical Results fan–and who isn’t?–you may have missed my regular blog updates for the last week and a half. Let me tell you what’s going on.

The weekend before last, I was completely saturated in Startup Weekend Cleveland, which in short was great fun and very educational. It starts at 6pm on Friday and ostensibly ends around 9pm on Sunday, but like most of the groups that coalesced there, our startup (a little thing called MyCleTV) is still together and still working on our big idea. But the intensive weekend is tiring, and it sucked all my energy for at least a few days afterwards. So last week was not a good time to get anything done (like blogging) that wasn’t strictly required.

This week has been even more intense though. I am finishing the four-month migration of a scientific application from a legacy Visual Basic platform to .NET. The last parts of specialized hardware just arrived yesterday at the build site. The machines were assembled at around 3pm. At 5pm the project owner told me that one completed machine will be delivered to a client next week, and another one the week after that to a different client.

Let me make one thing clear: this means that as of lunchtime yesterday, I’d been spending four months developing software for a hardware device that didn’t yet exist and now that it exists I have two days to ensure that it works. Wish I knew someone who specializes in “Software Projects That Suck!”

Want more?

Opt in to my keep-in-touch mailing list. You get a complete eZine about once a month, with articles and links and special offers that help you do your job, but also a quick note every week or so with something funny, interesting, or delicious. No matter what business or role you’re in, if you deal with software development projects in any way this is for you.

I was a little panicked by this.

I’m getting paid for the project regardless, because my contract doesn’t have an immediate deadline, but it’s important for the client to get the maximum possible use out of my implementation. Getting the software installed on the next go-round would be acceptable, in the sense that it wouldn’t wreck the project or cause a business disaster, but we really do want it to go live next week. My list of unresolved issues is about half a page of handwritten single-line entries. That’s a lot to do in two days.

On second thought, wait, no. The previous four months were devoted to refactoring the heck out of that unstructured legacy code. It’s easy to read and easy to modify. If the (never before tested) unsafe C# interfaces I wrote for the legacy DLL drivers for the hardware components don’t work, I know exactly where to go to fix them. The fact that my database moved to a new location is minor. Our specialized input device really does just dump bits to a buffer; it’s not that hard.

What I did

In any case, the project owner is in a hurry and confidence is important. So first thing this morning, I made a separate listing of the path from here to live rollout. It’s actually not bad at all, mostly stuff like this:

  • log software installation steps so they can be replicated later
  • database startup verified
  • demonstrate grab of input buffer
  • demonstrate foo
  • demonstrate calibration
  • fix coding of the Generic List of Baz, known issue there
  • demonstrate Quux algorithm

That’s the essence of today’s list. Tomorrow’s goes like this:

  • demonstrate functionality of X/Y/Z settings
  • demonstrate saving output to database
  • demonstrate saving output to flat files
  • demonstrate calculation of yea certain “critical result”
  • demonstrate four other items I won’t describe even vaguely in the blog

And for any leftover time (hah!) I have these tasks:

  • Remove unused legacy DLLs from build
  • Re-run all unit tests
  • Rebuild as “production” rather than “test” code
  • Bump software version in build
  • Commit one last time to Subversion repository
  • Create final installer package

There’s more, but you see the point. Notably, this is not a bug or defect list. It’s a progress list. We’re not aiming necessarily for bug-free; while it’s obviously important for the code to be right, that’s not the same thing as fixing things that are wrong.

The process is key

Today and tomorrow, and perhaps part of Saturday, the idea is to keep things moving forward. If I focused on a bug list, I’d be fixing bugs. I need to focus on a progress list instead, and if bugs are uncovered along the way then they’ll get prioritized.

Where I’ll be

Between now and Sunday you’ll find me either pushing this progress list, or refilling on espresso. In the meantime, help me out here. What am I doing right? What am I doing wrong? What part of this isn’t Agile enough? And please share your tips and war stories about using legacy DLLs from C#.

I’ll let you know how it goes.