altquark
Legendary Poster
[ QUOTE ]
Hmm. I seemed to have stirred up an interesting divergency of opinion here.
Thanks all for your contributions. Thanks Mr. Steele.
[/ QUOTE ]
Its Mr Steel, CNC God and Keeper of the dark secrets of CNC to you Mr Tirado !
Actually, I believe VERY strongly in documentation, documentation and documentation. I'm glad a couple of CNC types have come to this one lowly CNC's defense - far too often, the CNC is blamed for any downtime in the system - never mind it was the network switches that had a BIOS updated, or someone screwed up the Active Directory trust relationship, or some developer testing a data dictionary change in DV (!). I'll take the blame, and I'll fix the issue - thats what I get paid for. Then, after everything is working, recovered and back to normal, I'll document the exact reason the issue appeared in the first place...and, if the developer is very mouthy, I'll throw them under the bus...
Its not an issue of lack of trust people - its an issue of who should realistically "guard the chicken coop" - and whether a developer that has been working 14 hours to fix an issue he/she might have introduced into the last package has the right frame of mind to go ahead and then push that change into production.
The developers at the customer I currently work at have the ability to promote from DV to PY. They are then supposed to test (unit testing) before promoting to QA (a pathcode before Production - see my whitepaper on QA pathcodes on my website). The number of times I've seen code issues "appear" in QA, and then discovering the same issue appears in PY is insane. People often fail to test correctly, its human nature.
In fact, I saw an issue just last Thursday where a code promotion from DV to PY "broke" a MAJOR object, and in the middle of troubleshooting, I witnessed the project move from PY to QA by a developer "trying to also fix the issue" !!! Luckily he didn't have access to promote to PD...
Hmm. I seemed to have stirred up an interesting divergency of opinion here.
Thanks all for your contributions. Thanks Mr. Steele.
[/ QUOTE ]
Its Mr Steel, CNC God and Keeper of the dark secrets of CNC to you Mr Tirado !
Actually, I believe VERY strongly in documentation, documentation and documentation. I'm glad a couple of CNC types have come to this one lowly CNC's defense - far too often, the CNC is blamed for any downtime in the system - never mind it was the network switches that had a BIOS updated, or someone screwed up the Active Directory trust relationship, or some developer testing a data dictionary change in DV (!). I'll take the blame, and I'll fix the issue - thats what I get paid for. Then, after everything is working, recovered and back to normal, I'll document the exact reason the issue appeared in the first place...and, if the developer is very mouthy, I'll throw them under the bus...
Its not an issue of lack of trust people - its an issue of who should realistically "guard the chicken coop" - and whether a developer that has been working 14 hours to fix an issue he/she might have introduced into the last package has the right frame of mind to go ahead and then push that change into production.
The developers at the customer I currently work at have the ability to promote from DV to PY. They are then supposed to test (unit testing) before promoting to QA (a pathcode before Production - see my whitepaper on QA pathcodes on my website). The number of times I've seen code issues "appear" in QA, and then discovering the same issue appears in PY is insane. People often fail to test correctly, its human nature.
In fact, I saw an issue just last Thursday where a code promotion from DV to PY "broke" a MAJOR object, and in the middle of troubleshooting, I witnessed the project move from PY to QA by a developer "trying to also fix the issue" !!! Luckily he didn't have access to promote to PD...
