My first blog post of this year is going to be a tribute to one of my best friends that I recently had to say goodbye to… the computer I started with here at SlickEdit.   As a programmer, your computer is something that you spend 8-9 hours a day interacting with.  My work computer gets more face-to-face time than any other person I know, so it’s only natural to develop a friendship with it.

After three years of use it had developed its own unique personality.  It had the perfect background with cool sounds to match.  The fonts were just right.  All of the desktop icons were where I wanted them and I knew exactly where everything was off the Start menu.  I had scripts, shortcuts and bindings to do all the common stuff I need to quickly.  I’d gotten to know all of its quirks, traits, flaws and mannerisms over those few years.

However, like many computers, after installing several versions of many large apps, it wasn’t the playful, energetic puppy that it was back when I started using it.  It was in no rush when rebooting, and I could hear it let out a sigh whenever started Outlook or Visual Studio.  What were once speedy builds turned into mandatory coffee breaks.  Still, I loved that computer… we knew each other and wrote software together every day.

Then, early one morning, our sys admin came over to my office.  “It seems like your computer’s been trying to send out emails directly on port 25 during the middle of the night, any idea what that could be?”  I didn’t know.  We looked up the address where they were being sent, somewhere I’d never heard of before.  “Alright, I’ll bring over the Vista DVD,” he said.

And that’s when it sunk in.  An infection… a virus… the Vista DVD… I was going to have to reformat my machine.  I was going to have to shoot Old Yeller.

[From the movie… Old Yeller’s gone rabid and Mama’s holding a shotgun]
Travis: No mama!
Mama: There’s no hope for him now. He’s sufferin’. You know we gotta do it.
Travis: I know Mama… But he was my dog… I’ll do it.

I sat quietly for a while after he left, realizing that this was the end.  I spent the next few hours backing up all of my important files and exporting all of my preferences.  “There are automatic updates ready to install, reboot now?” it prompted innocently.  The poor thing had no clue.  I missed him already, and I wondered if a better place awaited him after fdisk.  A place without disk fragmentation, bloated installations, useless polling auto-update tray apps and frozen taskbars.  I said goodbye and shut down one last time before booting from the Vista DVD.

I’m still sitting at the same desk, but everything feels new and a little unknown now.  It’s like working again with that energetic puppy I began with.  He’s eager to start up and get to work, builds are a snap and the desktop is clutter-free.  I’m still getting to know it, and soon he’ll develop his own personality.  I still miss Old Yeller, though.

It’s become a custom with me and my kids to hit the yard sales during the summer and fall weekends.  They can get a lot more for their allowance money at those sales than they can at the toy stores, and sometimes I find stuff that’s such a bargain I can’t pass it up.  We recently went to one that turned up one of the most amazing finds I’ve ever run into at a garage sale yet.

Visual Basic 1.0

Sitting in between Turbo Tax ’99 and Mavis Beacon’s Typing Tutor was this gem….  Visual Basic 1.0.  I almost couldn’t believe my eyes.  To me, this was on par with finding the missing link.  As a programmer, this was archeological gold, and it was on sale for fifty cents.  My kids saw the excitement on my face and must have thought that I’d found an XBox 360.  For them, Visual Basic was a major let down.

A lot of people think that VB is soft and if you program in it, you’re automatically a drooling hack developer who couldn’t program their alarm clock.  I cut my teeth on VB 4.0 in my first job, and learned that when combined with COM in C++, VB was a fantastic language for the job of making a user interface. That being said, VB still has some special memories for me.

The contents of the box were practically undisturbed.  The disks were all still in their original plastic wrap and the manual didn’t seem to have ever been opened.  Immediately, there are certain clues that tell you just how old it is (even though the box is copyrighted 1991).  First, the box contains two forms of media; 3.5″ and 5.25″ floppies.  To actually take a 5.25″ floppy out of its sleeve and hold it brought me back to the days of floppy doors and the red LED that told you the disk was being read.  The system requirements for VB 1.0 were Windows 3.0, a 286 processor and 1MB of memory.  Somewhat of a far cry from the Visual Basic of today.

I also loved the included “Companion Products and Services Directory”.  The third party marketing rush had already begun back then.  Most of the components in the catalog, though, are for connecting to a VAX server or to a dBase or Btrieve database.  There are a handful of charting components and widgets such as tree controls (not yet standard in 1991) and grids.  The reminiscing continues.

This box goes right up on my bookshelf at home next to the most revered books in my collection. Say what you will about Visual Basic, but it may be one of the most important developments in programming over the last 20 years for the simple reason that it allowed any non-programmer to write a Windows program.  If you think that’s not a valid reason for such importance, let me repeat… it allowed any non-programmer to write a Windows program.  It was Prometheus, stealing fire from Zeus and giving it to mere mortals for their use.

You no longer had to know C, and wade through Petzold, to write “Hello World” in a window.  Employees from any company with core business knowledge, but no degree in programming, could now quickly write customized applications.  Of course, the debate of whether this was a good thing for programming or not still goes on today.  However, regardless of which side you’re on, you can’t deny that VB was a major victory for bringing the PC to the business market.  Without VB, we may not even have a Microsoft today.

So thank you very much, guy from two streets down, who decided that Visual Basic 1.0 wasn’t important enough to keep, but too important to just throw away.  One man’s junk is another man’s gold, and I really struck it rich that weekend.

SlickEdit is switching over to a different bug tracking system, so I’ve got that topic much on my mind lately. It’s amazing how complex something so simple can be. I’ve never seen a group of developers larger than three agree on how to do it.

I like the generic term, “change request” for all changes in a system. But it’s very important to know whether it is a defect or a feature request. In my lexicon, a “defect” is something that doesn’t work as spec’ed; a feature request is a request to alter the intended behavior. Overall, I prefer the word “defect” to “bug”. “Bug” sounds kind of cute. “Defect” is a harsh, painful word, which is exactly what I want associated with any part of the product that doesn’t work properly.

Depending on who you are talking to, they either don’t care about this distinction or they care greatly.

Customers generally don’t really care which it is. They just want the behavior changed. To them, it is a defect as in “defective”, and they don’t care whether it was spec’ed wrong or implemented wrong—it’s just wrong and they want it changed. Am I any different about the products I use?

As a product manager, I care greatly about this distinction because they tend to address different groups. Defects are typically the chief cause for dissatisfaction with a given product. Generally, customers wouldn’t have bought the product if it didn’t have the features they wanted, but key defects are sometimes discovered only after you’ve purchased. Certainly, if you have many obvious defects they will prevent new customers from favorably evaluating your product. Further, defects in a program add to the burden of development, slowing work on related capabilities.

Feature requests add new capabilities to the system. Though these are beneficial to existing users, they primarily want the existing set of capabilities to work as well as possible. New features are a means to broaden the product’s appeal. They can also provide incentives for customers to upgrade or participate in maintenance programs that include free updates.

Developers are also passionate about this distinction, but for a different reason. For them, the concern seems to be that a defect is considered a personal affront to their ability. I’ve spent more time arguing with some developers whether a change request was a defect or a feature request than it would actually take them to fix the problem (though, not at SlickEdit, of course!)

Balancing priorities for defects versus feature requests is one of the most challenging tasks a product manager faces. There are different voices pulling you in different directions: sales, marketing, customers, and developers. All have different things they want to accomplish in the next release.

At SlickEdit, we try to strike a balance that gives as much as we can to each group. Each major release contains new features that we think can improve how you write code. We also try to knock out as many defects as we possibly can.

« Previous PageNext Page »