Railroaders' Nostalgia > Where's 1008? (1/6)

It was about 8am on a Monday morning in 1979 in the BN Havre MT dispatchers office. I was working Havre West. The Superintendent asked from the door into the Chief’s office: Where’s 1008 (Amtrak No 8)?
 
Whitefish.
 
I never looked behind me toward the door, I just kept on working.
 
At some time after 9am, the Superintendent asked from the door into the Chief’s office: Where’s 1008?
 
Whitefish.
 
I still didn’t look back toward the door.
 
Again, he walked away without a word.
 
Why?
 
This is a long story, but is consistent with my repeated theme of excessive workload. It is a critically important theme. I regularly read or hear horror stories about dispatching in the 21st Century. It was bad in the late 20th Century and it keeps getting worse.
 
As time went on and management continuously added workload, I found that attempting to be scrupulously correct in everything that I did wasn’t enough. There were times that in trying to keep up with workload as the required speed would allow, even attempting to do everything as correctly, I scared myself pretty badly, realizing what I was about to do, having the feeling that I missed something when I hadn’t, forgetting to do something important, and realizing that I didn’t really know what I had out there as I was adding more and more to the mess.
 
I decided that yes, you think you’re a hero if you can work that fast and make it work as more and more gets piled on the job, but you’re fired if it doesn’t work out. You’re lucky if you don’t kill or injure somebody or bend anything. Management doesn’t really care about trying to be a hero; they really care about failing at it. I watched too many colleagues do time for being heroes, working at a regularly increasing pace, and occasionally taking shortcuts that eventually became accepted practice. I decided that never again would I push too far because the company increased the workload to the point of being impossible to do correctly.
 
I wrote this in Elements of Train Dispatching Vol 2:
 
KNOW YOUR LIMIT
 
Regardless of the means of traffic control, the most dangerous thing a dispatcher can do is to attempt the impossible; to push beyond the ability to handle the traffic. The following advice may not be popular with some railroad managers, but it extremely important to self-preservation and safety and should be heeded.
 
If you feel that you are losing control; if you look at the CTC display and can’t associate the various indication lights with real trains and maintenance workers, if you feel yourself taking shortcuts to keep up; if you are scribbling notes about train calls, track conditions, or other important matters; if you catch yourself at the unthinkable, such as starting to send track authority without the required protection; whatever else makes you feel that you are losing control:
 
STOP!
 
If there is even a faint possibility that you may have lapped trains, lapped a train with track maintenance, or missed passing out a speed restriction, stop the trains until you are sure.
 
Don’t add to the mess. No new trains, no phone calls, no radio. Until you have a complete handle on what is going on, the possibility of seriously screwing up is great.
 
If it is safe to do so (you are sure that you have not set up a dangerous condition), get out of the chair and leave your office/cubicle/pod/workstation. Go for coffee, go to the restroom, walk around the hallways or the parking lot. Being agitated and unable to think clearly happened before you realized that you lost control. Being agitated and unable to think clearly must be stopped before you can regain control. If you feel that you may have set up a dangerous situation, it is not safe to leave. Stop all of the traffic. Call trains on the radio and/or set signals at stop (but don't take signals down in the face of trains). When they are all stopped...go back to the beginning of this paragraph.
 
What happened?
 

The story started in 1971. At the time, I was in the B&OCT dispatchers office in Chicago.
 
The Chief Dispatcher, John Jenkins, had no tolerance for shortcuts, lack of knowledge, or inattention to the job. Once in a while, an ICC accident report would include train dispatcher involvement in a collision or other incident. The report would be placed in the live file (a file of current instructions such as setouts, pickups, which yard a train goes to, coming movements, etc.). Everyone read the live file when coming on duty and kept it current throughout the day, removing expired information to the dead file (never throw anything away) and adding information. If there was an accident report in there, we read it.
 
One morning, JFJ personally handed me an accident report. It wasn’t in the live file. It had not been in the live file. He had written in black crayon (we didn’t have felt tip pens…and we used straight pins in lieu of staples) in large letters on the cover
 
DON’T EVER DO THIS
READ, SIGN, RETURN TO ME
JFJ
 
The report was a pretty sad story about a BN head on collision at Sheffels MT.
 
BN had a branch line job: Pacific Jct. (Havre) – Great Falls, Mossmain (Laurel) – Great Falls, Sweet Grass – Great Falls, and some other branches. There were two other districts, Havre East (Havre – Bainville) and Havre West (Havre – Whitefish). There was a strange shift arrangement. The first trick branch transferred to first trick Havre East, who then transferred to second trick an hour later.
 
The operator at Havre was the wire chief, handling message traffic and circuit trouble and maintenance as well as train orders. The dispatcher jobs and the operator job were so busy that shortcuts had been developed in order to handle the workload. As the dispatchers cleared trains, the operator left the orders on the train register table for the conductors to get when they got on the book. The dispatchers fixed trains long in advance as there was a chance in order to have the orders ready for trains as they came on duty without delaying them.
 
On the day of the collision, first trick branch fixed a Havre – Great Falls train in the early afternoon, several hours before the train was on duty. The conductor was in town for some other reason and stopped by the telegraph office to see if his orders were ready, as they generally were. Sure enough, he was fixed. He got on the book with the information except loads, empties, tons, and leaving time, which he would give to the yard office by radio to relay to the operator. As usual, he didn’t go back to the telegraph office when he came to work. He got his bills and list at the yard office and went to the caboose.
 
Meanwhile, Great Falls called a train for Havre. The west man wasn’t on duty yet, so the second trick dispatcher busted the clearance (told the operator to mark it void and file it), stuck out a flat meet and cleared the west man again. The operator didn’t take exception to not finding the running order on one of the hooks on the table for undelivered orders, made copies from the file copy in the drawer, apparently thinking that the delivery copies had been accidently thrown away. He put the new clearance, including the recopied running order and the meet, on the train register table and forgot all about it. The dispatcher fixed up the train at Great Falls and cleared it.
 
Later, there was an OS at Havre and an OS at Great Falls. There was nothing apparently amiss and the dispatcher didn’t pay particular attention.
 
The two trains hit head on at track speed at Sheffels, killing four and injuring several others. The new clearance with a meet order was still on the register table at Havre.
 
I didn’t know exactly where Havre was and certainly had no idea that I would be working in that office in nine years. The only place that condition could remotely apply to B&OCT would be the MILW station at Faithorn, which wasn’t busy, but was not always open 24 hours. I put the lesson in memory and went on.
 

In 1972, I hired out as a train dispatcher on SP in Bakersfield CA. Taking road trips to learn the railroad, I discovered the operators at Fresno leaving clearances on the register table for crews to find when they came to work. When I discovered that. I promptly started asking the operator to call me when the conductor was there before I would clear the train. That was unpopular, but I explained the reasoning to FMB, the Chief, and he supported me in my one-man crusade (stopping short of requiring everyone to do it).
 
I went to work as an operator at Bellingham WA on BN in 1976 and discovered that the second trick operator would clear the night switch engine as soon as 794 (passenger) passed, walk to the freight house and leave the orders on the table in the switchmen’s locker room. The switch jobs would leave their orders (usually just a check on No 793 or No 794, the passenger trains) on the table for the convenience of the next shift, so there was sometimes a pile of orders and clearances on the table. Sometimes, they even took a set from the wrong date, merely looking for something saying that No 794 has passed Bellingham. I started cleaning them up every night and had asked the switch crews to not leave the orders on the table at the end of the shift. Going home and telling the dog would have been more effective.
 
Orders on the table in the locker room just about resulted in a disaster one morning when I had the orders for the morning switch job on the telegraph table in the office, they came to work, found the orders for the night job on the table in the locker room, and took off. I had a form Y (track maintenance limits) that the night job didn’t have, the railroad was missing on a bridge just south of the station. The engine was tied up on a track between the red flags.
 
I got the switch job stopped just short of diving into the abyss. I had managed to get on at around 10 mph and was in the cab yelling PLUG IT! because the engineer was on the other side of the engine from me, looking back for hand signs, not looking forward. As the engine came close to the end of the railroad, it was firsthand experience of the edge of disaster.

In 1979, I found myself in Havre MT, the owner of relief Havre West: Friday 3d, Sunday, Monday 1st, Tuesday Wednesday 2d.
 
Havre West was an ugly job: 252 miles including, east to west, 103 miles of single track CTC, 51 miles of double track ABS, 31 miles of single track CTC, 20 miles of double track ABS, 4 miles of single track 261 (bi-directional signaling, kind of like CTC but the rules are different), 13 miles of single track CTC, and 10 miles of double track ABS. MofW could use a track car lineup in CTC in lieu of the inconvenience of a permit, so the entire line required track car lineups – two a day Monday through Friday plus one each for any off-hours trouble calls. For the convenience of the Gandys, management had decided that the entire 252 miles would be covered by one lineup. There was switching on the main all day at Shelby, the Great Falls to Sweet Grass and return local using the mains at Shelby, there were two locals between Whitefish and Coram (the west 10 miles of double track ABS), and there were light helpers between Whitefish and Blackfoot – lots of them.
 
The dispatchers were employing shortcuts in order to keep it all moving. One of them was the bogus lineup. In order to not miss a train on the lineup (a firing offense, the same as lapping up train orders), they would fill the lineup with bogus trains: an extra west every 15 minutes from Havre, an extra East every 15 minutes from Whitefish, a light helper every 30 minutes between Whitefish and Summit and a light helper every 30 minutes between Summit and Blackfoot. That saved a lot of time in figuring out exactly what should be on the lineup when, but the lineup was worthless to anyone wanting to use it. They would have to call the dispatcher and get a lineup update, at which time, spatch would give a few hours worth of real figures. That would have been just as much work as putting out a good lineup, had they written down in the lineup book all of the updates that they passed out, as the rules required, but they didn’t.
 
The dispatchers would give temporary speed restrictions to trains verbally, without giving them a slow order, which on first trick wasn’t that hard because Montana had a full employment law for operators. BN was not allowed to close any agency. There were 16 open offices between Havre ad Whitefish, all but three of them in CTC territory. But, to keep up, they would call a train on the radio and say 10 mph between 106.5 and 107.9. The conductor would respond OK dispatcher, at that was that.
 

---

I discovered that nothing had changed since 1971. Dispatcher would clear trains hours in advance and the operator at Havre would leave the orders on the register table. I was the new guy in town and about to become really unpopular.
 
While constructing what was going to be in the track car lineup, the dispatcher also had to manage the railroad. That’s why they didn’t bother, putting out a quick bogus lineup in lieu. There were a lot of trains. My lineups were always at least two pages, and sometimes three. Especially on 1st trick on Monday, the 11am lineup could take an hour to develop good figures, protect times with train orders (I worked with guys who thought I was silly…until they did time for a train overrunning their own lineup), and transmit…with constant interruptions. Often, I was so far behind when I finished that I couldn’t deal with any more track work requests and sent the gandys to go polish the hubcaps or some other constructive work nowhere near the track. It was actually easier to deal with them on an off-hours call because then we could give them a lineup for the short piece of railroad and time that they needed.
 
Trains didn’t escape my scrupulous attention. After twice, the operator at Havre telling me that the absent conductor was there so that he could clear the train and leave the clearance on the register table, I started checking for myself. From my office, there was direct line of sight through the window of the Chief’s office, down the hall, to the telegraph office window and register table at the other end of the building. No conductor, no clearance. If I was buried with something when the conductor showed up, he waited.
 
There were slows and slows and slows. Management wanted all trains fixed with everything at Havre and Whitefish (gotta show that those operators in between don’t do anything so the jobs can be pulled when BN takes the state to court). It wasn’t unusual to have a half dozen slows at Havre and Whitefish and more coming in all the time. I made a point of not fixing any trains when I had a slow request that had not been turned into a train order. Turning it into a train order involved tracking down every train that didn’t have it and keeping those trains from going through the slow before I could get the order to them. Having operators helped a lot, but there were still some to stick out on the radio.
 
I was well known for trains waiting at Havre and sometimes at Whitefish for hours for their orders. At least, the Whitefish operators (also the Wire Chief as the Havre Operators were) were actually delivering them to the conductors and not leaving them on the register table. I was comfortable with fixing trains at Whitefish in advance as convenient to me.
 
In the year that I worked Havre West, three guys did time for shortcuts that went awry, yet it went on and on. However, nobody said a word to me about delaying trains and sending the gandys home early. Management didn’t like it, but they knew they had nothing legitimate to say. After one of the incidents, the Chief asked me what was wrong in there (Havre West). I replied: we can’t keep up with it. They keep trying; I don’t.
 

On this particular Monday morning, I came in at 630am to work first trick at 7am. 3rd trick had been 8 hours of hell. There was a lot of traffic, there were a lot of track conditions coming up, lots of gandys out there trying to fix them or alternatively, sticking out a slow. The gandys needed lineups, and he had lineups hanging (issued). There was a big pile of notes on the table, mostly requests for slow orders and form Y orders. I’ve known two guys who did time over a train going through track work without the form Y for the work.
 
The 3d tricker tried to explain everything that was going on, but he had lost track of just about all of it. He couldn’t remember who he told what, what lineup figures were good and what ones had to be watched, what trains were using the helpers (Havre West managed the Whitefish – Blackfoot helper power and crews), and other important things. He was exhausted from pounding for hours, shortcutting to keep it all moving.
 
I had worked with the office chairman on justification for splitting Havre West at Cut Bank as it had been decades ago. The company actually accepted the idea, but the dispatchers union General Chairman, in the Cicero office, traded our split district for one in his office. Thereafter, I was really underwhelmed with the organization that I had once been proud to be a member of.
 
The third tricker gave me everything he knew to the degree that he could remember. I told him to go home and don’t worry about having done something that would get him canned, I’d fix it.
 
That was it. The railroad came to a stop. I had to track down every train on the road and look for slows that it didn’t have and to be sure that it was on the lineups and not ahead of its time. Then there were slows to stick out from the pile of notes on the table. To do that, I had to stick them out at Havre and Whitefish, figure out what trains on the road would need them, not let them get through the location, and stick them out.
 
The operator at Whitefish told me that she expected what I was going to do next (all of my operators in the 24 hour offices, except Havre, had the same relief shift as I did, so we worked together five days a week). The third trick operator had told her that he thought the dispatcher had lost it. I had stopped trains on the road that were in danger of getting through a slow with nothing on it. Now it was time to stick out orders. Every order that a train on the road needed had to be sent to that train, or an intermediate operator, as well as Havre and Whitefish.
 
I had been, as a colleague once described, busier than a one-armed paperhanger for an hour when the Superintendent showed up at the door.
 
Where’s 1008?
 
Whitefish.
 
1008 was on time and due to leave in a few minutes. I was a long way from having everything they needed stuck out.
 
When he came back over an hour later, I was almost caught up, but still sticking out train orders, and short lineups for some gandys still needing to get out and fix broken stuff. I didn’t put out the 7am Havre – Whitefish lineup I had been told don’t ever do that, the lineup had to be Havre to Whitefish weekdays. I did it anyway. I didn’t stick out the regular 7am lineup. If work wasn’t immediately essential, I told the gandys to call back in a few hours and try their luck, or better yet, go change the oil or something.
 
1008 got to Whitefish a little early that morning and left something like 90 minutes late.
 
Everything was documented on the trainsheet. I did everything correctly, taking no shortcuts.
 
Nobody said a word to me about the delays that morning, as they hadn’t for all of the other days of freight train delays and gandys regularly getting a half day off because I couldn’t deal with the workload safely.
 
Run your railroad. Don’t let it run you.

TAW



Edited 1 time(s). Last edit at 06/15/16 13:42 by TAW.

.....and that, ladies and gentlemen, is precision.

Outstanding report. Fascinating study of how (and how not) to perform critical functions properly. Major kudos to you. After reading these posts, I'm not as concerned for the location of 1008 as I am for where the Aspirin bottle is!

John Ford

Posted from iPhone

Fascinating read. I'm a railfan, not a rail, and just spent the last few days reading every post from MDO and TAW on the Railroaders' Nostalgia board. Too much great stuff to begin to comment on it all. There are some themes that pop up over and over. It seems the sequence goes something like this:

1. Rails figure out how something works. It generally goes well until someone gets hurt or some equipment goes in the ditch.

2. Management enacts a rule. It probably makes it safer, but adds time.

3. Neither management nor crews like the slow down, so old ways continue. Right about here is where the corporate BS of a "culture of safety" goes out the window.

4. Someone like TAW steps in and says no more. For their trouvle, they at best get ignored, and at worst get flack from crews and higher ups. The only silver lining is management knowing they can't officially say ignore the rules, so (hooefully) it ends at a yelling match that really goes nowhere.

5. With no TAW around, the old ways lead to another run jury or more equipment in the ditch.

6. Management now pulls out their job description, skips the safety part, and goes to the bold underlined "Enforce the rules" part. Anyone below the first manager to act is subject to corporate wrath.

7. When it's all done, the railroad is without a few experienced guys for at least a while, the manager who acted feels good because he finally did something. Go back to number 1 and start again. No root cause analysis, no getting to the bottom of things. Maybe another rule in the rulebook at best.

Safety first, except for all the other stuff really first. Sounds more like Animal Farm than a Culture of Safety.

Keep 'em coming, TAW! Applause from the sidelines for taking pride and time to do it right, and the time to tell us all about it here.

Posted from Android

Jared Hamilton
Scott Depot, WV

     An employee once said, " safety is of the utmost . . . . until it becomes a little costly " when he figured out what the mis-management was doing. That was in the 1980s.

     In the 2000s, the mis-management was telling the twit brains they were bringing up that, " you don't have to know anything about whats going on, your job is to manage the people ".

     And now its even worse.

     An employee once said, " safety is of the utmost . . . . until it becomes a little costly " when he figured out what the mis-management was doing. That was in the 1980s.

     In the 2000s, the mis-management was telling the twit brains they were bringing up that, " you don't have to know anything about whats going on, your job is to manage the people ".

     And now its even worse.

     These are the stories we need every day so everyone is educated about what goes on behind open doors.

TAW, great story once again and quite a lesson for working rails. I like the your stopping trains while you sort stuff out.  I wished I had been working somewhere in one of your territories (but I have known really good, professional dispatchers over the years). They - you - are worth their weight in gold!

When hand-offs are that oral, something is terribly wrong.

What an "efficiency expert" should be doing, instead of stop-watching activities, is designing systems that make it easy and foolproof for a dispatcher to continuously document the status of the railroad and to make it easy for the relief dispatcher to digest it all at shift change.

One should be able to "look" at the status. And see it all. At any time.

If you cannot measure it, you cannot manage it.

Designing such a system requires empathy, vision, ingenuity and engineering. Which is what industrial engineering is all about.

Best regards,

Rob L.

Great stuff as always TAW.
I was raised to want to do a good job, and that by doing so I would help my company succeed, provide satisfaction from my work and increase my chances of advancement and compensation.
The idea that profits, and that this quarter's stock price, are all that matters (i.e. the actual work and the people doing it are purely means to make money), is so prevalent today that I think most people just accept it, and to say otherwise invites charges of being a socialist.

Please continue posting everything you can, and I hope someday you open your undisclosed storage unit where all your secret records are hidden.
-Tom
 



Edited 2 time(s). Last edit at 06/17/16 05:59 by RRTom.

rob_l Wrote:
-------------------------------------------------------
> When hand-offs are that oral, something is
> terribly wrong.
>
> What an "efficiency expert" should be doing,
> instead of stop-watching activities, is designing
> systems that make it easy and foolproof for a
> dispatcher to continuously document the status of
> the railroad and to make it easy for the relief
> dispatcher to digest it all at shift change.
>
> One should be able to "look" at the status. And
> see it all. At any time.

That ability was intentionally removed by railroad management.

Go to virtually any traffic control office of any railroad throughout the world (other than in North America) and you will see a traffic (stringline) diagram in use. (An exception that I have observed is South Africa, where the diagram is no longer used, following US practice, replaced by only the CTC panel indications.)

We used to have the equivalent in the trainsheet (same information, different format). The whole situation was there; a real time model of what was in the field. The trainsheet was taken away as needless clerical work, taking away the cognitive connection between the dispatcher and the trains. In CTC, we had the CTC graph, which also provided an overview. Those were taken away as needless clerical work.

In 1979, we had the trainsheet...and virtually no time to write anything other than basic required information (and sometimes not even all of that).

The modern systems of which I am familiar record the information that FRA requires on the trainsheet and provide no cognitive benefit to the dispatcher. Not only is there no overview, other than the CTC diagram (some of which are so poorly designed that they are nowhere close to representing an overview), but checking information that required a glance at the trainsheet requires clicking this in order to click this in order to do something else that will show some information about the train in question.

Industrial Engineering can develop technological solutions that provide the overview, but is seldom used in that way. I worked on several systems for BN, each of which was killed primarily because of the disregard of the users (manifested in a complete failure to understand what the systems should do and why) by the IT folks. In many of those encounters, I was regularly treated to the IT folks talking about users with the same disdain that would be used to describe the product of the No 2 end of a dog. Part of the responsibility for that situation lies with the IT folks. Part of it lies with the folks who hire the IT folks.

>
> If you cannot measure it, you cannot manage it.

Once again, in order to measure, you need time to record.

>
> Designing such a system requires empathy, vision,
> ingenuity and engineering. Which is what
> industrial engineering is all about.

Such a system existed. Once upon a time, you came to work, read the live file, the orders, the permits, the lineups, then the guy you relieved went through the train sheet one train at a time, giving you a synopsis of the situation and things that are noticed but not necessarily written:
855 coming at R
903 just left Q. Jones is being Jones; they took 40 minutes to make that ten car pickup at Q
62 out of T
750 coming at M watch him he took 6 minutes too long getting up into N.

That helped fix everything in your mind, correlating the real situation with the written situation. It was the same kind of things you would notice about your trains as you worked.

When workload is increased to the point that there is no time to write it down (or type it), or even no time to properly protect conditions without extensive delays, no amount of systems or industrial engineering will fix it.

The loss of cognitive connection between the person and the activity because of automation is currently a serious concern of some folks in the aviation industry. Planes have fallen out of the sky because of automation so extensive that the pilot is removed from the reality of flying the plane. When the automation can no longer cope with the situation, the pilot, disconnected from flying the plane, is expected to instantly step in and remedy the situation...after figuring out what it is.

The pile of notes about track conditions was a result of attempting to keep up with the rate of the receipt of information. When the prescribed procedure takes longer than the rate of the activity requiring the procedure, the workload is excessive. One of two things will happen: trains will stop while the procedure is followed, or workarounds will be developed to facilitate the rate of activity. Workarounds include increasing the amount committed to memory, requiring more debriefing, and quick notes of activities conduct that are intended to facilitate memory, but also become overwhelming.

Now and again I hear stories of (and sometimes see in person) modern train dispatching working conditions in which even the systems that are supposed to facilitate work require more work than the manual ways they replaced. Once again, the responsibility lies with the system designers and/or those who hire them. Peter Josserand wrote extensively in the 1945 edition of Rights of Trains about the mental processes of a train dispatcher. 71 years later, the people who employ train dispatchers and the systems folks who are supposed to facilitate that activity, in spite of the seven decades of intervening opportunity for further study and better understanding, demonstrate virtually no understanding of that knowledge.

TAW

TAW and all, I would like to shed a little light on something here:

I see "blame" being placed on the "programmers" here and there, and while that may be directly true, there is of course more to the story.

I am in IT. Have been for 15 years now. (OMG, is that really true, 15 years, wow. Time flies.) Where I work full time my title is Network Administrator. My own company business card says Network and System Administration. What that means is that I am the catch all, jack of all traders, master of none. There are 2 types of people in IT. Those who are generalists and those who are engaged in specific parts. 

People in IT with administrator in the title where many hats, whether or not they put them on.

However, programmers, engineers, analysts, technicians, help desk and such others are focused and trained on specific aspects of IT.

Programmers (generally speaking) only know how to create code to take given data to create a desired outcome. This is absolute, whether or not the data or outcome is static or dynamic. They do not see the big picture, the why, how come. That is not their job. That is the job of the administrator. Within IT, there is a standard running joke: The programmers blame everything on the administrators. The Administrators blame everything on the programmers.

I am not sure how many reading this will understand this, but big "Code Red" stories that came out about 12 years ago is exactly the result of that joke. It happened because programmers had created gigantic security holes in their programming. BUT it was not really their fault, they were just following orders. Administrators took their work at face value, never considering or testing things. Programmers never thought about security because it was never brought up to them.

So, getting back to my point: Yes, the dispatching software the programmers came up with did not work out in real life. But that is because they had no knowledge of real conditions and expectations. They just went by the information that was fed to them.

In other words, if the programmers had been allowed to sit down with dispatchers and observe and learn what the dispatchers go through, the software then created by those programmers would have been useful and worthwhile.

That last paragraph said a WHOLE LOT in just a few words. That's what I told my boss: don't give me an off the shelf program, give me what I need and I will tell you what I need.  It fell on deaf ears.  Why?  Money.

jst3751 Wrote:
-------------------------------------------------------
> TAW and all, I would like to shed a little light
> on something here:
>
> I see "blame" being placed on the "programmers"
> here and there, and while that may be directly
> true, there is of course more to the story.
>
> I am in IT. Have been for 15 years now. (OMG, is
> that really true, 15 years, wow. Time flies.)
> Where I work full time my title is Network
> Administrator. My own company business card says
> Network and System Administration. What that means
> is that I am the catch all, jack of all traders,
> master of none. There are 2 types of people
> in IT. Those who are generalists and those who
> are engaged in specific parts. 
>
> People in IT with administrator in the title where
> many hats, whether or not they put them on.
>
> However, programmers, engineers, analysts,
> technicians, help desk and such others are focused
> and trained on specific aspects of IT.
>
> Programmers (generally speaking) only know how to
> create code to take given data to create a desired
> outcome. This is absolute, whether or not the data
> or outcome is static or dynamic. They do not see
> the big picture, the why, how come. That is not
> their job. That is the job of the administrator.
> Within IT, there is a standard running joke: The
> programmers blame everything on the
> administrators. The Administrators blame
> everything on the programmers.

~~
~~
> So, getting back to my point: Yes, the dispatching
> software the programmers came up with did not work
> out in real life. But that is because they had no
> knowledge of real conditions and expectations.
> They just went by the information that was fed to
> them.
>
> In other words, if the programmers had been
> allowed to sit down with dispatchers and observe
> and learn what the dispatchers go through, the
> software then created by those programmers would
> have been useful and worthwhile.

That's why I (I hope I remembered to everywhere) referred to system designers, not programmers.

The system designers were once in a group called systems analyst. You've been in the business 15 years, so perhaps the custom has changed. Long ago, someone designing a system was prohibited from talking to the employees doing the work or even to know exactly what they were doing. Computers and the big bucks expended upon them required a new paradigm, and that's what the clients were going to get....and that's what they got.

I have also encountered computer science graduates who have no experience other than computer science, but they feel that they are an expert at anything and everything by virtue of the computer science degree, just the way that some MBAs think that they know everything by virtue of their degree.

I long ago, when I was being assigned to some IT projects at BN, I suggested that the company had a large body of pretty good hobbyist programmers (that's where I'm at) who, when teamed with a real IT pro, could develop some awesomely effective systems for the railroad. The reaction from IT management was NO...JUST NO! Don't bring that up ever again!

The customers are at fault for not understanding how to facilitate their own operation and for not requiring the participation of experts in their business. Young computer hotshots (actually, young any kind of hotshots) are at fault for thinking that if they don't already know it, it must be unnecessary.

tomstp Wrote:
-------------------------------------------------------
> That last paragraph said a WHOLE LOT in just a few
> words. That's what I told my boss: don't give me
> an off the shelf program, give me what I need and
> I will tell you what I need.  It fell on deaf
> ears.  Why?  Money.

I work for me and I write most of the specialized stuff I need. The result takes longer to achieve, the first time, but is so much more effective in the long run.

TAW

i don't know how overwhelmed dispatchers are today or even what kind of dispatching software is being used.  what do today's dispatchers think of their software and workloads?  i read about the procedures and tools dispatchers used in the 70's and am amazed.

in the 2000's i dispatched using digicon.  i thought digicon was great and when it wasn't insane/busy, dispatching was one of the best jobs i ever had.  that said, there were a LOT of times when the amount of train traffic and m.o.w. i was responsible for combined with all of the other dispatcher's duties (phones, speed restrictions, calling crews, coordinating relief crews/vans, entering delays, etc.) were just too much to efficiently handle the railroad.

having less territory to dispatch back then would have been my solution BUT since nobody was injured when things were insane/busy the amount of territory dispatched did not change..........

66