Monday, August 26, 2013

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.


Wednesday, August 7, 2013

Artistic Analysis


Every once in a while you get a lifetime project: the development (or more typically the redevelopment) of the central system that pumps the heart of a business. The toughest part of this challenge is nailing the initial analysis. On such a large, mission-critical system, getting the analysis correct is both an immense responsibility and terribly vital. So to aid your developers your first set of deliverables should be:

1) A sociological analysis. This should include a full detailing of which employees are best at performing what functions, and how that will mesh with the new system. It should consider how the project will survive the politics of the employer and its staff, and supply contingencies in the case that certain key people fail to demonstrate any new skills you may require from them.

2) An object-oriented analysis. At an early stage of a project the best you may be able to provide is a UML of the abstract objects, but you should at least gain an understanding of how all the business objects and methods fit together, as well as a sense of data flow and any timing dependencies.

3) A strategic analysis. You should understand the strategic plan of the company and of the I.T. department, and should detail how this development effort will support these plans on all time scales. You should also accommodate the Gestalt of the SDLC to your company's ever-changing environment.

Before coding can begin you will need to understand many other components (screen wireframes, project timelines, implementation strategies, physical architecture, state diagrams, and coding and security standards), but these are fairly typical of all projects. Take extra care however in your Project from Jupiter to be attentive to generating the analytical viewpoints from all three dimensions.