One of the first steps in any application design is to work out what functionality is required. Almost always (certainly in document design anyway) the only requirements considered are the client’s requirements, but think about this for a second. Who will be doing most of the maintenance on the application? Who will be investigating any production errors that occur once the application is live? Who is responsible for testing? You’ve got three additional stakeholders in the application straight away right there, how much thought do you generally give to the requirements of maintenance, support and testing?
One of the things I always build into any application or script I write is some debugging functionality. Now I know that Dialogue has the ability to produce a “debug” file on the development platform and programming languages such as Perl have a huge raft of debugging support whether it’s natively supported or via an Integrated Development Environment such as Komodo but the problem with most of these is that they almost always mean going back to the development environment to find out what’s going wrong.
Data protection and security issues mean it isn’t always possible to copy a file containing live customer data to your development environment for debugging purposes. At the very least it will usually require some kind of formal agreement from the client which isn’t going to be easy to get at 3am.
With this in mind I almost always add a debugging switch to my applications. In Perl scripts it’s usually an optional script argument which, if set, triggers additional output, whether it’s to STDOUT or a debug file. With Dialogue applications I set up a user variable which is set to never reset. The default value is either ‘FALSE’ if it’s a boolean, or ‘0’ if I’m using an integer. I can then create rules using this variable to display text strings, page components and pretty much anything else I think would help when the variable has been set to somthing other than it’s default value. For instance if I have the variable USER_DebugMode_B I can create a rule containing:-
IF USER_DebugMode_B = TRUE THEN INCLUDE ENDIF
Then if for instance I have a table which contains lots of rows all conditioned around various combinations of the same five variables, I can add a text box to the page which outputs those five variables and use the above rule on the text box to make sure it only appears when I want to debug something. If an expected row isn’t appearing it’s then a simple change to add
-VARSET=USER_DebugMode_B,TRUE
To the control file, re-run the datafile through and straight away you’ll have the values of the variables being used to control the rows printed on the same page as the rows themselves.
Similarly if you have an application which makes extensive use of sections and paragraphs such as an insurance policy document (which often have many subtle variants of the same basic paragraph) adding a paragraph identifier to the text and applying the rule above as a text rule means that when it comes to testing and you need to verify that each paragraph comes out when and only when it is required you have the much simpler task of checking a series of paragraph identifiers against your test plan rather than a lot of (often jargon filled) text which you first have to compare the text against the spec’s to see whether it is the paragraph you were expecting or not.
There are lots of ways you can make use of this type of functionality and I’ll put together a more detailed article on it at some point in the future, but in the meantime, next time you’re writing a system design ask yourself if there’s anything you can add to the design to make your life and that of your colleagues easier.