The “Visual Basic Effect”

The programming language of BASIC has always been a popular option for beginners in the past. BASIC is an acronym that stands for “Beginner’s All-purpose Symbolic Instruction Code”. So its designers were clearly targeting beginner programmers. As a result, the language is quite easy to understand for people with little or no prior experience with computers. Its syntax is close to simple English phrases, and users do not generally need to worry about data types much.

On the Windows platform, Microsoft offered Visual Basic, in two flavours:

  1. The ‘full’ Visual Basic for stand-alone Windows programs.
  2. Visual Basic for Applications, a ‘scripting’ language for use inside MS Office and various other Windows applications.

Visual Basic was mostly used by inexperienced programmers, and people from outside the world of software development. Especially VBA, which was used by (non-programmer) people to add functionality to their Word and Excel documents, for example. Some even made ‘complete’ (and sometimes business-critical) applications this way. This resulted in poor average quality of Visual Basic solutions. This is what I would describe as the Visual Basic Effect.

Namely, in the hands of an experienced and properly educated software developer, Visual Basic can be used for decent software development, and can produce applications of good quality, even though Visual Basic obviously has its limitation (then again, don’t all programming languages? To a significant degree, software development is all about working inside limitations).

This is not limited to just Visual Basic, I think there is some ‘Visual Basic Effect’ in every programming language or environment. I think the most obvious example these days is in JavaScript. A lot of JavaScript is written by people who aren’t necessarily software engineers, but rather web designers who have learnt a bit of JavaScript to implement their designs.

As a result, many websites have highly inefficient, unstable, poorly written and bloated scripts. Now, I grew up with 8-bit computers of just 1 MHz and a handful of kilobytes for memory. And these machines could respond to user input ‘instantly’. I simply can’t get my head around the fact that today there are many websites that take a second or more to respond to a simple button-click, even on a computer with many cores, many MHz, and many gigabytes of memory. And certainly, there are fine examples of JavaScript-driven web pages that are very elegant and efficient. Of course, these are designed and implemented by proper software architects and engineers, not necessarily ‘people who build websites and know JavaScript’.

A related thing I encountered was with image processing, where it seems common to use Python to interact with a library such as OpenCV. Now, OpenCV itself is written in C++, by people who understand the intricacies of image processing, and know how to optimize it at a low level. The people who use OpenCV with Python are likely similar to the BASIC and JavaScript-crowd: People who aren’t necessarily software engineers themselves, but use Python as a simple tool to access OpenCV as a toolkit.

When people at work were looking for people to hire, they found that it was easier to find Python programmers with OpenCV experience, than people using C/C++. I pointed out the ‘Visual Basic Effect’ and said: “Are you sure the Python programmers are what you want though? They will know how to use OpenCV, but if what you are looking for is actually a custom re-implementation of certain functionality that is in, or similar to, OpenCV, these Python programmers are probably not going to be up to the task.” You will want the type of programmer that can develop something like OpenCV, and those are usually C/C++ people. These people think at a different level of abstraction, the level required to implement and optimize image processing routines such as found in OpenCV. Simply using OpenCV and rigging some processing routines together in a Python script is a completely different affair. Clearly, anyone well-versed in C/C++ is capable of picking up Python in a matter of days, and doing those tasks as well. But not the other way around.

I suppose that brings me back to the ‘aptitude’ that Joel Spolsky pointed out in his Guerrilla Guide to Interviewing. People who interview others for a job by just asking if they have experience with certain tools, or just asking a lot of basic facts, like a ‘quiz show’, are missing the point. You don’t want to know if the person you are interviewing happens to be familiar with the buzzword-of-the-day in the niche that your company’s latest project happens to be operating in, of if he or she happens to be familiar with the flavour-of-the-month tools and languages that your company is currently using. No, you want to know if the person has the aptitude to pick up the relevant knowledge and apply it in ways that generates value for your company.

And in that sense, it may often be better to hire people who are smart and experienced in other areas, than those who happen to know the tools you’re currently interested in, but have limited understanding and experience otherwise. In the case of the Visual Basic effect, you’re probably better off hiring non-VB programmers, because the developers that use more difficult and advanced languages such as C++ and C# will generally also be able to design and implement better VB code than people whose only exposure to software development has been VB.

There is just this huge difference between people who ‘know how to do X’, and people who have a solid understanding of relevant technologies, and can apply them to a wide range of tools and problems.


This entry was posted in Software development and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s