Hi,
This month pulls from my programming and consulting days: how I solved working with management bullies, and used technology to solve short time frames and to assist in a screen-conversion project where I didn’t have any help.
All of these examples go back a ways in my career but the way I handled the difficult situation and used technology as an aid in these projects is still important today.
The Bully
This example goes back a few years. I was in a pre-sales position and I was well-versed with Oracle CASE (computer aided software engineering), one of the original application design and development systems from Oracle. The sales rep took me to a customer who bought the CASE product but was having major performance issues with it.
I arrived at the client site and was met by the manager, who was a huge individual. He was not in a good mood, as he had implemented the software but the 20 or so people using the software were not able to get much done. They would click on something and wait…click on something and wait…click on something and wait…get the picture? People were waiting several seconds per mouse click. They also couldn’t print their database diagrams on the laser printer they had purchased.
He really let me have it over the issues with the software. We were nose-to-nose and toe-to-toe. He towered over me. He was talking loud… he was right in my face…everyone in the department could hear his lecture to me. He seemed to believe that I had coded this software and all of its problems were somehow related to something I had coded into the software. He was very imposing and was clearly upset and these issues were somehow my issues.
I listened till his tirade was done then turned to the sales rep and said, “I don’t think I can help this person…I came here to help him with his problems but he feels all these issues are my problem, and I don’t have any problems! I’m ready to go.” This caught both the rep and the bully manager off guard and the mood changed quickly. I was an instant hero with the staff as they were all intimidated by him as well. I’m not sure they had ever seen anyone stand up to him before. The bully realized I was serious about leaving and that I really had no interest in his problems if he was going to treat me in such a poor way, especially in front of others.
I reviewed the install. This was a time when networks were relatively slow and they were attempting to run the software off a single network install.
I recommended that he purchase 20 larger disk drives and install a copy of the CASE software on each work station. The ‘slow’ issue was because just about every click of the mouse was making calls to DLL code back on the app server, and the DLL had to be pushed to the workstation for execution. When they installed the software locally, only the data was being transferred over the network and the slow application issues simply went away.
I had to be the bearer of bad news about the printer though; he needed to buy a pricey Postscript printer. Today, these printers do not cost much but back then, they were scary-expensive, to the tune of $20,000.
The bully changed his tune quickly when I stood up to him by informing him that I could probably help him with his purchase, but wasn’t going to be bullied into doing so.
The technical solution here was to properly diagnose the performance issue and make the correct recommendation.
When working with difficult people or difficult situations, you simply cannot have enough documentation. I know auto repair people who keep a running log on what they did to which car and a time stamp. Keeping track of what you did and when you did it can be useful information both for review time and if you feel too much is being asked of you.
If you are faced with a difficult project or are on a difficult team, keep this kind of documentation as well. If asked, you can easily provide information on your interpretation of meetings, tasks, problems, and progress. If you experience harassing phone calls, either from management or fellow employees, record and timestamp the conversation. Save rude and unprofessional voicemail and emails you receive. I’ve saved and used unprofessional telephone conversations to get my funds back (credit card refund) for shoddy work and bad equipment. It’s hard for people to argue their point when you have evidence of their being extremely rude to you on a recording. Stand up for yourself if you feel you are in the right and/or if you feel you are being mistreated.
The scary part of this story? Would have been facing that bully again had I not been right on the application performance issue.
The Huge Task
This was a consulting task where a team of us were barely on schedule working to convert a COBOL mailing label system over to Oracle. The team lead gave me an important program to write. This program was to take its parameters from the command line. These passed parameters could be in freeform, in that they didn’t have to be in any particular order. The program printed the bag tags in various customer-defined formats for mailing through the United States Postal Service (USPS). It’s been a while since I wrote this code, but as I recall, the parameters would direct the program to print in a variety of different formats for a number of different publications they did the mailings for. Seems the output side of the program was the easy part; I actually don’t remember the various formatting requirements.
I was definitely on a timeline. I didn’t want to disappoint the team and I DEFINITELY didn’t want to make the project go any longer, especially with a task that was deemed both important and difficult to do. I’m not one to shy away from a challenge, but I found the pressure to perform and perform well a bit scary.
The client wanted this program to be so flexible that it could not only handle the existing various bag tag formatted information, but also that if/when they acquired more clients, they could easily adapt the bag tags to the client’s existing format and not have to re-program a thing. So, the parameters were able to specify just about everything for each line of the bag tag.
I have written several parsers over the years, programs that read in a string and walk forward and sometimes backward to interpret what is on the line or in the text. I have written parsers that converted entire program source code and data layouts into Oracle applications and RDBMS DDL, complete with data load scripts.
This program was using a C program that would jstart jobs (SQL thru the Pro*C interface) that would make calls to the Oracle database and select the correct data, based on one of the parameters that contained a customer code.
I was given three weeks to code this. The team lead had no idea how I was going to tackle this task; he thought the request was a difficult programming task, he really didn’t know how long it would take or how the program would work. This was also more of an enhancement, as the current system didn’t really have such a task. They had a separate program for each different bag tag (each different client). This client wanted a single flexible program with passed-in parameters.
There would be financial penalties if the overall conversion went past mandatory completion dates.
Since my consulting background was in parsers, getting the program initially set up to bring in the commands was relatively easy for me. I remember it could do up to a dozen different commands, delimited by space between them and an ‘=’ sign for an option that was passed via the command. I treated the line like a string array. I simply walked along, saving the characters until I hit an ‘=’ or a space. I continued down the line until I hit a space or a ‘;’. The end of the options contained a semicolon.
Since I had a background in parsers, it took me just over a day to code the initial program and another two days to work the bugs out and get it printing the initial test bag tag.
I completed the task in about a week instead of three weeks. This made the project manager look very good because suddenly we were way ahead of schedule. Success can be so sweet. This could easily have been scary had I not had a good handle on being able to process the parameter line. There was no Internet then, or any other resources to draw upon.
I was the ‘software hero’ instead of the ‘software ***’.
The lesson? Draw on your past experiences to solve the task at hand. Programmers today have a wealth of online video, YouTube, blogs, and other online resources to draw from. Understand the process, break down its tasks, and see if the problem is as big as it’s perceived.
The Overwhelming Conversion
This one goes back to my COBOL days but it’s a good story on using technology to assist you with your large conversion projects. This really isn’t a scary story but more of of a ‘can I do this, will it work?’ kind of story. Will my line of thought be a waste of time (programmatically generating the code)? How long will it take me to produce the conversion program? And will I have to put in overtime on my own time to keep the conversion within the timeframe if it doesn’t prove to be successful?
The company had purchased a new way of handling screen interaction with the terminal network. It was Burroughs version of IBM CICS, but simpler. There were 30-some programs under my control that needed their screens converted to this new method. Some of the programs had as many as a dozen various screens within them.
The old system had the screens pretty much laid out in the program, both outbound and inbound. In the new system, the screen layout itself was within a front-end processor, so the outbound layout data locations needed to match the screen layout and the inbound was just the data. The data item lengths needed to be perfect, in both directions.
A PERFECT application for a program! Computers are great at both counting things and performing repetitive tasks.
This may have been my first parser. It definitely was my first code generator.
I was given three days to convert each program, so roughly a quarter of a year for the entire project.
It took me three days to write the program, a COBOL program that opened the COBOL source code as a file and produced updated COBOL source code! I parsed down through the working-storage section to find the screen layouts. When I got to the Procedure Division, I knew I was done. This project was a long time ago but I recall that there was syntax that made these layouts easy to identify. I was able to grab the column name and length and create a file of output that was named after the screen image and contained the COBOL code for both the outbound screen format and the inbound data lengths.
I used technology to do the hard part of making sure the data field locations were both in the correct position and the correct length. It took me minutes per program to strip out the old code and install the updated code. I did test to make sure that the updated program both painted the data into the screen correctly and returned the data in the correct order. I don’t remember for sure, but it seems to me that I could do around two or three programs a day. I suppose I could have written another program to strip out the old code and insert the new code!
I used technology to aid me greatly in this project, getting it all done well inside of the first month, letting the computer do the boring/repetitive/error-prone part with ease.
The process worked so well, the company used it on the other online systems, and this process eventually got incorporated into when changes were made to some of these screens.
I got a promotion.
I hope you find these tips useful in your career and in handling difficult situations and people.
Dan Hotka
Author/Instructor/Oracle Expert
Start the discussion at forums.toadworld.com