It is interesting that you notice things when you are sensitive to it. Someone bought a new car in “Night Blue” because they wanted a car that no one else had – she had not seen any cars of that colour. Once she got it, she noticed many other cars of the same make and colour.
I was sliding down a slippery slope, and realised that another project I was working on had also gone down a slippery slope.
My slippery slope.
I wanted a small program to do a task. It worked, and I realised I needed to extend it, so with lots of cutting and pasting, and editing the file soon got to 10 times the size. I then realised the problem was a bit more subtle and started making even more changes. I left it, and went to have dinner with a glass of wine.
After the glass of wine I realised that now I understood the problem, there were easier (and finite) solutions to the problem. Should I continue down the slippery slope or, now that I understood the problem, start again.
I tried a compromise, I wrote some Python code to process a file of data, to generate the C code, which I then used. As this worked, I used this solution, and so; yes it was worth stopping and going up the slippery slope and finding a different solution.
I had a cup of tea to celebrate, and realised that I could see the progress down a slippery path for another project I was working on.
The slippery slope of a product customisation.
I was trying to configure a product, and thought the configuration process was very complex. I could see the slippery slope the development team had taken with the product to end up with a very complex solution to a simple problem.
I looked into the configuration expecting to see a complex product which needed a complex configuration tool, but no, it looked just like many other products.
Many products (including MQ on z/OS) configuration consists of
- Define some VSAM files and initialize them
- Define some non VSAM files
- Create some system definitions
- Specify parameters for example MQ’s TCP/IP port number.
The developer of the product I was trying to install had realised that there were many parameters, for example the high level qualifier of data sets, as well as product specify parameters such as TCP/IP port number, and so developed some dialogs to make it easy to enter and validate the parameters. This was good – it means that the value can be checked before they are used.
The next step down the slippery slope was to generate the JCL for the end user, this was OK, but instead of having a job for each component, they had one job with “If configuring for component 1 then create the following datasets” etc. In order to debug problems with this, they then had to capture the output, and save it in a dataset. They then needed a program to check this output and validate it. By now they were well down the slippery slope.
The same configuration parameter was needed in multiple components, and rather use one file, used by all JCL, they copied the parameter into each component.
During configuration it looks as if it copied files from the SMP target libraries, to intermediate libraries, then to instance specific libraries. I compared the contents of the SMP target libraries with the final libraries and they were 95% common. It meant each instance had its own self contained set of libraries.
I do not want to rerun the configuration in case it overwrites the manual tweaking I had to do.
I would much rather have more control over the configuration, for example put JCL overrides such as where to allocate the volumes, in the JCL, so it is easy to change.
A manager said to me once, the first thing you should do every day, once you have your first coffee is to remind yourself of the overall goal, and ask if the work you are doing is for this goal, and not a distraction. There is a popular phrase – when you’re up to your neck in alligators, it’s hard to remember that your initial objective was to drain the swamp.
ColinPaice 