Saturday, December 22, 2012

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.

Friday, December 7, 2012

The Art in Modularity

Good software developers tend to be organizing freaks: everything goes in a tiny little box in its proper place. You know the saying “there’s no limit to how complicated things can get, on account of one thing always leading to another.” This is especially true in programming.

To combat this creeping complexity we strive for modularity and maintainability. A small module that encloses a specific business rule is easier for testing and allows for greater flexibility of reuse. When modules become too small however, the sheer act of tracking them, organizing their use, maintaining consistent versions, and finding where a business rule gets implemented interferes with your productivity.

Somewhat counter-intuitively smaller modules also need greater external documentation, mainly to track the nature of the parameters passed between them.

What’s the right size for a module then? And how many modules should a system have? Although I like a module to be between a half and five printed pages it really depends upon two things: how many people are maintaining the software and the density of the development language.

The fewer the number of developers the larger modules can be. Each of you is baking your own cake. So if it’s just the two of you maintaining a legacy billing system written in an old dialect of Basic (that gets about as complicated as a GOSUB and a CALL) then sure, go with the 5-page modules.

But if a half-dozen of you are planning to maintain ASP web pages in C# (with overloads and inheritance) then you’d better veer closer to the halfpage module size. In that case you’re not each baking a cake; you’re all contributing to building a car. You need to be able to swap in new replacement parts when the old ones wear thin. Every once in a while step back to review how you are developing the code: are you using appropriately sized modules?