|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Create a playlist of uplifting songs I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
Accounting for Typos When I watched Star Trek as a kid, I was amazed by the technology. Talking to the computer, the touch screens, the handheld communicators. We have most of those devices now, without the space travel. Hopefully that will start to change with all the effort being made by various organizations. One of the things that always bothered me was the chance for mistakes. A mis-spoken (or mis-heard) command to a computer that didn't verify things as a human might. The chance to hit the wrong part of the screen as the starship moved. It seemed as though soft buttons would have allow more mistakes than hard ones. Certainly humans make mistakes with physical switches, but I think I make more mistakes trying to hit a part of the screen in my Tesla than using one of the (few) buttons or wheels to change something. Interestingly enough, my 23 year old decided on a slightly older car because it had more physical buttons and few soft ones. We are human. Frail and faulty. We make mistakes. Some are small (I ran a SELECT query on the wrong database), some are bigger. A mistaken copy paste error sent US$36 million away. That is the type of mistake that could happen to any of us, though hopefully not at this scale of financial loss. This type of mistake is a main reason why I think DevOps and automated flows for development, testing, and even for production updates are a good idea. This doesn't prevent human error, but it does serve to limit it and reduce silly mistakes. Often these types of errors are caught when we force someone to work through a bit of a process. An easy and quick process, but still a process. In this case, you would hope that someone looking to make changes would write an update that can be tested in a second environment before applying to the production blockchain. Perhaps with some idempotent wrapper and a pre-check that verifies the target. That might seem like overkill, but it's the type of care that most of us take when we know we aren't going to be the one executing the code. If you submitted a script to a DevOps process, you'd want to be sure the process running your code made the proper decision of whether to run the code or stop because of some error. We won't prevent all errors, but a lot of automation and light DevOps process is designed to limit simple, silly human errors because we are tired, distracted, or otherwise unfocused. I am a proponent of having humans design systems and processes, but then letting the computer handle the drudgery of following the process over and over on a regular basis. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
