Thread regarding SAS Institute layoffs

“I didn't even know there was an option not to have the certificates (letters) framed.”

None of my anniversary letters were framed, and I never even received my 30th anniversary letter because my manager at the time was a bo-b who had no concept of appreciation for the contributions of his direct reports. I did ask him about it, more than once. He did nothing. Whatever part of the human brain it is that enables empathy…he didn’t have that. But he did have an extra helping of the “fault-finding gland.”

Ultimately, of course, the letters are rather trivial (that’s why I didn’t care about framing), but I would have liked to get that one. Or any gesture of gratitude from my manager. Absolutely nothing. When, a few years before my retirement, he announced he was leaving SAS, I think I did a pretty good job of repressing my “YIPPEE” reaction. 😉

I didn't even know there was an option not to have the certificates (letters) framed. I wasn't asked and I didn't even know I was getting them until I was given them. It was a waste of company's money but it kept the Art Department busy.

@2dqt+1pT2aT9t

I declined the option of having my signed certificates framed because I knew that they would end up just as you described, and I am always trying to do my part to reduce company costs. I still have them in my folder of important papers and enjoy knowing that I still have them.

"SAS Art Department gave me 3 framed letter souvenirs...one for my 10th anniversary, one for 25th anniversary, and one for (non-forced) retirement. I have no idea what to do with these 3 huge frames now"

This is what I did with mine. Enjoyed them on the wall for about a year. Then realized that they represented the past. Besides myself who really cares about what I did in the past? Few if any. So I removed the certificates and put them to one more useful but final purpose: they got used to start a fire in the firepit. The nice frames got donated to the local thrift shop.

The best memories of SAS are kept inside my head forever and have nothing to do with that "art".

I'm at the phase of my life of getting rid of useless "stuff" that will only be a burden on my heirs. Sadly, JG and JS might be in the same mode.

@1qti+1pT2aT9t

Remove the certificates, insert some art, hang them on the wall!

@2itv+1pT2aT9t

That ship likely sailed before you were born!

Simplify all the things !

"Its the Art Department now, which is safe."

LOL... SAS Art Department gave me 3 framed letter souvenirs...one for my 10th anniversary, one for 25th anniversary, and one for (non-forced) retirement. I have no idea what to do with these 3 huge frames now....can't bear to throw them away so they are in the attic for now.

Its the Art Department now, which is safe.

SAS always focused on scalability over usability. That’s why we lost market share to Qlik, Tableau, and PowerBI.

SAS has talented UX designers, but they aren’t always listened to. When the ship date comes, products usually ship. They aren't delayed to test for usability.

As others have noted, UI developers weren’t always given the best tools. We clung to Flash long after we should have switched to HTML5. Then we chose Dojo; then SAP’s toolkit. These may all have been honest mistakes, but they're consistent with a low priority on usability.

For most of SAS’ history, focusing on scalability over usability was a sound business decision. Large customers paid well for products that could quickly handle large data sets.

Then open source began offering similar features and performance. Now much of the market for scalable analytics has gone there.

The market for usable analytics has largely gone to Tableau and PowerBI. Both offer free versions. It would take not only usability, but profound innovation to win that market back.

Industry solutions might be a better direction now. To succeed, usability would need to be a high priority.

SAS got swept up in all the "big data" hype in the late 2000's, and focused far too much effort on scalability and not nearly enough on usability.

If they'd really understood what their customers were looking for, they would have focused much more on industry solutions.

@pnl+1pT2aT9t

Broadcom has done many acquisitions. They probably have quantitative analysts on staff who can model a $3B declining revenue stream and say what it's worth.

So Broadcom may never have looked at the books. They may have said, we're interested at a price in this range. And that may have ended the discussion right there.

Compatibility between Viya / SAS systems - actions and procedures. Why it was thrown out the window from the start is beyond me.

I was there "at the time".
The moment that it became clear that there was no easy path forward for V9 customers to migrate to Viya was the moment it became clear that SAS would likely eventually die.

Most were too dazzled by the sizzle of Viya to recognize, much less admit, that it really was not steak.

And here we are with few good options that rise to the level resulting in a sale for a price the founders will accept.

I'm convinced that Broadcom walked away after perusing the books. Change my mind.

Anything else?

Development language(s) choice is important, yet far from telling the whole story.

PL/1->C + MVA were critical to SAS growing out of its mainframe and mini-computer roots.

By the early 2000s, Java was necessary for Web, midtier and application infrastructure. A few folks got over -caffeinated and decided it could possibly be used for everything. They were wrong for a multitude of performance and architectural reasons!

TK was necessary because by the late 90s SAS was still profiting from and very focused on hosting the core product on multiple OS platforms/machine architectures. C++ was not yet mature enough as either a development language/set of libraries, nor able to support everything we needed with regard to multi -threading on all target hosts. TK filled a certain gap but then gained more ground than it probably should have because we didn't begin a transition to C++ by 2005 when that would've been possible. By then SAS should've started realizing their new reality would be fewer host platforms. Some did, yet too much emphasis was still placed on porting and supporting hosts that had no real profitability future.

TKTS was a complete cluster fu-k. Perhaps someone with direct experience can provide even more details why, but suffice it to say that very poor scoping, ineffective leadership, and a lack of deep database internals expertise ranked at the top of the list of why it failed. Apparently JG declare that he was actually happy TKTS failed, because he never wanted to be in the database business to begin with.

The Metadata server became the locus of Version 9 Enterprise enterprise products and the "glue" between our solutions/applications -- even so several of the product product groups managed to duplicate some of the effort that should have been centralized in a better Metadata server implementation. From its beginnings, there were a variety of architectural limitations baked in to the SAS Metadata server, owing to similar reasons stated for TKTS, only saved by the fact the Metadata server was more limited in scope, and had a small team of hard-core developers for most if its history.

HPA, In-DB, etc. were "stopgap" architectural extensions in an attempt to remain relevant on new platforms like high-performance storage appliances/data database hardware. This is directly related to JG's historical, thinking about the 2 to 3 time horizon for new tech. He was apparently more interested in preserving our analytics heritage than he was building out a massive architecture/framework that would've allowed us to capture the future more optimally. Version 6 (initial MVA) head already been a massive CapEx expenditure that introduced very thorny compatibility issues with prior non-MVA versions of SAS. Everything that followed, including TK was much more incremental and could piggyback off and extend the existing internal build/testing people and infrastructure (which was probably half the cost of everything we did in R&D).

SAS should've gotten into GoLang sooner WRT micros services. Most of the new analytics and systems level code after 2005 should have been written in C++.
Development standards that included. All of R&D, and all product groups should have been much more rigidly, enforced to reduce/eliminate so much duplication of effort.

As computer engines, LASR and ultimately CAS were in-memory data, multi-user/multi-threaded evolutions of SAS' heritage. Given the state of things at the time they were developed, they were decent ideas, yet could've benefited from more thoughtful architecture that considered cloud data integration, the growth of containers, etc. earlier on.

Virtually all of the current problems, we see at SAS stem from overall suboptimal management, lack of architectural vision, and diminished practical research/ongoing learning excellence within the rank and file.

JG and SAS executives had too much patience for the status quo, which included chasing niche markets (because that's what many product-mevel Diirectors understood) when SAS would've been much better servered long-term developing a cogent early architectural strategy for cloud and edge computing.

Gotta give you credit, you sure are good at conjuring up new threads to stir up conversation.