Slashdot Mirror
Real World Code Sucks
An anonymous reader tips an article at El Reg about the disparity between the code you learn at school and the code you see at work. Quoting:
"There is a kind of cognitive dissonance in most people who've moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is, and this is rarely acknowledged. To be precise: a tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it's outright terrible by any number of measures."
It might be interesting to read The Rise of "Worse is Better"
Author of TFA had some bad experiences, worked for some bad software houses, generalizes it to "everybody".
I do not agree that his generalization is necessarily valid. Sure, code in the real world seldom looks like code in textbooks, because code in textbooks is usually designed to solve a discrete problem in a stand-alone way. In the real world, this code will be part of a larger system under circumstances that are less ideal. (Different business requirements, or slightly different mode of operation, etc.)
I work in enterprise embedded stuff where the systems are five nines reliable, and even there we've got problems. We recently ran into a day-one bug that suddenly turned and bit us because we switched to a different brand of hard drive.
I've worked in opposite land apparently... Code quality output by a team of well-vetted coders that I used to work with was high by my standards - low bug rate, decent code coverage for unit tests, generally well documented.... Then I moved to a place where the product was a postgraduate project from a dozen or so CS students. No documentation, ill thought through design, no unit tests, and unmaintainable architecture choices. Why? No real-world experience and no reason for polish, so long as a "working" proof of concept doesn't fall over while being evaluated. (Among other things.)
You look at it as "the real world sucks." I look at it as "college doesn't prepare you for the real world." It doesn't prepare you, because it doesn't expose you to it at all.
In college (at least, when I was there), the focus was entirely on showing you good code, not showing you bad code. This is like running a medical school where the doctors-in-training only see top-form athletes and never get a glimpse of sick people. Beyond lack of experience, a lot of the time the best way to understand why certain standards or principles are good is to see what happens when they're not followed, and you just don't see that in a classroom.
At the risk of drifting into "get off my lawn!" territory, allow me to give an example I experienced.
During my classes ("software engineering principles" or something like that), one of the things we went over was coupling, and why loose coupling was better than tight coupling. Passing parameters is better than using a global variable, which is better than reaching into another module's guts, etc. All very reasonable, and everyone agreed that it made sense. However, nobody, including myself, seemed to give it much weight. Most of us already coded that way, anyway, so it wasn't any big revelation.
A few months later, at a job that involved maintaining and extending a decent-sized (by early 90s standards) application, I had to work with code by a guy who declared a single variable, "s", as an 80-char string, and used that all over the place. Different functions read and wrote to "s" at their whim and without regard for what other code might be doing with it. It was used in place of function parameters, in place of function results, and sometimes just as a temporary variable. Naturally, this caused all sorts of difficult-to-predict bugs. It was when dealing with this crap that a light went on in my head and I realized, "Oh! This is what the prof meant when he said tight coupling was bad!"
"The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
It's even worse than that.
These folks learn the classics, but then go out and are forced to make a living by making new editions of Twilight, Hunger Games, etc. As a bonus, they're not allowed (by edict and budget) to change more than 25% of the nouns (in aggregate, not as categories).
Quo usque tandem abutere, Nimbus, patientia nostra?
This, and even the *book* is wrong half the time. Given the pressure to come out with a "new edition" every couple of years that many publishers and authors face, they re-write many parts of the books, including examples and problems. Often, it's clear that what the author wrote hasn't even been compiled before, as there are glaring syntax errors. (Obviously, some books are better at this than others.)
Most of the people I work with produce much better-looking code than a college student. Interns come in periodically and help prove that point; they write for ease of coding, not ease of reading or maintenance or reuse or anything nice like that. The code from more experienced people is by no means perfect, but they've at least seen both good examples and bad examples when they have to touch somebody else's code, and they tend to pick up a few of the good habits while dropping a few of the bad ones.
Reminded me of a comic by the oatmeal: http://theoatmeal.com/comics/design_hell
The creaping featuritis thing amazes me to this day. I am a codeslinger, if you want it I'll write it. But I will tell you if I think you're making a mistake.
One of my old bosses put it well when a customer was questioning my opinion on some of their stuff I was pushing back on.
"If he thinks it's a bad enough idea to tell you that you shouldn't have him do it, you should f'ing listen. You do remember he bills by the hour? If he's telling you it's not something you want him to do he's doing you a favor. And if he won't do it there's no way in hell we'll do it for you, he's the guy we send people to for crazy shit."
The simple truth of the matter is that most commercial code is written by overworked developers on tight schedules and with miniscule budgets. The managers crack the whip and rush things along because the people who sign the checks don't care about quality code if it means that they won't have a "first mover" advantage in the marketplace. This is particularly true in the consumer space and the phone app world. Much of that code is just pure shit. Ironically, some of the best and worst code that I've seen in the wild comes from the open source community. Is there any good commercial code out there? I'm sure that it does happen from time to time in mature products. The engine control unit in your car or perhaps the drill bit controllers on oil field equipment or maybe the hard disk controller, but in my experience crappy code is the rule and quality is the exception. Users rarely perceive quality as long as they system works, so few are willing to pay more for it in either time or money.