The Hidden Perils of Drag and Drop

Have you ever been in Windows Explorer, and while clicking here and there, you accidentally click and drag a folder into another folder? Pretty common right? No real harm... all you have to do is go in and move it back.

Now imagine coming in to work one morning, logging in, opening Visual Studio, and finding out that your Visual Source Safe repository for your project is missing. After placing the appropriate calls to the "Help Desk", they tell you that its accidentally been deleted, but they're not sure by who are why. Then they tell you that they're not sure they have a backup.

Fast forward a day to find out that they have a backup, but it's off site in another state and will take a while to get here.

Fast forward one more day to find out that they didn't actually delete the repository, but someone accidentally moved it (most likely via Drag and Drop given where it was moved to), and didn't realize what they did. Moreover, they're still not sure who did it.

How could they not be sure you ask? Well, as it turns out, this particular server has a global share on it that pretty much everyone has access to. And as it turns out, pretty much everyone here has access to the C$ drive on everyone else's machine too... by design. So if I want to, I can easily delete all the files off of a coworkers computer if I'm upset at him.

Finally today we got our repository back, after two days of down time. I won't say what client I work for... but I will tell you that this is no mom and pop shop. They should know better.

How Many Companies Use Apple?

There is a reason why companies prefer Microsoft over Apple. The NY Times tries to bill legacy support as bad:

As a result, each new version of Windows carries the baggage of its past. As Windows has grown, the technical challenge has become increasingly daunting. Several thousand engineers have labored to build and test Windows Vista, a sprawling, complex software construction project with 50 million lines of code, or more than 40 percent larger than Windows XP.

"Windows is now so big and onerous because of the size of its code base, the size of its ecosystem and its insistence on compatibility with the legacy hardware and software, that it just slows everything down," observed David B. Yoffie, a professor at the Harvard Business School. "That's why a company like Apple has such an easier time of innovation."

Microsoft certainly understands the problem, the need to change and the potential long-term threat to its business from rivals like Apple, the free Linux operating system, and from companies like Google that distribute software as a service over the Internet.

Microsoft has understood this from the very beginning... dating back to its first dealings with IBM. Microsoft recognized that software was just as crucial as hardware, if not more so. It also recognized that software was an investment. Not only does software cost money, but so does deploying it across a large corporation. From the deployment itself, to testing and training, and backwards compatibility concerns with legacy documents. Companies make an investment in software.

Apple over the years has ignored that fundamental business reality to its own detriment. They unveil new hardware that won't run old code. They create new operating systems that require new versions of other software to use. As a result, companies are unwilling to buy Apple computers and operating systems because they realize that an upgrade to the OS would not only require paying for the new operating system, but also investing in new versions of other software to work on that operating system.

While Windows may be slower, you can still run old versions of Office on Windows XP for instance. That allows companies to delay, or even completely avoid upgrading peripheral software that may currently fit its needs. This decision is key when companies scale up in size. Because new hardware won't run old operating systems, it is not uncommon for large corporations to run mixed hardware and operating systems across the enterprise. However, because Microsoft handles legacy applications so well, they can still run the same version of Office, or any other application. Companies can then invest in new hardware for new employees, and not worry that it will create inconsistencies elsewhere.

So while handling legacy code may have disadvantages to pure performance in the operating system, it has far more advantages in the enterprise. Apple's sales numbers, and market penetration over the years more than prove that. Hopefully Microsoft won't forget it.

You Can Find Me Other Places Too

As Joseph Addison once said, "There is no defense against criticism except obscurity." And with that said, you can find my latest review up at BlogCritics.org. It's a review of the new O'Reilly book, Information Dashboard Design by Stephen Few.

You Have to Understand The History

One of my favorite quotes about software is from Michael Sinz:

Programming is like sex, one mistake and you have to support it for the rest of your life.

If you've programed in Visual Basic.NET for any length of time, you soon realize that this is a language that has to make a lot of child support payments. Yesterday I had to answer a question from a colleague about yet another bastard child feature in VB.NET... Array Declarations. She kept having issues because there was one extra item in the array than she was expecting. Previously she'd really only dealt with collection classes like ArrayList. So she was very confused when this statement created an array of 7 elements:

Dim pkTableCol(6) As DataColumn

After all, this statement initializes an ArrayList with a Capacity of 6 elements:

Dim pkTableCol As New ArrayList(6)

In the majority of languages like C, C++, C#, Java, and who knows how many others, you declare an array with the size of the array. The array is then indexed from 0 to Size - 1. In Visual Basic, you declare an array with the largest index. Therefore you get an array that is indexed from 0 to Index. But why on Earth would you make that decision? It's all due to the long and storied history of Visual Basic.

Visual Basic isn't like most programming languages, in that it was designed to be used by people without general computer science backgrounds. One of the "User Friendly Features" they created was arrays that were indexed starting at 1, instead of 0, and ended at Size, instead of Size - 1. While programmers are used to counting starting at 0, most non-programmers start counting at 1. While most C++ programmers would walk through an array list this:

const int ARRAY_SIZE = 6;
int array[ARRAY_SIZE];
for ( int i = 0; i < ARRAY_SIZE; i++ )
{
   array[i] = i * 1000;
}

A VB 6 programmer would have walked through an array this way:

Const ARRAY_SIZE As Integer = 6
Dim array(ARRAY_SIZE) As Integer
Dim i As Integer
For i = 1 To ARRAY_SIZE
   array(i) = i*1000
Next i

In this context, the To keyword is inclusive, so it's equivalent to <= in the C++ for loop. Unfortunately, this lead to a lot of issues. While arrays in Visual Basic worked this way, and so did some of the internal collections, may other types of lists and collections had to be 0 based because they interacted with the Windows API which is C based. So Visual Basic code was filled with mixed base arrays that confused the hell out of a lot people. You could, if you knew about it, actually change the base of an array either by using the Option Base directive, or by changing your array declarations:

Dim array(0 To ARRAY_SIZE-1) As Integer

But many people either didn't know of this feature, or just didn't bother with it. That meant that when Visual Basic.NET came along, there was a lot of old code that had to be supported for conversion from VB6 to .NET.

In .NET, no matter what language you use, arrays are indexed from 0 to Size - 1. This allows for interoperability between all the .NET languages, the Windows API, and COM controls as well. Even Visual Basic array are indexed this way. However, by changing the array declaration syntax to continue to support the old way, they supported all the old code. This way, old VB6 code would still work, there would just be one extra element in the array at index 0, which would never be used. But, the advantage is you don't get all sorts of index out of range exceptions when you convert and run your old code.

Had they changed the array declarations to come in line with the C family of languages, then you'd have to go in and modify a lot of old code if you were converting a VB6 project, because the last element wouldn't exist if you started counting at 1. Was this a good idea? Should they have forced people to modify their old code? That's up for debate. But that's all water under the bridge at this point. The decision has already been made, and now you have to support it.

If It Ain't Broke, Don't Fix It

One of the projects that I sometimes still get dragged back into now and then is about a week and a half from going to production. This is a fun time when the last of the defects are quickly being fixed, and testers scramble around to run the last of their scripts. Then you see a defect that is in code that you know has been working for a long time. After investigating the defect for a bit, you run into the buggy line of code.

That's when I usually say out loud, "How did that get in there?"

The very first thing I do in this case is search through the file history in Source Safe. Sure enough, something was just checked in prior to today's build. So I look at the check-in details. "Fixed Defect #xxxxx and changed a couple other things".

"Great. I wonder what 'other things' got changed."

I've run into this problem at the end of more releases than I care to remember. There is usually at least one developer in any group who loves to tinker. They usually say to themselves, "Well as long as I'm working in this file anyway, I might as well clean a few others things up too." And that's when the new defects come in.

While it can be all well and good to change around some ugly code during development, you should always let ugly code lie at the end of a release. There simply isn't enough time to test your changes. And your changes should be tested. What's worse, is that these "minor changes" are rarely ever called to anyone's attention when checked in. They're simply snuck in, so people don't know that they need to test them. As the old saying goes, "If it ain't broke, don't fix it."

You Know You're a Geek When...

Have you ever written a really bad joke or pun into an email, and not realize how awful it was until after you hit send? Yesterday, I happened to put this in an email response:

Just wanted to make sure I didn't get lost in the void... or
the void* for that matter.

If that person didn't know I was a geek before... he does now.

How Many Designs Have You Regretted?

With out this guy, Dilbert would have never been popular:

Robert Oppenheimer agonized over building the A-bomb. Alfred Nobel got queasy about creating dynamite. Robert Propst invented nothing so destructive. Yet before he died in 2000, he lamented his unwitting contribution to what he called 'monolithic insanity.'

Propst is the father of the cubicle. More than 30 years after he unleashed it on the world, we are still trying to get out of the box. The cubicle has been called many things in its long and terrible reign. But what it has lacked in beauty and amenity, it has made up for in crabgrass-like persistence.

Of course we all have some decisions that we've regretted... but how many can you say have made the lives of millions of people miserable? Now that's an accomplishment.

Pimp My Cube?

This seems like a good idea, except for what's included in the kit:

For only $14.95, you can turn your own drab office space into 'dazzling digs.' That's the promise of a soon-to-be-released kit, Pimp My Cubicle. With a title spun off the popular MTV show 'Pimp My Ride,' the kit will be released March 14, providing office workers with gold pushpins, a mini disco ball, a dollar-sign paperweight, leopard-print fringe and an adhesive gold keyboard key—'to give you a little start on your bling.'

Adding some flair to your cube is always fun... but I think most people who dwell in cubes aren't looking for gold studded bling. This is the sort of stuff we put in our cubes. Know your market!