I started out with no experience working for a company that provided services for telephony. Our company bought out a telephony billing software company (we we

I started out with no experience working for a company that provided services for telephony. Our company bought out a telephony billing software company (we were leasing that previously). The deal included the guy who wrote the first release and subsequent, by himself, for years. This matters as it explains the mindset - there was low level of trust between us. So that guy who wrote the software didn't want us messing with his servers/workstations. His solution? To remove the default route. As we were located in different cities, it meant we could only access his systems when he would add routes, which he would remove afterward. My company needed access to a server one day, and they asked if I could remotely get that going. Since we paid the bills, we owned the internet router, and I realized I could hop from that router to his servers and add the default route at will. This worked great and everyone was happy (or didn't know we were doing it), except for me. I was determined to automate that. So I wrote up a script that would log in to the router, then the server, then add the route, and logoff. However what I didn't understand was that without wait states between commands it was possible under the right circumstances to overflow a router. This was exactly what happened while I was testing my script... A bunch of garbage flashed across the screen, my telnet session disconnected, and suddenly I could no longer ping their router. Now we had to tell that guy what happened, so he could meet the phone company engineer on site to reprogram the router. Just because something works a few times doesn't mean it's good to go...