All of my editing is On-Line in Run-Time.
That is why I have developed such a taste for MGD!
Tangent Alert! Towards the end of this tirade I started enjoying the fact that I was in MGD-land. So... it sorta kinda went the way it did... so what.
And now, returning to our story...
I don't believe in writing a major-chunk of code and then dumping it in to see if it works... during production time... only to find out that it doesn't. Production doesn't have the time to wait while I shake out "just a few more bugs". Sure, I could just re-install the backup... but why go through that at all.
My main process has about 5000 lines of code. The process has been around awhile. I've been slowly going through the entire process and "breaking it, just so I can fix it!"
All "serious" process developers have this thing where they don't think there is a piece of code written by someone else that can't be improved... by guess who? I'm a "serious" process developer. I go looking for things that ain't broke, give them the once over and then I break them. Quite contrary to the "If it ain't broke, don't fix it" philosophy... do ya' think?
When I say I "break-it" what I really mean is that I replace the code. However, as I said, I don't write a major-chunk of code and then dumping it in to see if it works.
I write "shadow-code". This is code that runs along side of the existing code. The existing code is still controlling the process. The shadow code runs along side, using all of the actual Inputs, Outputs and Control Relays as conditionals in the shadow-code. The result is that the shadow-code is running in a real-time, real-world simulator.
The shadow-code that would normally drive a real Output actually drives a "Proxy-Bit". The "Proxy-Bit" acts as an Output just as the shadow-code determines.
In this way I can add many lines of code over several days without affecting the process. At the same time I add my "Bug-Traps". There are certainly times when the existing code operates differently than the shadow-code... those differences are the reasons why I'm rewriting the process... the reason why I'm "breaking it".
As time goes on, I watch the code, I watch the traps and I watch the clock... it's almost time for another MGD!
Eventually, I become satisfied that the shadow-code is behaving as I expect.
Then I go to every real Output line and insert a "Code-Diverter-Bit" (--| / |--) as the last element in the rung to the Output. I then insert a branch below the existing code. That branch consists of a Proxy-Bit followed by another copy of the "Code-Diverter-Bit" (--| |--) in parallel with the entire existing code and the --|/|-- Code Diverter Bit. Like so...
Code
Diverter
Bit
---| EXISTING CODE |-----|/|---+----( OUTPUT )
|
Code |
Proxy Diverter |
Bit Bit |
---| |-------------------| |---+
I use the same "Code-Diverter-Bits" in each Output involved in the current "break-it / fix-it".
I have the luxury of being able to bring down one of my HMI's and modify its display while the system is running. I build in the capability for the "Code-Diverter-Bit" to be turned ON and OFF.
I drink my 15th cup of black coffee (Navy-Style) and finish the last smoke in my third pack.
When I finally get the hair.... I turn the "Code-Diverter-Bit" ON. Now the Proxy-Bit, from the shadow-code, is controlling the real Output. I watch the process... I ask the operators to test the extrema, the worst-case scenarios... Now I start sweating bullets. However, I feel some relief knowing that the bullets are small, .22's, maybe, maybe smaller. I know I can bail out at the push of a button. I'm not worried about a major screw-up. Both the bug-traps and the operation of the shadow-code, while in shadow-mode, have indicated that the shadow-code is fundamentally sound.
I write-up and post a
"Technical-Flash" to tell the current shift operators, and the on-coming shift operators, what I have done, and what to do if the new code presents any problems... "Push Button-X".
This "routine" has been working for me for 8-years. In all that time, I've NEVER held up Production with a program-modification issue. Certainly there have been process-program issues... but, I'm pleased as Punch to say that those were caused by the old existing code... not my "break-it / fix-it" code.
Yeah... I'm "serious" about what I do... and, believe it or not, I'm one of the "good-guys".
Knowing full well that my primary job is to increase company profits, I provide first for the Production-Folk, so that they can do their jobs as productively as possible, then I provide for the Maintenance-Folk so that their job of restoring the system to running condition, when necessary, is as easy as can be allowed (keeping safety in mind), and then last, I provide for me... the programmer. "I work harder so you don't have to!"
Did I tell you that I'm a pro-worker kinda guy?
(127)