“Going to” means you know. ‘Should’ means you know nothing.
“Those servers should come up cleanly after a reboot.”
“That storage array upgrade should not cause an outage.”
“The customer should be fine with this.”
Right.
If you can’t say “going to” then you need to do more work.
Update: if you think I’m wrong don’t take it personally, join the comments where the beatdown is already happening. Please, no nails in the 2x4s, though. 🙂
‘should probably’ is even better.
I always go with “should” because I’m a superstitious bastage and I don’t want to tempt the wrath of the network gods.
Wrong.
You have been in the business long enough to know better.
The minute you use “going to” instead of “should” Murphy is going to hit you in the head with a twenty pound brick of his law and show you just how confident you “should” be.
“Those servers are going to come up clean after a reboot.”
… followed shortly by …
“Well I didn’t see that hard drive failure coming.”
NEVER TEMPT FATE! 😉
I’m with roxet. I know too much about computers to put any sort of faith in them
“Those servers should come up cleanly after a reboot.”
Yeah, they should. Always. However that’s not always the case, and while I’ve never questioned your logic and reasoning before, I’m suddenly very specious of everything you now say. Way off the mark on this one.
“That storage array upgrade should not cause an outage.”
Yeah, it shouldn’t. However it does. That’s what “should” is all about.
“The customer should be fine with this.”
No, they shouldn’t. They be informed. Every step of the way.
Wow. Poor article, Bob
Geez, you guys. These are machines, not gods. Should I be slaughtering a goat and dancing a special dance before each maintenance window? Or should I be doing quality, relevant testing so that I can turn the speculative “should” into “going to?”
Aaron, are we not preparing for hard disk failures by using RAID, or redundant servers?
Bob E, if a storage array is likely to cause a problem then don’t say “it should work” and shrug when it doesn’t. If you’re that uncertain use terms like “it’s going to cause an outage” and plan appropriately.
It sounds like we’re all wrong, and that in the end we should choose a wording that conveys that it’s going to fail horribly each and every time.
Personally, my goal is to remove the uncertainty you guys are talking about, and deliver a solid, understandable, predictable product to my customers.
The hard disk failure was one example.
I once had a datacenter get hit with a direct strike of lightning during a migration, no one had planned for that one! The servers were all fine but the PDU had literally melted.
Just saying, the sysadmin who speaks in absolutes hasn’t been around very long.
Aaron, funny thing is I agree. I just wish sysadmins would speak in fewer generalities, and quit treating their profession like it’s mystical.
Perhaps my original post should have been more clear about that. 🙂
And that lighting strike sucks. I’ve had similar experiences, where a big storage array upgrade had the power go out half way through. Freak incidents are very hard to handle, and the ROI of planning for them is pretty low.
Maybe I should rephrase this.
You can be as confident as you want, but it’s the old axiom, hope for the best, prepare for the worst.
Server will come up fine after a reboot, but if it doesn’t we can expect that it will be fixed within our SLA. Unless some major catastrophe, which we then would expect patience in missing our SLA.
Still, its niggling semantics.
Absolutely. It’s just the clowns that don’t prepare for the worst and use “it should have worked” as an excuse that drive me nuts.
Which is actually what caused this post.
Anyhow, I appreciate all the comments guys. I’ll write more about this tomorrow, and please keep calling me on the BS when it happens. 🙂
I’m really somewhere between the two. I’m one half goat slaughtering mystic and one half meticulous tester. It’s like the project I’m working on now. We are bringing in a new internet connection and I need to cut over from our 2 DS3s to this 200 MB Ethernet pipe. I spent most of the day yesterday and today testing and planning the cutover. But no matter how much testing I do or how confident I feel, there is no way I am going to do the cut on Friday. =)
Bob –
Great post, great discussion. 🙂
I get to approve changes/patches/upgrades that if they fail, a hundred thousand customers will know that we have failed, and/or a multi-million dollar project will turn into an HGE (Headline Generating Event) or RGE (Resume Generating Event).
I listen very carefully for ‘should’, ‘supposed to’, ‘will’ and other similar words when evaluating the requests.
–Mike
(okay, so I didn’t get to leave the office like I was planning, after that last comment of mine. So I’ll continue the discussion.)
Mike, I don’t envy you at all. Well, to be honest I do envy you a little, because that sort of exposure often means that you get funding and time to do proper sorts of testing.
But it also means change is hard, even when everybody knows it’s for the better.
roXet, I often will plan changes considering the possibilities if things go wrong. For some of my customers a Friday evening change is good because if it goes bad I’ll have all weekend to fix it. That is, if I want to spend my weekend fixing it (which is where I think you were going). 🙂
I’m with Bob on this one, however, what I find is that you certain something is going to happen only for one little thing to get in the way and make you look like an idiot in front of the customer. You can fix it in seconds, but you still look like an idiot.
Maybe you either become better at your job or settle as a ‘should’ sayer?
All things being equal, I agree with frowning on “should”. However, I don’t believe all things are equal, especially when people are involved. When I do an upgrade, I do not have all of the equipment to do full testing on everything I do. I work for a non profit and I can’t replicate my environment. I can do VM based testing, but that doesn’t mean that an OS upgrade won’t puke because driver A doesn’t work with hardware A. I can do as much up front testing and research before hand, but I can’t control a crap driver from a brain dead hardware manufacturer like broadcom.
All though, while the upgrade “should work”, eventually it “has to work”!
I work for a large company and the last thing you want to do as a “good system admin” is say “its going to work this way” since Murphy wins every single battle. That being said I am a majorly annoying tester pushing for rollback plans and what kind of testing has taken place and how many times have you done this. ITIL for the win. More often than not Systems Administrators have to be the best at delivery every single time since the things that we do can be the cause of a business ending event. Last thing I want is to give the wrong impression to an end client on what the ultimate impact could possibly be.
We have had significant discussions on proper words to use and imply in communications with end clients and Change Control Boards. The key is to state what the goal is in objective clear terms in Change Memos and when talking to people to not over promise perfection.
Saying “going to” implies that nothing will ever go wrong. That only works in a perfect world and if it doesn’t go right, your reputation is shot. Period. That harms you as a System Admin more than anything else you do. Your reputation as someone that the business can count on to do what is necessary to bring up the servers and services that the business depends on to make money is everything. It is at the end of the day what they pay you for. Now good system admins will test things out, make sure plans are available for back out, minimize the outage windows and generally be as Scout prepared as possible.
As part of that “Should” does not generally imply the right thing though I don’t know a better term. I do agree with you on this in principle Bob.
@Craig
Maybe you either become better at your job or settle as a ’should’ sayer?
It’s like this. I say “should” for the same reason that the multi-million dollar datacenter I’m in says “99.9999%” instead of “100%”. Any system of decent complexity has enough moving parts to be able to avoid a 100% chance of, well, anything. Saying “will” is only betting against those one-in-a-million chances that seem to crop up every other week or so in this field.
As long as we’re fishing out the war stories… There’s always the year that mass user deactivation here blew up when the desktop it was running from started on fire…
jon