Thread regarding SAS Institute layoffs

Depends on the pairing…

How do you feel about "paired programming"?

Agile is for developers who have no clue what they are doing. Getting rid of the old folf is geting ruc of the people who have a clue...

The last paragraph in the OP was meant to be satirical ... the OP author has lots of experience with Agile -- which has morphed far from its roots as a set of succinct principles laid out by real engineers who understand true software craftspersonship.

The problem is is Agile, is turned into an entire industry of its own with multiple philosophical streams, that in some cases borderline on religion. There's a huge financial interest in keeping this industry alive and thriving.

Project management has existed for a long time and SAS as used at variously,. The complexities and pitfalls of building "correct" software have been understood since Fred Brooks wrote the edition of The Mythical Man Month, roughly 50 years ago.

In my observation Agile is often seen as a panacea, but if we can "just get it right" and do sprints and scrums on the right intervals then it will be effective. In reality, it has another administrative layer functioning as agile professionals, who think they have answers for real engineers, who understand how to design, build and validate Software.

It is also been pointed out that CI/CD is not necessarily the best model SAS considering the majority of the paying customers still run on premise. Some of those customers are chafing at being forced to deploy Viya 4 locally in containers. The trade-offs and conflicts of trying to streamline software delivery, and maintenance of course demand that all of this is standardized in containers.

There's no need to even address your git comment because of course it has become the standard way of doing source management, versioning, etc. That said, apparently, Google doesn't use it internally.

You are spot on and pointing out that there are many reasons why SAS is currently in the shape it's in. My generation build the core SAS products and saw the company grow from roughly $50M annually to well over $2B before any of the technologies, we are currently discussing became relevant.

It is indeed, unfortunate that the transition to the current way of successfully operating a software company was not done with greater care. The biggest dilemma I witnessed was a general complacency in many (certainly not all) longer-term R&D employees to take a leadership role in this transformation as well as corresponding conflicts with more senior developers and managers brought in from the outside who had experience with more modern techniques.

Then there was the ever present need to deliver new releases and maintenance of our existing software while attempting to also involve the build/test infrastructure. I witnessed one Director level manager, literally shaking and having a meltdown over the stress of all of this. He is a highly conscientious individual and was working day and night doing his part to make the transition successful. Thankfully, he was able to move to an individual contributor position before the leadership role destroyed his mental and physical health

SAS R&D was built on a very unique and highly innovative culture going back to the late 1970s. Honestly, if anyone commenting does not have experience dating back to pre-MVA code and then the entire history of MVA and TK, then they can't possibly understand just how hard the problem of transitioning to a modern cloud-based CI/CD delivered product is when the whole of SAS (especially some of the highest revenue generating pieces) is taking into account. The UX pieces are the proverbial tip of the iceberg. There is a world of code underneath based on some of the best computer science and applied math. You will find anywhere. Yes, it's aging. Yes it's being displaced by open source, cloud, vendor, offerings, and newer tanks on analytics, AI, etc.. Yet, it was one he-l of an effort and one that I'm damn proud of habe been part of.

From my vantage point, agile is mostly a superficial bookkeeping system (associated with a set of high-priced tools) that has very little to do with real Software Engineering. If doing SCRUM or Kanban or whatever works for your team, then do it and adjust it until you get it right.

However, that's not the same thing as deep thinking about real engineering/deployment problems and creating effective strategies for how to solve them. There is not an agile coach or scrum master who has ever help me improve on these things.

There are many factors behind the "decline of SAS," but it's laughable to say that Agile is one of them. I think that the resistance of some long-timers in adopting what is now standard practice across the software industry is largely to blame.

I am sure that some teams hold scrums incorrectly. You will find that at almost any company. As an individual, one could try leading change by actually working within the Agile framework. That would require learning about how Agile is supposed to work and recognizing when it's being implemented incorrectly. All I ever see are rants about how it's a scam meant to sell books or some Gen-X obsession... as if there weren't thousands of courses and books for every other software development tool in history. Every generation evolves this industry in its own ways. I also don't get why OP keeps trying to make this a generational battle.

In my opinion, what's much worse than Agile is when managers pretend to do Agile for the sake of appearances while telling their teams to ignore the process entirely. Those managers are letting the company down by lying, and they're making decisions that they weren't tasked with. They are also letting their employees down when it comes to career development and marketability when they seek new jobs. I have seen less of this behavior recently, possibly because many of these managers have moved on to other opportunities. I don't think that's a bad thing.

I am curious if OP feels the same way about Git and CI/CD, both of which have been taught in computer science programs across the country for 10+ years. I still hear people complaining about those things, and I feel embarrassed for them. They're usually the same people grumbling about Jira.

If 7 testers found 6000 bugs in a few months, that was poor management. Developers should have been incentivized to find all the bugs that were easy to find.

The whole point of having testers is to find the bugs that developers don't find. If you have skilled testers, you don't waste their time looking for the easy bugs.

At SAS, most of us saw a mix of skilled and unskilled testers. I wish I could see a clear explanation of how, last week, they kept the skilled ones, and laid off the unskilled.

"Good engineers produce good stuff and they also know how to validate their fundamental product. Not dissing on testers, just saying good developers know how to produce quality software that can be validated."

This gave me a good chuckle... makes me wonder why in the just completed re-write of one of the GUI based applications, a team of 7 testers found 6000 bugs in a few months period... wonder what happened here. And that's not a-typical either. Code written by excellent developers - top of the line people. I have great respect for them. Lots of factors go into delivering good software.

Having been a "developer" aka programmer before - responsible for testing my own code, I have seen how hard it is to think outside yourself to test your own software. You tend to develop tests to match what you think you wrote the code to do.. very hard to come at your code from a fresh perspective. Love that "OH s**t moment when you realize how your logic didn't account for THAT case.

Years ago, I once saw a curious picture of a particular manager at a meeting for high level managers. It was puzzling why this person was in the meeting, as they were not a high level manager, nor had any relevance to the meeting. They probably weren't even invited.

The picture had all the leaders standing behind the senior leader, who was seated in a chair. At the senior leader's knee was this outlier, kneeling like a small, desperate child. It was a really bizarre photo.

This is one Boomer who often worked 7 days a week for SAS, ate lunch in my office while working, and exercised at home prior to coming into work to optimize travel overhead. I worked for a West Coast tech company (after leaving SAS) that required less grind.

Maybe the Boomers and Gen Xers should spend time chasing Pokémon around campus, join in the guitar classes In conference rooms and joining multiple special interest groups they be more productive

"I was targeted for the next layoff, and said manager eventually became Sr. Director."

Yep ... your garden variety corporate power player who only cares about their own promotion and the appearance of looking good. When SAS started hiring these types (they were only a few prior to the year 2000), is when the slow demise began.

"When asked to stop this crazy behavior in favor of actually slowing down for two days, doing the analysis, and solving the problem once and for all, said manager replied "But I'm doing Agile!"; uh, no. You are churning labor for the appearance of "responsiveness", but with negative results. I was targeted for the next layoff, and said manager eventually became Sr. Director."

Sigh ... now imagine attempting to design a new SAS component that requires a couple of months basic research and prototyping -- something specialized and suited to one or two (true) Principal level Developers. Having to give daily updates on the progress is ridiculous, this project need someone who can lock themselves in a quiet office for weeks and diagram/prototype.

This is largely how SAS was built -- especially the base components that continue to generate revenue. Many of those involved had decades-long careers. Their work is the reason why SAS COULD CONTINUE TO HIRE AFTER THE YEAR 2000 (cue jack, Nicholson's diatribe at the end of A Few Good Men 😉).

OP is also a Boomer, with decades in R&D who is attempting a little bit of irony with the final paragraph -- not trying to denigrate anyone.

In my view Agile is well, beyond "a tool", in the estimation of the modern software industry. It's an entire philosophy (ever evolving with variations) built on creating consulting, courses, and certifications, that attempt to lend authenticity to a money making scheme that has managed to further stratify development, efforts, and isolate engineers from the very people they're building technology for.

Good engineers produce good stuff and they also know how to validate their fundamental product. Not dissing on testers, just saying good developers know how to produce quality software that can be validated.

The best engineers engineers often communicate well and are capable of working directly with their target user base. For the relative handful of engineers, who do not communicate well, it is often because they are so focused on creating the deepest and most beautiful parts of the technology -- the parts that require a special kind of intelligence. Those folks can be supported by the rest of the team.

The team I worked on practiced Agile well and effectively. The manager for that team had worked elsewhere, and set a good example. They rose in the company.

Sadly, another who rose in the company mistook Agile for "hot potato". It went like this - An EVP would send a specific request to said manager. Said manager would tell their team to do the specific request stat, just so this manager could respond to the EVP that the task was done. "Something" got done, but the end result was haphazard, wrong, and simply a waste of time and effort. The next day the cycle would repeat for that same task.

When asked to stop this crazy behavior in favor of actually slowing down for two days, doing the analysis, and solving the problem once and for all, said manager replied "But I'm doing Agile!"; uh, no. You are churning labor for the appearance of "responsiveness", but with negative results. I was targeted for the next layoff, and said manager eventually became Sr. Director.

I think Agile works better when developers can shift easily between areas of work, and that is far from being universally true at SAS. In my main area of responsibility, it was very much not true. Lots of highly specialized experts and not many generalists. It was good for everyone to be in touch regarding what they were working on and to share ideas, but at the end of the discussion the work at hand was still the responsibility of the same person as before.

In my other main area, management, after wasting our time having us do a survey of other R&D groups to investigate points of integration for an expanded offering, management decided to shift all dev resources to help out with the Go conversion of another product. All but one quit or retired in response. Yep, developers were not so interchangeable as management thought.

For us product managers, CI/CD became an operational burden, to say the very least. The fixed cost of monthly releases swamped everything, including proactive customer outreach. On top of that, my view is that monthly releases might sound good but are of very dubious practical value. Consider that, even when SAS was releasing annually or semiannually at best, customers would still lag one or two releases behind.

All in all, this (plus the noted terminations of longtime employees) is why I accepted the 2021 early retirement package and called it done after 35 1/2 years with SAS.

I'm a Boomer. You should speak more nicely of us, because we're all old and grumpy :-)

Scrum is a poor choice because it leads to a rigid process that constrains developers. Managers often like it, perhaps because it gives them more control. Kanban is a better choice because it gives developers more freedom and thereby increases their productivity.

However, methodology isn't the determinative factor here. Recall that development of SAS started in 1966. What methodology did they use? Waterfall, or none at all? Probably the latter, and it didn't matter. Good software engineers produce good software using any methodology.

Agile is only a tool. People matter a lot more than tools. We've had 40+ years of A people hiring B people who hired C people. The determinative factor here isn't any tool, but the Peter Principle.

Warning, personal opinions ahead, most of which are probably not correct.

1. Agile is only a tool - I do think SAS has taken the "prescribe once, apply everywhere" approach to Agile, Scrum, JIRA, and planning too far. The process these days is overwhelming and suffocating to development teams and leaves no room for autonomy. That said, I don't think Agile is a make-or-break detail. I see it simply as a tool for execution against a plan. A bigger problem I see is a lack of strong product leadership and requirements that work in concert across products to accomplish a common goal.

2. Lightning rarely strikes twice - I honestly think the downfall of SAS isn't process, or people, etc. I honestly think that it's very hard for a company to strike gold twice. It could be argued that companies like Google or Facebook are still riding mostly on their singular cash cow...or that some of their other successes are acquisitions rather than organic ideas. Try as hard as they have (and still are) coming up with a second billion dollar idea in this fast-paced world is not easy.

3. CI/CD was a mistake - at least partially so. I think SAS took it too literally that "companies like facebook ship software every 30 minutes". SAS still (mostly) ships software installed by customers on their own hardware. Of course having the tools and automation to iterate quickly is important, but I feel we tried too hard to copy what aaS companies are doing without actually being a service operator ourselves. In fact, I think we actually made things worse since now Viya 4 is architected like a cloud service (usually operated by the very company that develops it) and instead we ask our customers to operated it. Worst of both worlds in many ways.

Like I said, happy to be wrong about these...just the way I see things.