Thursday, May 17, 2018

Artful Versions

When you focus on modular resilience, one item that helps a great deal is to pay attention to versioning. Version numbers are of use not only for change management but for testing and customer support as well. Apps developed with Microsoft tools keep their version numbers in a config file. You should standardize on a common meaning for the four subparts of version numbers.

Upgrades that produce a system that is incompatible with a prior release should increment the "major" version number. Upgrades that retain compatibility but that add significant functionality, should upgrade the "minor" version number. Bug fixes that get packaged into a distribution should increment the "release" version number. Finally the developers should increment the fourth component, the "build" number, with every compilation.

I like to present versions to the customer as major dot minor, for example this is versions 2.4 of the software. This version should display in a welcome pop-up and in the title bar of the main screen of your application. But for purpose of technical support I like to display (in a pop-up "About" box) something like version 2.4.3 build 118. Of course all of the version components are retrievable using the system reflection class.

Another helpful trick is to include a parallel matching version number within the backing database. When the client begins to run your software, make sure the version number in the data is compatible with the number in your software.

You should also version all of the modules within your software in a similar fashion. Although the component module versions aren't typically presented to the end user, reflect them to a called module (for debugging purposes) so that the called class can display the version of the invoker whenever it throws an error.

Sometimes it may seem superfluous, but it only takes about 30 seconds to update a version number, and with multiple developers on a project you will find that having this tracking available is invaluable.

Friday, April 13, 2018

Artfully Clean

Imagine buying a house and then never doing the laundry, vacuuming, taking out the trash, or washing the dishes. You just let stuff pile up until you run out of space and then you throw your up hands and go “oh, it must be time for a new house.” Sounds ludicrous eh?

In a highly competitive development environment though you build tables and files and directory folders, develop software, test a bit, and away you go. You patch up the bugs, optimize the queries, add a handful of indices, and you’re flying.

After a couple years though people are wondering why things take so long. Unsurprisingly the typical reason is a failure to archive and then remove the old data. Nobody is taking out the trash! Data retention and archival policies never get baked into the original specifications as the sponsors seldom see any immediate competitive value from them. Eventually however a clean system becomes less of a luxury and more a necessity. Folks start to notice the pile of dirty dishes.

The effort required to retrofit for cleanliness is about the same as the effort for planning for this up front. Strictly operationally however it is better to delay this expenditure until a system becomes a mess as you will then have a better understanding of the corners with the most fuzzballs.

Thursday, March 15, 2018

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.