Do they still have jobs or is it one of those '30 days to find a new position' deals?
42 replies (most recent on top)
"...failed to produce Viya in a reasonable timeframe. And when it finally shipped, it wasn't what the market wanted."
Whatyousay? I think you're forgetting the first year or so of Viya history, when it was just "Project X". And it didn't start under Oliver. Viya development started under Armistead. I really liked Armistead (for the record I also liked Oliver) because he wasn't afraid to change things, and there were (and are now) a lot of people at SAS who found that really threatening. A lot of the original design priorities (we'll say) of Project X were later completely abandoned. No backward compatibility for microservice APIs means no "modular" (whatever that means for something like SAS) architecture, no updating one "thing" without affecting other "things", and a CI / CD pipeline that went from an arbitrary number of ship events per year to one every two months (what an improvement!). So the idea of Viya was one thing, and it proved harder to implement in the time allotted, and parts of it were abandoned because it proved harder to implement, and because SAS development just wasn't up to the challenge, even with all those PhDs.
"The only moat SAS ever has is what's been built by the Advanced Analytics (AA) division: SAS/STAT, SAS/ETS... For the quality minded firms, you simply can't find replacements for them."
This must have been before the time of that DB with the 3-letter name. The other big German.
The BG was a good statistician, sufficient to code GLIMMIX. But you don't hire a carpenter to build a skyscraper.
His skills were not sufficient to build Viya. He never studied how to architect large software systems, how to manage large teams of software engineers, or how to learn and verify what customers want.
People study for 4, 6, and 8 years to learn these skills. He tried to pick them up on the fly.
Failing to acquire the needed skills, he alienated many of his staff, more or less ignored his customers, and failed to produce Viya in a reasonable timeframe. And when it finally shipped, it wasn't what the market wanted.
If you want to call him a good coder, I’ll agree. Not a good software developer.
He was not unusual at SAS. But other analytical folks with advanced degrees were more humble, recognizing they were working in a field they had never studied. He never learned the skills to scale up.
"But open source changed all that, and accelerated innovation dramatically through a vast global community. The fact that SAS couldn't or wouldn't leverage that vast body of "free" IP, is a major reason for it's decline in competitiveness."
But what about that SAP OpenUI5. SAS embraced that...
""Ph.D. level analytic developers can easily learn to be great software developers..."
I can think of one Big German who never learned that."
GLIMMIX remains the most popular SAS/STAT procedure among customers. And it's extremely complex and powerful. Say what you want about him, but he produced some incredible work.
"Ph.D. level analytic developers can easily learn to be great software developers..."
I can think of one Big German who never learned that.
Ex-SAS employee working as industry practitioner now. The only moat SAS ever has is what's been built by the Advanced Analytics (AA) division: SAS/STAT, SAS/ETS... For the quality minded firms, you simply can't find replacements for them. I challenge you to find a usable open source design of experiments (DOE) library, which by the way is fashionable again thanks to the hyper-parameter tuning in AI.
All the rest, the data format, the vertical solutions, the services, the model-as-products, you can find better and cheaper offerings. Even some of the AA product such as SAS/OR is irrelevant now due to much better commercial (gurobi) and open source (e.g. Google) offerings.
Apparently this appreciation of analytics is beyond many software engineer's depth. If they happen to sit at the top, they fill up the moat with bland software engineering practices: agile, unit testing, XasS, whatever that's fashionable... Ph.D. level analytic developers can easily learn to be great software developers but not the only way around.
@6znh+1uHlUdcW
What you describe sounds a bit like the SAS attitude of "if it wasn't written by us, it's not good enough" or something similar. In today's world, that seems like an arrogant and insular attitude that in hindsight has limited SAS's ability to scale and remain competitive.
The competition who wrote 200-line "improvements" to open source were being smart and not reinventing the wheel. I'm sure it was different back in the day when you helped to write SAS/STAT, one of SAS's greatest achievements, because there was nothing that had come before it that was reusable.
But open source changed all that, and accelerated innovation dramatically through a vast global community. The fact that SAS couldn't or wouldn't leverage that vast body of "free" IP, is a major reason for it's decline in competitiveness.
I was a SAS/STAT developer. When we attended the Joint Statistical Meetings (the largest gathering of statisticians in North America) each year. We would interview potential job candidates. Since we all were there and did not have to fly each candidate in, our criteria for scheduling an interview were lower than they would otherwise be. I would always ask the question: “What is the longest program you ever wrote?” Before I divulge the answer I most often heard, let me state that the statistical SAS procedures my colleagues and I developed were tens of thousands of lines, often over 100,000 lines. The answer I got to that question was amazingly consistent. It still amazes me to this day. I often heard: “I wrote a 200-line C program to speed up a function in R.” While I appreciated the honesty, that answer never resulted in a job interview back in Cary. More importantly, it underscored to me (what I already knew) that we have PhD developers writing code that is independently validated by highly-skilled professional PhD and Masters level testers. In contrast, our competition had graduate students writing 200-line “improvements” to open source. I knew whose code I would trust. Unfortunately, the market did not agree.
Open source like R made SAS statistical products and testing irrelevant business wise. Not that having 884 PHDs that can't code ever made sense for a software company.
Consider yourself lucky.
"Did you READ that article???"
Why the yelling? Better calm down before you have a heart attack
Sounds like someone needs to go back to school
To get an advanced degree???
This situation is no different from prevailing industry standards, such as those established by Microsoft:
Did you READ that article???
Too many acronyms. Please translate.
"A result can be incorrect without generating a failure.“
Sounds like someone needs to go back to school to figure out how to write self-validating tests correctly.
"FYI, just heard from HW that TC is moving forward with the GMM in Q4 :-("
OMG!
"A result can be incorrect without generating a failure. Does "precludes validation" mean that numbers are checked, or not checked??"
I doubt the numbers are really checked. If the procedures don't fail they move on.
The true testers will be SAS customers. When our software gives the wrong numbers back and SAS does not know and customers find them and report them then SAS's reputation will take a huge nosedive. Things like this happen when you cut corners.
So much for high quality posture. SAS talks the talk but doesn't walk the walk.
@4jji+1uHlUdcW "Yes, those same tests are now containerized and self-validating so that they automatically detect failures in the CI/CD pipeline. Nothing in this scenario precludes validation of the output of one PROC versus another."
A result can be incorrect without generating a failure. Does "precludes validation" mean that numbers are checked, or not checked??
Here is an example using SAS/STAT. The accuracy of those procedures was verified by professional testers who wrote SAS/IML code so that the results could be independently checked. Does "containerized and automated" provide the same independent checks?‘’
Yes, those same tests are now containerized and self-validating so that they automatically detect failures in the CI/CD pipeline. Nothing in this scenario precludes validation of the output of one PROC versus another.
This situation is no different from prevailing industry standards, such as those established by Microsoft:
Instead of directly (ie. in-house) employing quality assurance teams who were dedicated to testing software builds, Microsoft switched to a model based on sprint-based development work and rolling releases with feedback from telemetry data … [https://ghuntley.com/fracture/]
@3sbz+1uHlUdcW "Tests are all containerized and automated in the CI/CD pipeline. What’s a testing manager to do? Babysit and manage a bunch of test containers?"
Here is an example using SAS/STAT. The accuracy of those procedures was verified by professional testers who wrote SAS/IML code so that the results could be independently checked. Does "containerized and automated" provide the same independent checks? (That is a real question.)
"I hope that we are not moving away from that kind of testing."
Tests are all containerized and automated in the CI/CD pipeline.
What’s a testing manager to do? Babysit and manage a bunch of test containers?
“FYI, just heard from HW that TC is moving forward with the GMM in Q4 :-(”
WWTMA
(Whoa—way too many acronyms)
FYI, just heard from HW that TC is moving forward with the GMM in Q4 :-(
@2qro+1uHlUdcW
Bingo! Bingo! Bingo!
"I hope that we are not moving away from that kind of testing."
Of course we are.
Schabenberger started this when he dismantled QUEST and moved the testing teams back into development. I'm sure the move was something development managers were all in on, because their control of the narrative allows them to hide their problems and eliminate the defect burn-down at the end of every release cycle and consequently make themselves look better. I can't even remember how many of the defects that I reported were dispositioned "nobug", "nofix", or deferred to the next release during the burndown because there weren't enough developer-hours to fix all the problems we were reporting. Then they were just, quietly, never fixed. Schabenberger even had to implement the "you can only defer one release" rule to keep development managers from forever deferring their technical debt to the next release. What difference did that make? Even he had to eventually accept the reality of the situation.
Then after Schabenberger left SAS someone, I don't know who, convinced Harris that unit testing can more or less completely replace QA. The slide had started before that, when we transitioned to Viya in 2016 or so, but as a complement to QA. Unit tests are the "due diligence" of the quality cycle, not the "preventive action", or even the "action to prevent recurrence". That's what QA is for. But QA has to have independence from production or their activity is completely captured. Whatever prompted this decision more or less guarantees that the inherent conflict of interest will ensure the quality of SAS software only continues to decline.
Senior management at SAS has always believed that whatever they say is true is true. It's the SAS version of Jobs' Reality Distortion Field. But this has never been the case. Senior management that survives at SAS just learns to carefully manage the message up, and create networks of alliances that ensure that an attack on one is an attack on all. The entire thing has always stunk to high heaven. For the most part, those are the development managers who survived the last five years or so, because managing the message is their work, not delivering quality software.
The irony is that there are a few commenters here who consistently blame individual contributors at SAS for their apathy, willingness to "ride it out", etc. but that's learned behavior. It all starts at the top. Not even Schabenberger, with his 30 minute lunches and all the scurrying back and forth from one meeting to another with his assistant always a few footsteps behind could set the tone from the top. Senior management just had to wait him out , and they did. They'll wait out Harris too, and whoever Goodnight anoints after him, because they're really the ones in charge at SAS. There's been some what I would refer to as "light housekeeping", but not enough to really make a difference. Why should an individual contributor be held to a higher standard than their apathetic and ineffective boss?
When talking to customers and explaining why paying for SAS is better than using free open-source code, one of my points is that SAS has dedicated teams of full-time professional testers writing independent programs to check the accuracy of our analytics code. I hope that we are not moving away from that kind of testing.
"R&D makes a big push for quality and testing, but doesn't actually want to stand behind it with staffing the necessary people to achieve quality deliverables."
Sad! Oxymoron! But that is very SAS !
“why are they taking a jackhammer to this organization?”
Same reason that dude jackhammered the greenway?
Sad to hear, why are they taking a jackhammer to this organization?
I heard that the same thing happened to development managers.
"ARD (and wider Platform Engineering) are pushing to blur the lines between Devs and Testers (now known as SDETs) so they can circulate people around to whatever the new customer escalation or "all hands on deck" issue is. "
Firefighting -- a manager once referred to this practice as "Agile". I referred to it as "Chaos". They are now a Senior Director, in a 'special' job, for a 'special' person.
Positions weren't eliminated, but as someone else said they were offered other management positions in ARD or were told to be ICs.
Big push right now for "quality" (just see JPs weekly emails about it) and then OKRs for "code coverage" this year which I assume is just unit tests. Unit tests are useless when the code is garbage to begin with. ARD (and wider Platform Engineering) are pushing to blur the lines between Devs and Testers (now known as SDETs) so they can circulate people around to whatever the new customer escalation or "all hands on deck" issue is. R&D makes a big push for quality and testing, but doesn't actually want to stand behind it with staffing the necessary people to achieve quality deliverables.
Perhaps a customer-testing approach?
Televangelist
“Speculating... outsourcing to India and China and others for QA resources?”
We are happy in Beijing!
JP came from the world of web apps and could be an excellent software engineering manager. The position he's sitting in right now is beyond his depth. Only in SAS he can survive and thrive.
"@1osy+1uHlUdcW "...First step in eventually phasing out testers altogether."
Please elaborate. How will testing occur without testers??"
My impression is that JP thinks the combination of "unit tests", developers testing their own code, and some testing of code from other developers will be sufficient.
And don't forget that "Quality" is the highest priority!!
Speculating... outsourcing to India and China and others for QA resources?
@1osy+1uHlUdcW "...First step in eventually phasing out testers altogether."
Please elaborate. How will testing occur without testers??
"All testing manager positions or just a few. Who's the head of the Analytics division?"
All of them. But a couple got moved to manager of the new developer/testers groups. The others will become individual contributors.
Seems like you aren't allowed to name names on this site? Her initials are SH but rumor is that it's all driven by her boss, JP. First step in eventually phasing out testers altogether.
Well, I guess the first phase was laying off 44 testers last year.
Don't worry. Those testing managers with connections were parachuted into dev managers roles. Advanced Analytics, the soul of SAS, the money cow has been further reduced to oblivion by folks who don't know analytics.