It's ok
-
So my boss was on vacation last week while our team was supposed to be preparing for a release at the end of this week. So was the guy who recently migrated all our source code to maven.
The four guys in charge of deployments to test and qa didn't do the build because some script didn't work. Why? Because we moved to maven and some of the paths changed. Unfortunately, these four Linux guys couldn't figure out how to edit a shell script file and change a few paths, so rather than ask for help from anyone with half a brain, they decided to just shelve it until the maven-guy returned this week.
Unfortunately, a) they are the only ones with permission to deploy to those servers, and b) this left us with not enough time to get the test and qa environments up and running to do testing, so the release got cancelled. My boss decided that cancelling a publicly visible release - with features specifically requested by our customers - is ok; don't worry about it.
Maybe it's the get-it-done-now mentality that's been drilled into me over 20 years on Wall Street, but this seems to be a little lackadaisical, or should I just enjoy the mellow?
-
@snoofle said:
Maybe it's the get-it-done-now mentality that's been drilled into me over 20 years on Wall Street, but this seems to be a little lackadaisical, or should I just enjoy the mellow?
Sometimes, the delayed approach is preferable than the pressured release, given that the latter brings increased risk.
Nowadays I'm more concerned with taking time and effort to get it right than rush it out and await the expected firefighting.
TRWTF is the Linux guys, and their mentality.
-
I can understand their reluctance to modify the scripts if it was more out of responsibility than actual lacking the required skill. I mean, if they misinterpret something in the script and release something that they "fixed" wrongly, then it's their problem. So they would logically leave it for a time when the person responsible for the script is back.
It's a sign of the times that people are sometimes afraid of overstepping their boundaries in-case something goes wrong and untold blame be heaped upon them (with the threat of the odd lawsuit too). Of course, that's just assuming that was their reason. which does seem the most likely, but not the only reason.
-
I would say it's pretty stupid. I understand your boss not wanting to try to hurry a release out, but someone should be yelled at for that.
-
@ASheridan: I misspoke; these Linux guys are not SAs; they're developers who work on Linux, and are responsible for a team-script that any one of us could be modifying. In this case, they just didn't care.
-
@snoofle said:
@ASheridan: I misspoke; these Linux guys are not SAs; they're developers who work on Linux, and are responsible for a team-script that any one of us could be modifying. In this case, they just didn't care.
So they caused the cancellation of a public facing deploy due to not doing their job, how are they still employed? I guess if it was the first time something like this happened I could understand catching shit but not a pinkslip, but if it was a just don't care thing then this can't be the first time.
-
General agreement with previous posts...
a) If it was *not* their responsibility, they did the right thing by not changing it. The fault liew with whoever is higher in the food chain for not making sure appropriate resources were availablr.
b) If it was their responsibility, then they are at fault, consequences (up to and possibly including termination) should apply.
