Other

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.

To quote Jeff Atwood of Coding Horror fame:

“I don’t care if you suck at writing. I don’t care if nobody reads your blog. I don’t care if you have nothing interesting to say. If you can demonstrate a willingness to write, and a desire to keep continually improving your writing, you will eventually be successful.”

How this applies to us

We began blogging at SlickEdit a little over a year ago. Not written by a single person, the blog is a group effort authored by the dev and support teams. Our goal for the blog was to better connect with the developer community at large and to become an active participant in online discussions . The ‘Hello World’ blog gave us the perfect platform to share our thoughts, opinions, and expertise on a myriad of technical issues.

From software management and best practices to managing the first days on the job, the SlickEdit team has shared their thoughts, tips, real world experiences, and genuine joy of coding with the online community. I am very happy to say that the blog has been a huge success. With hundreds of thousands of visitors from over 176 countries and territories, the SlickEdit blog has outperformed our wildest expectations.

What has been really exciting are the hundreds of comments we have received on the blog, as well as link backs, that have really allowed us to connect and interact with the online community – the whole purpose of the blog to begin with. On the social media side, we have been Dugg, Reditted, StumbledUpon, Dzoned, DotNetKicked, Delicioused, Hacker Newsed, etc… more times than I can count. Exciting stuff and we can’t thank you enough.

Just in case you have missed any posts, here are a samples from each month since we began the blog.

Visit the blog archives for a complete list of all posts :

April 2007

Is Your Editor Working Hard Enough?

May 2007

Top Ten Reasons NOT to use SlickEdit

June 2007

Learning to Fly: The Musings of a New SlickEdit Employee

July 2007

Programming Language Wars

August 2007

SlickEdit 2007 For Windows Development

September 2007

Creating a PHP 5 Extension with Visual C++ 2005

October 2007

Comfort, Habits and Ruts in Software Development

November 2007

C# with SlickEdit : No Visual Studio Required

December 2007

Classical in a Digital Age

January 2008

My Programming New Year’s Resolution

February 2008

Plug-in Extensibility Through Reflection in .Net and Java

March 2008

Software Schedules and the Parable of the Loaf of Bread

April 2008

BASIC and the Rubik’s Cube

May 2008

Tutorial: Adding Language Support to SlickEdit

June 2008

“Management” is a Dirty Word

 All

Complete list of all posts for SlickEdit

« Previous Page