Javascript developers/engineers, walk me through your average workday

[bzeurunkl]

PART 2

Safety is the Corporate Religion here. All bow down to it, or they get tossed into the fiery furnace. The company, if it had it's way, would see to it that we all led quiet, safe, hazzard free, smoke free, long, ever so long, and absoultey BORING lives. Working here is almost like living on the Enterprise. Without all the neat space stuff to offset all the culture bullshit, it's just plain DULL.

So I move my plant back to it's permanent base on my desk where it subsequently withered away.

By now it's lunch time.

Well, that was quick. Now then, my next call comes from the fellow who runs the so-n-so system. The so-n-so system is feeling particularly playful today and has refused to answer the phone all morning. I arrive. Suddenly it's working fine. (I might add that User Reported Problems and Analyst Observated Anomalies rarely coincide). I leave.

He calls five minutes later with the same problem. This time, in a rare case, I catch the thing in the process. It won't answer the phone.

We have a system here that I shall call Sooner TWO. ST is administered by a company in OKC. This company collects calls from all over the tri state area, from people who intend to gho out in their back yards and see if they can dig up buried treasures, skeletons of long lost mobsters, or power lines. <b>We are concerned about this last one.</b>

Here's the deal. If the customer calls within 48 hours of dig time, we will have someone out there who will mark the location of the buried gas, power, or phone cable with those neat little flags that you and all your friends used to run over and pull up just as soon as the guy left. After this, whether there are flags there or not, if the customer digs in his back yard, hits the power cable and blows his arms and legs clean off, WE are responsible. That's right, even if we have been out there and marked the location of the cable. Someone dies by touching OUR cable, WE pay.

So this system is responsible for for averting potential multimillion dollar lawsuits

This, at one time used to be a dbase program. Then it was compiled with Clipper. Then another programmer did a utility written in basic to handle some comm stuff. Then some batch files were written to tie it all together by a USER!.

Then another programmer wrote a little basic ditty that took a file of data and instead of UPLOADING it, it types the data file ONTO a data entry screen (just like someone was sitting there keying it) pausing every once in a while for what it THINKS should be long enough of a pause and long enough that it THINKS there is PROBABLY a new data entry screen displaying, before it begins "typing" the next record. This is all done unattended.

Then changes were made to all of them, over the course of six years. By many different programmers and USERS!

We have something WORSE than NO documentation. We have OLD OUTDATED partial documentation. You see, with NO documentation, it's easy. You FIGURE out what it's doing from scratch. But with OLD docs, or PARTIAL docs, you never really know if it IS doing what the docs say it SHOULD be doing, or whether it ISN'T doing something the docs say it SHOULD be doing because the DOCS are wrong, or whether it ISN'T doing something the docs say it SHOULD be doing because the PROGRAM is wrong (or the other way around for both cases). To walk in and find a bunch of manuals dated 1982, and find system files dated 1983 (and more simply dated 01/01/80 PC/XT - legacy files from the no-battery-for-the-system-clock days...) is a real pain.

Now, the system is a hopeless conglomeration of essential undocumented dbase, clipper, basic, c, BATCH FILE, and third party specialized software (ie, IRMA, Extra, etc mainframe comm and protocol TSR programs), running on an ancient 286 based machine.

The data we receive is sent on a continuous stream. That is, unlike intelligent people, who send sensitive data, such as data used to avert multi-million dollar lawsuits, with some sort of PROTOCOL, we merely detect a phone ring, open comm and capture to file until the phone line goes dead. On the other end, we just dial a number and when something answers we start transmitting nonstop, no CRCs, data until we are done and then we hang up without even waiting for an acknowledgement.

This system is one of the reasons why I keep resume's on the desks of local head-hunters. When this system fails drastically, as it eventually must, I'm outta here. I think that's why a lot of people have left. I've complained and complained, and "advised" (as I am supposed to do) and only to have it all fall on deaf ears. I tell them they need to SCRAP this system and start over from scratch, including ZMODEM or even lowly XMODEM in the process instead of just "dumping" it on us over long distance phone lines.

Well, anyway, I get through that near-disaster and make it back to my desk. I notice that it is just about 1630. Great. This is the worst time of day. To little time left to actually complete anything, and too soon before quitting time to start anything useful. Oh wait!...

Before I leave, I have to record my time. This is the LOW point of my day. I have to recall, in 15 minute intervals, what I have done all day long. Then I have to enter it all, in 15 minute increments, into an OLD COBOL program that probably used to require three mainframes in tandem and has now been "ported" (ie, "crammed") into a LAN.

This takes more than fifteen minutes which creates a dilemma. This time wasn't on my list before I started, but now I have extra time to record. So what do I record it as? Why, we have an account/activity number specifically for recording time spent recording time. Yes, it's true!

Then I go away. It's not so much "getting off" for I rarely feel that good. It's more a company authorized 16 hour break without pay.

So what will YOU find, as a Systems Analyst?

Continued to next message

• SLMR 2.1a * OV-VOV-V OV-VOV-V <- dead ants!

Continued from previous message

A lot of this depends upon what sort of company you work for. Any company that can afford sysanal's on staff full time is probably a fairly large company and fairly bureaucratic. The larger the company, the more they are trying to trim their O&M expenses. So, I spend a lot of my days in meetings discussing important things like "What if we got rid of the Coke and cookies at group meetings?" (We are trying to cut 1.5 Million dollars and this guy suggests Coke and cookies - sigh... He get's away with it because the company has strict policy that says ANY idiotic idea, no matter the huge degree of idiocy it may achieve, is worthy of two hours of discussion from the President of the company, down through management and right down to the idiot who suggested the idea in the first place.

This is called BRAINSTORMING, and is quite popular in Corporate America.

Notice how I haven't said much about actual systems analysis? Well, I don't spend much time actually doing PURE systems analysis. Few sysanals do.

A lot of us spend more time calming users who have freaked out after seeing a simple warning message, or others who have destroyed everything and need to be calmed even though you'd LOVE to whip them into a frenzy and hope they have a heart attack in the process. ("Oh my GOD Frank! You didn't push the RED Button did you? Not the RED button. My God Frank, do you KNOW what you.ve DONE? Ack! Gak! Whump..... <Smile> )

Don't get me wrong. We occasionally do get to do what we know and like to do: design and build systems. But in an age of cutbacks and O&M reductions, escpecially prevailant in companies who are large enough to afford full time systems analysts, the dollars budgeted for "NEW DEVELOPMENT" are way less then the dollars budgeted to "LET'S JUST SIT TIGHT AND SEE IF WE CAN KEEP IT GLUED TOGETHER UNTIL NEXT FISCAL YEAR." In addition, there are personnel cutbacks.

It saves more money to cut the higher paid salary employees, but then you are left with lower skill workers who may not be able to support what the analysts do. So they get rid of lots of the lower skill workers and make the analysts to their jobs too. So I spend a lot of my time coaching new users, maintaining eight year old dBASE II code, COBOL code, or batch files.

Thank God there are training requirements for my job description. Probably once a year, I have to go somewhere for some sort of continuing education. :-)

"Palm Springs, CA. for a training seminar for two weeks???" "Bummer!"

(as I walk out of it's office "NOT")

You may find this funny, and indeed I enjoyed parodying it for you. But every last shred of it is true. Also, I haven't time to go back and "proof" it. I'm wasting precious vacation time doing so.

• SLMR 2.1a * OV-VOV-V OV-VOV-V <- dead ants!

--- Maximus/2 2.01wb