files. At the end of the demo I commented “gee nice. Hey I was wondering about this item I read here about total protection.” I told him that I seriously doubted their software could stop somebody from destroying all the data on the C drive. He adamantly assured me that it would. Well then, was he confident enough that he would let me have a crack at his demo computer? Without a flinch he said sure!
I carried up a boot disk with the old DOS debug program on it, turned off his computer, put the disk in, and turned the computer on again. Zyg zyg beep! At the DOS prompt I typed debug and then used a command to write all zeroes to the boot sector on the hard disk. “Well uh, I think I just wiped your C drive,” I shrugged. The salesperson didn’t believe me. I removed my floppy disk and watched in a pitying amusement as he tried to restart his computer. Naturally the C drive was no longer readable at all (now he would have to reformat it).
Needless to say we declined the offer to purchase their software. Moral of the story: when you are buying software, trust… but verify.
Languages and Tools
Software developers ground themselves on languages and tools just as painters depend upon oils, brushes, style, canvas, and subject. Most developers eventually find themselves wed to the languages and tools that they find best meets their work objectives; the process of arriving at this mating however can be winding and perilous.
In this chapter I describe some of the difficulties and neuroses associated with being dependent upon vendor-supplied tools and languages.
Artful Vendor Relations
In any business, nobody does all the work themselves. We all rely on outside vendors for such mundane chores as providing the toilet paper up through providing the phone lines, tax services, and legal assistance.
Here in Information Technology we have our own set of vendors with their own wonderfully peculiar characteristics.
We group our unique compatriots into three worlds: the language vendors, the software vendors, and the hardware vendors. We’ll get to all three in due time, but today we will chat about the marvelous world of language vendors.
Selecting a language vendor is comparable to choosing a wife. You may yearn for greater contact with the vendor, but you will still get to deal with what she cooks up and her aesthetic tastes will affect you long after she is gone. Yeah and changing language vendors is as painful as going through a divorce.
So what should you insist upon when selecting a language vendor? Probably the most important consideration is to perform an evaluation of their openness for how they admit to bugs and problems. Upgrades to language tools are major undertakings and a vendor doesn’t approach it lightly. So to meet ongoing challenges they should show resolve to provide a workaround for any of their bugs.
Languages and development tools constantly evolve (and I’ve never seen a version of a language released with fewer verbs than the previous version). To some extent the vendor is trying to remain competitive by adding the functionality that becomes available in competitors’ products. A software vendor also employs a large number of programmers who need to keep releasing new versions in order to maintain their livelihoods.
Managing your relationship with a language vendor turns out to be a bit of a balancing act: stability helps your programmers be productive, and yet staying current of tools allows you to incorporate new aesthetics and retain the new young talent. It’s as if you are a circus performer crossing the high wire repeatedly from one platform to another, except the balance bar you ferry keeps on growing.
If a major vendor announces their plans for their next release of one of their market-leading programming tools then you would be remiss to overlook its pending availability in your plans. Is the language starting to succumb to “featuritis” or does it still allow for competent upward and downward compatible development? You will need to use your intuition (and contacts in the industry) to get a better sense of the credibility of the press reviews of the vendor.
Evaluate carefully and be very deliberate when choosing a language vendor, for you will be living captive with your choice for a long, long time.
Artistic Tools
How much do our tools determine the temperament of our software: its look and feel, the aesthetics, presentation, and its interactive characteristics? As developers and artists creating works of response, data storage, and algorithms, the result of our efforts are as tied to our tools as a potter’s works are tied to her clay and glazes. Hence we share pretty much the same neuroses with respect to our tools as any artist.
With a few clicks of a mouse and by dragging some widgets around we can create full application frameworks as if we are gods commanding machinery. Then once inside the code we press “dot” and select from a list of actions. We love our tools because they allow us to accomplish in one hour what used to require a full day.
If you want a highly animated presentation then your tool might be Flash. If your application requires extensive analysis, dicing, and slicing of multidimensional data then your tools may include SQL and Cognos. And once you’ve chosen your tool and made your investment to learn its bells and whistles, woe be the day you need to develop something that your tool doesn’t support.
I suppose you can paint a portrait out of pottery, but it’s just not the same. It looks like a portrait out of pottery. The tools that you use define you nearly as much as your accomplishments. True artists practice a unique style by developing their own set of tools. A structure, a methodology, a bunch of accouterments seem to create themselves a priori out of thin air and then this drives the subsequent creating.
When you are developing you should always strive to increase the variety of tools at your disposal and leverage them by finding ways of blending them to make them work together. Work as if you want to become the next Jackson Pollack or Andy Warhol of code.
Artistic Language
It happens pretty rarely in one’s career, but perhaps once or twice you will find yourself in the unenviable position of selecting a development language for yourself and your cohorts. Nowadays most shops use C# or Java, but back in the day when our choices were Cobol, Basic, or Fortran, I had the pleasure of making this dubious analysis. And no doubt as hardware and languages progress we’ll reach another tipping point where you may find yourself selecting between a panoply of competing next generation languages, so I share this in the spirit of support for when you need to cross that bridge.
Choosing a new language to use is as distressing as having to select a new city for relocating. You can research the weather, travel blogs, crime statistics, and a hundred other metrics, but you only fully appreciate the flavor for the place after you’ve lived there a couple years.
Languages bring to the table a variety of capabilities. Part of the challenge in making a selection is that you need to be fairly conversant in the languages you are reviewing so that you can both define the nature of the capabilities and then rate the features of the languages across those dimensions. Metrics I have used in the past include:
+ complexity of math library
+ readability of code
+ flexible variable typing
+ multithreading support
+ security framework
+ development environment tools
+ trace and debugging support
+ compilation speed and complexity
+ runtime distributable
+ execution speed
+ step-through execution
+ data entry validation masks
+ extensive sort support
+ integrated dictionaries
+ versioning
+ vendor commits to backward compatibility
Yeah