Artistic Tools

How much of the nature of our software, its look and feel, the aesthetics, presentation, and capabilities, are determined by the nature of the tools that we use to create it? As developers, as artists creating works of interaction, data storage, and algorithms, isn't the result of our work as tied to our tools as a potter's works are tied to her clay and glazes? And 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 here or there, we can create full application frameworks. Then once inside the code we press "dot" and select from a list of actions. So we love our tools because they allow us to do in one hour what used to take us a full day.

At the same time however, if you want a highly animated presentation, then your tool might be ClearSlide. And 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 time you need to develop something that your tool doesn't support.

The tools that you use define you nearly as much as your accomplishments. True artists define 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 to blend them and make them work together.

Artful Vendor Relations

In any business, nobody does all the work themselves. We all rely on outside vendors from such mundane chores as providing the toilet paper up through providing phone lines, tax services, and legal assistance. And here in Information Technology we have our own set of vendors with wonderfully peculiar characteristics.

We group our unique compatriots into three worlds: the language vendors, the software package 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 a lot like choosing a wife. You may not have as much actual contact with the vendor as you would like, but you will 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, but that's a story for another post.

So what should you look for when selecting a language vendor? Probably the most important consideration is to perform an evaluation of their openness and how they admit to bugs and problems. Upgrades to language tools are major undertakings and a vendor doesn't take it lightly. So to meet ongoing challenges they should show resolve to provide workarounds.

Languages and development tools constantly change (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 or other languages. A software vendor employs a large number of programmers, who need to keep releasing new versions in order to maintain their livelihoods.

So it turns out to be a bit of a balancing act managing your relationship with a language vendor: stability helps your programmers be productive, and yet staying current of tools allows you to incorporate new aesthetics and retain younger talent. If you happen to be in the position of selecting a vendor at the start of a large project you will partly need to use your intuition (and contacts in the industry) to get a better sense of the credibility of the press and of the vendors.

On the other hand, if one of the major vendors 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. So take your time and be very deliberate when choosing a language vendor, for you will be living with your choice for a long time.

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 it's a lot to ask for from a language vendor, but then once you select them you will be making a major commitment and effort in your life while using this tool. Perhaps it is precisely due to the difficulty of this decision that developers become pundits. If you wish to be continually marketable though, it's smarter to stay flexible and multilingual. A software language is a sophisticated tool: respect its art but be cosmopolitan.