Yahoo's Engineers Move to Coding Without a Net
-
-
I'm not that sure about that first word. You sure you didn't miss an
r?
-
They use that, too. But a lot more than a dash.
-
Isn't that what Discourse is doing?
I thought Discourse did BSDD. I'm not sure what the BS stands for, but I think its bike shed...
-
How does this strategy compare to BSODDD?
-
Discouse is just JDD. Where the current focus is whatever idiotic idea sprung into Jeff's head in the previous 10 minutes while smoking Discocrack in the bikeshed.
-
This explains why I've gotten spam emails on a yahoo account that had never seen the light of day and had an account compromised despite having a password longer and more complex than what @Polygeekery thinks my list of graduate degrees is.
-
password longer and more complex than what @Polygeekery thinks my list of graduate degrees is.
You must be so smart, having all those degrees and such. Why, I bet no one else here has even one!
-
what @Polygeekery thinks my list of graduate degrees is.
0..3 letters or so, I'm guessing? You wanna rethink that?
-
0..3 letters or so, I'm guessing? You wanna rethink that?
At last count, @Polygeekery estimates that I hold 743 degrees.
-
At last count, @Polygeekery estimates that I hold 743 degrees.
I would probably have to read one of your SJW threads to know that, though.
-
-
I have a bit of sympathy for their developers, after working on some "firefighting only" projects where there was never enough time to implement any decent QA or automation, it's all too easy for management to paint you into that kind of corner. If I had time, I'd love to implement a proper automated regression test suite for each of the web apps I maintain - but management will always go for the quick patch then use the time for new features instead, or move on to the next project before the paint's dry on the last one...
I wonder if someone principled at Yahoo is actually implementing the moronic policy to the letter, to demonstrate just how stupid it is by seeing everything break daily until Meyer gets replaced and they can start trying to deliver a decent product again?
My mother still insists on using Yahoo Fail (yes, I've tried getting her onto a proper desktop client, a Gmail account, using her phone instead, etc - but still she pounds away at it, turning the air blue as it stalls, spews gibberish and malfunctions daily) - and it's all too obvious they have little or no QA of any kind going on - yet still they plug away, shoving in more brainless "features" nobody asked for, probably mainly aimed at shoving the ads a bit harder to squeeze another few pennies into Meyer's coffers.
Even in "beta" services, Google at least seem to do a bit of testing before deployment: their "untested experiments" are more robust than Yahoo's mature and simple products now! It's mad.
-
I have a bit of sympathy for their developers
Why the fuck someone would even think about blaming the developers for untested software? Management is responsible for business processes, and even if the entire team is incompetent the management would be responsible for fixing that.
-
@jas88 said:
I have a bit of sympathy for their developers
Why the fuck someone would even think about blaming the developers for untested software? Management is responsible for business processes, and even if the entire team is incompetent the management would be responsible for fixing that.
I mean, I feel sorry for the poor sods, having their work sabotaged like that. BTDT. I've worn a QA hat and built testing stuff, I've worn a dev hat and broken stuff - and I've been "IT guy" in a software startup where that meant dealing with everything from the phone company accidentally killing the PSTN line to ... doing the quarterly sales tax (VAT) returns, because that's done using software, which makes it "IT", right? They tried hiring someone who was laid off by a bank to offload some of my workload after trying to lay me off, because obviously she'd know about accounting software ... except she'd been a mortgage sales advisor. So that bit of work came back my way after someone got suspicious about the negative sales figures that quarter... These days, I just drop in once a week to put out their latest fire. They have a great idea for the newest project, though: to "avoid" bugs, they're getting it implemented multiple times in different languages. I can't wait to see how that one turns out, as long as I don't get caught in the blast...
If I worked there, I'd be furious about being associated with buggy untested crap. It's probably how it felt to be a sysadmin somewhere like Enron: you did your job perfectly well and had nothing at all to do with the insanity higher up - but still get left with a huge steaming turd on your CV.
I like to think there was a Dilbert-like scene, with the Pointy Headed Meyer announcing that from now on all QA would be outsourced to the users since they don't need paying, and Yahbert replying "so ... you want us to expose every bug to the public as soon as it's written, now, not bother with any testing in house? OK." In a perfect world, Meyer then gets extradited to Elbonia to work as L1 tech support for a mud vendor. She's underqualified, but could probably figure out which end of the shovel is which with fewer than three guesses.
(Yes, trying to develop, manage and support a bunch of web apps with shoestring testing and never enough time to do anything "properly" is stressful, but it's also an interesting challenge to deal with. The whole setup really was designed for a DWTF article, and I'll get round to writing it one day!)
-
I can't wait to see how that one turns out, as long as I
don't get caught in the blast...make TL3 so I can post all the gory details in the lounge.FTFTROU
-
Resurrecting the topic a bit as this landed somehow into my twatter timeline: http://readwrite.com/2016/01/22/staging-servers
"Staging servers must die, let's check in onto production daily, nothing unexpected could go wrong!"
What was called irresponsible coding in the old days, got the name of Continuous Delivery today. I think in 15-20 years I better open a pancake bar to keep my sanity. Fuck software.
-
Feature Toggles are a good plan, but the disturbing trend of skimping on QA because of them is idiocy. A disabled feature can still have a negative impact on the quality of the code: performance, security, maintainability.
I also am in favor of getting rid of staging servers in favor of an elongated red-blue deployment process, preferably with cloud-style server provisioning: spin up half your farm's worth of production servers, deploy to that, test internally, then swap out half your prod servers for the staging ones. Now if there's a problem you can swap back, and once you're confirmed stable, you just deploy to the inactive formerly-prod servers and swap them for the other half of the farm, spinning down those servers. It's literally impossible for staging to be out of sync with prod on an infrastructure level that way.
-
Ugh. I guess if you don't care about corrupting data or whatever this could work. But now you're in a maze of twisty feature flags, all alike.
-
But now you're in a maze of twisty feature flags, all alike.
Ye find yeself in yon dungeon. Ye see a SCROLL. Behind ye scroll is a FLASK. Obvious exits are NORTH, SOUTH and DENNIS.
-
Feature Toggles are a good plan, but the disturbing trend of skimping on QA because of them is idiocy.
+
ACTUAL
We just deployed a "feature" that will clear unread messages over a certain threshold.
We don't want that. We've disabled it. How do we restore the messages that were cleared.
You can't. There's no way to reverse it.
Later (theoretical, but plausible)
What the shit? We disabled that feature, but if you go look at messages through Unread, it still triggers the threshold.
Well, I guess we didn't put the toggle on the logic there. Oopsies.
If you don't have a staging server,
you, your data, your users.
-
Ye find yeself in yon dungeon. Ye see a SCROLL. Behind ye scroll is a FLASK. Obvious exits are NORTH, SOUTH and DENNIS.
> BUILD YE FLASK
I don't know how to BUILD YE FLASK!
(And you just sit there and imagine why on Earth you can't build the flask, since there's certainly no way the compiler's going to tell you.)
-
Duh, you can't BUILD it without holding it first!
> TAKE FLASK
Taken.
-
You were eaten by a grue.
-
it isn't dark, I can see - because I saw the room contents, so the grue wouldn't eat me.
I'd come up with dickweedery to go with
but illness is a thing.
-
>PICK NOSE
-
Quest For Glory
-
It seems to be working for Yahoo. (Most of) the QA team has taken other roles, the developers are directly responsible for the code they deliver, and the management is happy about it. I figure they wouldn't be if the result wasn't working for the customers.
What is your problem, then?
-
Yahoo mostly degraded to lolcats these days. Nobody will notice there's one less lolcat.
-
Try pulling that trick on a major carrier's billing system and your exploded ass is gonna be buried all over Arizona, that's what the problem is.
-
I take your comment as meaning "i love my silos". I've yet to be explained why my "exploded ass is gonna be buried", let alone how it'll get to Arizona in the first place...
What Yahoo seems to be doing is integrating the QA process - combining the developer and QA silos instead of throwing the product over the wall to the next department.
This change is consistent with modern development methodology. It usually follows naturally, since there's no (separate - they're ON the development team) QA team to blame, that the development team makes higher quality code as a result. It fits nicely with sentiments like "developers carry beepers" and "more value sooner" - other aspects of modern development technologies.
-
combining the developer and QA silos
Meaning either people who dont' know how to develop are developing or people who don't know how to test are testing. Unless you're going to say they're actually training developers on QA? Nobody seems to think QA is an important thing to learn, they just assume people can figure it out on their own without any sort of formal training. I've seen some terrible shit coming out of that attitude.
I like the idea of having a tester co-locate with the devs, but devs suck at testing their own shit.
-
User: Welcor
Posts: Not many
Summary: "Offshore is great. I am offshore" and also "Yahoo is great. Don't criticize them"Conclusion: Welcor is offshore codemonkey on contract to Yahoo. Survived last round of cutoffs. Has plenty of time to sockpuppet for the company-- at least for the next two weeks. That's when all the production-critical bugs hit, and he'll be swamped 24/7 fixing what should have been caught in QA.
-
devs suck at testing their own shit.
The mentality is that if I know this is a bug I will not commit it. Only a second set of eyes can catch my shit.
@Lorne_Kates said:
That's when all the production-critical bugs hit, and he'll be swamped 24/7 fixing what should have been caught in QA.
It makes sense to improve your job security.
-
if I know this is a bug I will not commit it. Only a second set of eyes can catch my shit.
QFT
-
-
devs suck at testing their own shit
Well, of course. The cases that the dev thought about, they handled. The cases they did not think about, well, they did not think about them, so they won't test them either.
And that applies even to people who are quite good at testing. I have a colleague who finds quite a few bugs and misfeatures. But his code is not particularly less buggy than anybody else'sā¦
-
Well, of course. The cases that the dev thought about, they handled. The cases they did not think about, well, they did not think about them, so they won't test them either.
This. Also for devs testing is an annoying tedious formality because they already did their tests during or immediately after implementing the function. So nothing will be gained by making the same people test the same thing AGAIN. They'll just test what they know to work.
-
So nothing will be gained by making the same people test the same thing AGAIN. They'll just test what they know to work.
The dev knows what code they are trying to test, so they'll run the application so as to invoke the code. While a tester knows which feature they are testing and they'll use the application in a way (they think) typical user would, which is a wholly different thing.
-
User: Lorne_Kates
Posts: who cares? If you're wrong here, none of your other posts matter.
Summary: "I can't read"Conclusion: Lorne_Kates draws conclusions from his ass.
-
User: Lorne_Kates
Posts: who cares? If you're wrong here, none of your other posts matter.
Summary: "I can't read"Conclusion: Lorne_Kates draws conclusions from his ass.
That's complete wrong. I PULL posts from my ass.
-
@Lorne_Kates said:
@welcor said:
User: Lorne_Kates
Posts: who cares? If you're wrong here, none of your other posts matter.
Summary: "I can't read"Conclusion: Lorne_Kates draws conclusions from his ass.
That's complete wrong. I PULL posts from my ass.
It's rather obvious too just look at the shit stained pattern ... draw conclusions leaves totally different marks ... like those on welcor's post.
-
The dev knows what code they are trying to test, so they'll run the application so as to invoke the code.
Not only that, but our deadlines never account for testing. I can't ever fix basic ui bugs before phb pushes for shipping it.
You know when you use a software with self evident bugs, for years, and you don't understand why they never fix it? My stuff is released like this.
