Scripting, repeatability and GUI

Most programmers love GUI. It is so easy, so convenient, just point and click here, click there, drag and drop, repeat few times and problem solved. Who in sanemind would bother typing and writing code when can GUI do it all. The convenience rules. If you need to add or change something, it takes just few more clicks. Not a big deal, just add a few more easy steps. No problem – right ? Wrong !

What is wrong with this approach is that with few clicks after few clicks, the whole process becomes more and more complicated. It may need to be done differently, based on conditions. It may get different results if the order of clicking changes. If it needs to be done on more than single system, it start to be more like chore, than a shortcut. Something that needs to be done over and over is always very sensitive to human errors. And because the clicks do not leave audit trail, only the guy with the mouse in hand actually has any knowledge on what is going on. It is also very hard to keep the sequence of mouse clicks in CVS :-). And it is close to impossible to tell what was the difference between two series of clicks after they are done – one of which worked and one not.

To get repeatability, you need a process that starts and runs unattended, based on input parameters performs the task at hand. It can be either compiled program or script – but script is faster to create and easier to maintain. Therefore “scripting”. The script allows to be version controlled, contains explicit decisions and it is the minimal documentation of the task. Without script that starts from well-defined state at the beginning and properly handles all tasks / transformations, you will never know in which state you have ended.

Not all script were created equal. Many GUI tools allow you to perform tasks required and then generate scripts that (in theory) perform the same thing. This sounds like an ideal combination of both: you can keep using the GUI and by generating scripts, you keep trail of the changes for version control. Right ? Not quite, unfortunately.

The problem with generated scripts is, well, that they are generated and not written. They contain lots of repetitive information, many function arguments that are not really relevant to the task and no parameters. They are bad documentation because of the verbosity and can lead to problems with version control – small change in GUI setting may lead to very different script rendering.

Generated scripts *can* be used as started point to accelerate the initial steps, though. It is time consuming to start with empty file – but it is very often very educational and sobering experience. Generate first version of the script by tool, then developer takes over, changes the script structure, extracts parameters, re-factors repetitive steps to functions/procedures, adds comments. After this, the GUI should not be used as primary tool again, from that point on running the script should be the only way how to perform the task. If change is needed, edit the script and re-run it. This type of script is actually very useful: it is both documentation as well as tool, it can grow, evolve as the problem evolves and helps understand what is being done.

Typical area where this is extremely visible is database development. In Microsoft world, the Management Studio (former QA) is tool that allows do most of the configuration tasks via GUI. If also will generate the SQL for the task – but the SQL will not be as flexible as it should be: it may contain hardcoded references to database, it may not be complete (e.g. script will generate ALTER PROCEDURE which will fail if procedure does not exist, rather than test existence and drop if exist, then re-create). Formatting will depend on settings – e.g. you may or may not get the brackets around identifiers – which will make version control of such script an interesting exercise.

The GUI tools can be great help if they are used by skilled person who understand their power as well as their limitation and use the GUI to speed up development, but does not depend/rely on the GUI tool exclusively. It usually takes some experience to realize the GUI trap and develop skills/habits outside of the GUI tool. Therefore when looking for e.g. senior database developer, try to test him/her with simple repeatable task that requires working without or outside of the GUI. If he/she has problems writing scripts by hand, using command line tools and scripting in general, it is not a senior developer, regardless how many years of experience has on the resume.

Advertisements

Comments are closed.

%d bloggers like this: