Thread regarding Cisco Systems Inc. layoffs

3pdr - have you looked at the financials for the companies you listed recently? Most are in decline. Is this due to eeoc hires for ceo?

@3lbv: You are bitter, scared and irrational. The USA got to where it is today long before the influx of H1B Indian engineers happened. We may fall from the 'greatest country in the world' slot going forward but trust me, we will do fine without the low to mid-level Indian software engineers of Silicon Valley. Take a deep breath and get over yourself.

OP.. Just because they are indians doesn't mean they are bad.

Look at CEOs of Google, Microsoft. Aren't they Indians ? Oh how come, their stock is going up and they are doing well?

This attitude of people like you is what is causing Cisco to decline.

I think you've got it backwards...it's the people that have been coddled by newer languages that protect you with a "sandbox" and no concept of pass by reference or pointers that get in trouble with embedded coding. That should be left to bit-twiddlers, not people that are more comfortable using constructs that are delimited by "".

This is just a small taste of low level software issues in what could be a set of books on bad management, systems, hardware, software and testing practices. I've seen many variations of everything here in other environments (I left out Cisco unique issues for obvious reasons) so they are clearly a problem with the larger development community:

• Functions sometimes longer than 10,000 lines nested dozens of levels deep with gotos everywhere because no one learned how to use GOSUB in a high school BASIC class in the 1970s. No, it wasn't time critical code.

• Data structures longer than 10,000 lines (some individual lines being arrays of other large structures) with massive replication of data because ??? No, these weren't register maps for complex devices.

• Pointers are cast through int as an opaque type despite the fact that 64-bit systems were available for decades when that code base was created. Newfangled Pascal acolytes with their "unions" are too abstract and correct.

• Having a macro with a dozen static arguments followed by a variable argument list where all the static arguments are type cast inside the macro so the type checking which would have revealed many missing, extra or simply wrong parameters is gone

• APIs can't specify what internal details can't be depended upon so clients can both depend on those unsupported details most likely to change and reach into and change data in structures of APIs directly because there is no way changing the state from external code in a way the internal code doesn't expect could cause problems

• Code written for one compiler with one set of flags for one instance of one instruction set architecture on one version of one OS will run the same on every other permutation of compilers, build flags, operating systems and processor architectures. Java developers know this isn't true and Java was supposed to be "write once run anywhere." How do C developers of 30 years still not get this?

• A range check rarely executed is more expensive than multimillion dollar outages because those come out of other people's budgets. Ironically even when executed frequently there are many times when check code simply runs in unused stall slots costing almost nothing in cache utilization and therefore adding almost zero execution time.

• What should have been one function with one behavioral definition on 100 branches can actually be 100 different incompatible functions with a common declaration where syncs and collapses won't have any negative effects

• The library O(n^6) algorithms work fine for n=1. If your platform requires n=10,000 that's not a library developer problem.

• Not creating another instance of the halting problem is starting to look like another instance of the halting problem

• A run to completion environment which is later changed to allow control to be handed to an arbitrary second block of code before the first block completes doesn't need any interlocks even when the code executed in the second block trashes the state in the first uncompleted block

• By extension there is no need to manage shared structures and hardware state with mutexes on multithreaded systems which are explicitly preemptive

• Data structures of all kinds can never been freed because developers don't know how to design complex interrelated structures which can be torn down. When allocation of these structures fills memory and you have no choice but to try to free things, put them on a short recycling list hoping everything will stop referencing them before they get pulled off that list for use elsewhere.

• Using reference counting for resource allocation while releasing the resource on the first deallocation

• Code is written for a single instance of something with all state stored globally and when someone creates a second instance of the same thing rather than adding a parameter to the functions to hold instance specific data all the code is cut and pasted and the function names changed in the second instance

• Having no clue as to how much "" goes on in the management plane and how many lifetimes have been lost fixing bugs in broken hand written string code

Usually you see 15% good engineers among any groups of people (age or ethnical). In Cisco San Jose, in some teams everyone from SVP to engineers is Indian. This picture tells you that something is terribly wrong, be it product quality or ethics.

I think you've got it backwards...it's the people that have been coddled by newer languages that protect you with a "sandbox" and no concept of pass by reference or pointers that get in trouble with embedded coding. That should be left to bit-twiddlers, not people that are more comfortable using constructs that are delimited by "".

Agile. Maybe that post-it note didn't have enough stickiness on the back, fell off the white board and ended up in the "basura" during the evening tidy-up. But hey, that's the price you pay for migrating from development models that put people on the moon, simply in order to see dollars now.

Don't worry, it can be fixed during a continuous inconvenience I mean improvement cycle...that makes sense for critical network gear, doesn't it?

...and layoffs of higher quality American developers and managers.

As a customer from the 1990s I can say the quality was extremely poor long before there was a major development presence in India. Having worked there and suffered through brutally bad SFS, SDS, code and test plan reviews I can say they have almost no "higher quality American developers and managers." Cisco reportedly stole their original product from Stanford and has been acquiring for the last quarter century because they've never had competent leadership and development.

My friend who commented on the quality woes of Cisco NCS 5508:

"Ah… it does boggle the mind how this stuff slips through. I’ve long bemoaned the gaps between WCS/NCS and the controller GUIs, and the perception that the developers on this stuff really don’t get the degree of pain that these little over-sights cause in the real world as we sure get enough of them".

More terrible stories for NCS 6000.

Little they know that this is the direct results of Indian nepotism in Cisco, offshore to India, and layoffs of higher quality American developers and managers.

One thing is that Adobe doesn't spin themselves as a security company...

Security issues are simply a subset of quality issues, and their quality like Cisco's and a wide range of other players is extremely poor. There is no moral high ground for any of these companies.

...with openssl you get quality you paid for.

As customers of Cisco we're paying dearly for the poor quality of both open and closed source code used in Cisco's products which includes OpenSSL. At a ROM Cisco gets a million bug reports a year and with $70B in cash on hand and tens of billions lost on failed acquisitions we're really not getting the quality we're paying for.

I wasn't kidding when I said the royal "you haven't the slightest clue on how many far more obvious mistakes are being made even when the engineering teams involved were taught repeatedly not to make a given mistake." Many people there aren't just intentionally wrong having been presented in advance with the reason why their approach would fail, they celebrate it publicly. If it were unique to Cisco I could write it off as an anomaly, but most people who end up in embedded software using a legacy language just can't think in higher level terms and will end up performing poorly at tasks at every level from hand copying bytes one at a time on up.

@MDFwLkb-1cxa

One thing is that Adobe doesn't spin themselves as a security company, and with openssl you get quality you paid for.

I agree - it's not the first issue and definitely not the last, but if this was indeed the root cause here, then fact that such basic mistakes can still slip through the cracks (after "goto fail", heartbleed and others), is embarrassing for the company.

Indians are the most creative in Cisco Engineering. They are full of new ideas. Using 64 bit counter to count picoseconds is just one of the new innovations that the Cisco Indian management has asked. Anyway, Cisco customers like Google and AT&T are full of creative Indians in their decision loop (likeyfrom the same village). It won't matter.

And what does it say about engineering review process and quality assurance in general?

It says you haven't the slightest clue on how many far more obvious mistakes are being made even when the engineering teams involved were taught repeatedly not to make a given mistake.

Think it's limited to Cisco? Look at the decades of security patches from Adobe.

Think it's limited to closed source? Read any good analysis of the OpenSSL code.

The Internet, which rose from the ARPAnet - a military network which was supposed to survive anything, had all of YouTube's traffic going to Pakistan because a dummy route accidentally escaped the country in 2008. Everything is far more fragile that most people would dare imagine.

Heck, look at this site to see how many people at Cisco think that last August was the first time any company started to lay off old people. The lack of awareness is staggering.

Make the minimum pay 115K or 130K, that will change things.

Top kids out of college are getting six digits in the US. Over a decade ago it was reported Engineer IVs were pulling 130K on average at Cisco. Considering how many Principal Engineers (WAY over $130K) have made obvious individual mistakes costing over an engineering-lifetime and done nothing to begin to offset that cost $130K for truly positive game changers is peanuts for a company like Cisco.

At least in the embedded world having H1Bs and locals compete has somehow left both less competent now than they were a quarter century ago when this started. Removing the H1Bs will increase the cost of development but the quality without competition will likely continue to go down, even if it is no faster than it was going down with H1Bs in the mix. If the locals up their game and they can produce far more with less then people are still out in the street. Change is one thing, but change for the better is far more difficult.

Indian takeover of engineering has damaged the company more than anything else.

The new policy won't change anything. Make the minimum pay 115K or 130K, that will change things. Vague rules can be loosely enforced, especially for the right price or favor.

Trump, Trump, Trump, Trump

The U.S. Citizenship and Immigration Services agency issued a memorandum that makes it harder for companies to bring foreign technology workers to the U.S. using the H-1B visa process.

The new guidelines, issued late Friday, require additional information for computer programmers applying for the work visa to prove the jobs are complicated and require more advanced knowledge and experience. The new policy is effective immediately, so it will change how companies apply for the visas in an annual lottery process that begins Monday.

Raise those starting H1b starting salaries to 100k.