Can someone explain to me how you can understand the culture in a team of programmers that leads to this being acceptable? Just a few small guidelines could help alleviate things like this, right? Modularization and a tiny sprinkle of code review and this is solved. Perhaps some (big) initial effort to clean up if you've started with code bases of different individuals with the goal of integration.
In large companies there is never 'a' team of programmers, there are N teams of programmers with varying amounts of communications and cooperation going on between them, where "varying" often includes being completely unaware of the other teams existence.
N different teams working independently of each other each implement a variation of feature X to solve their own problem. The someone decides it's time to merge the whole thing together and it's easier to just use the N different implementations of X rather than to try to refactor and debug a single implementation of X that works for all N cases.
"Just get it out the door and we'll fix it later". I've heard that from most managers I've known.
Instead of this:
"We need to audit then refactor the existing codebase to bring it up release quality. It will delay release by 2 months, but we are dealing with customer PII so we have to be as stable as possible to prevent break-ins."
What I've noticed is that in general that as long as there some activity (even if it's bad) it is considered success. I'm currently knee-deep in a code base where the exact same function was nearly copied several dozen times and trying to fix it gets shot down as a "waste of time". I say nearly because in some places the same exact variable is misspelled many different ways.
The "culture" behind this is endemic to industry and isn't anything unique to Huawei.
People have already commented on this not being a "team". Let me focus on "programmers".
What probably happened is that many of Huawei's programmers are EEs who happened to take a programming course or two in college.
But learning to think and behave like a good programmer is much more than that. It requires a certain mindset. It may require a certain amount of avocation and enthusiasm, beyond what is taught in an introductory programming course. It requires one to grok good software practices.
Most non-CS majors in college (USA or China or whatever country) probably don't get much of that cultural indoctrination during the few programming courses they take. The engineer wants to pass/ace the programming course. Learning the aesthetics or nuances isn't a priority.
Programming is just too easy. Type a few lines into a file, compile, debug syntax errors, tweak until you get something that looks right. There's no rigor involved. No style. No aesthetic.
Don Knuth called it "The Art of Computer Programming". I submit that many engineers don't think of programming as an art. It's just a means to an end.
E.g. here's an example from a large codebase that was extensively reviewed. The context was Toyota's unintended acceleration problem of about 15 years ago. The design review found things like: Other egregious deviations from standard practice were the number of global variables in the system. (A variable is a location in memory that has a number in it. A global variable is any piece of software anywhere in the system can get to that number and read it or write it.) The academic standard is zero. Toyota had more than 10,000 global variables.[1]
None of this will ever change until and unless a company's top level management understands the problem and mandates change.
Additionally, there's always an incredible push to bring new products to market. That's 1000x more important than it is to follow best software practices.
> What probably happened is that many of Huawei's programmers are EEs who happened to take a programming course or two in college.
Oh yes. Most of my classmates have picked EE over software engineering because they "dislike programming". The fact that EE (and any other engineering field really) is now mostly about programming anyway is lost on them.
People designing EE study programs are usually completely unaware that, well, computers exist. I have literally heard "Want to learn programming? Uh, just spend a weekend playing with Matlab or something and you will be set.".
Sometimes the academic standard isn't realistic because software that large is often written by many people in different stages with little thought to architecture. Coupled with the fact that software design is so ambiguous (i.e. why you get papers with the title meme "considered harmful" to the n power for certain software practices) I don't blame people for being confused. For example, people can make legitimate cases for use of goto, continue, and break which academics consider bad practice because it interrupts program flow. My guess is the primary reason it had 10,000 global variables is because of lack of knowledge, but also lack of structure. And to restructure the code with that many pieces of global memory would probably require extensively rewriting. And I can't tell you how many articles I've read that tell you to never rewrite applications because it implies a death sentence for the company (ie. Netscape).
Someone once described the difference between working with Cisco and with Huawei as being (and I'm paraphrasing) with Cisco if you have a feature request or bug report, you'll submit it through to your account manager, it will work its way through the Cisco machine, and eventually it might get added/fixed. With Huawei, if you spend enough they'll just give you someone to develop whatever it is you want. That came from someone with a ccie so I guess they have some level of interest in making Cisco sound more organised, but it would explain why Huawei have issues like this
