Real World Code Sucks 292
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."
must read: "worse is better" (Score:5, Interesting)
It might be interesting to read The Rise of "Worse is Better" [jwz.org]
Sounds like sour grapes to me. (Score:3, Interesting)
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 think he's mostly correct (Score:5, Interesting)
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.
other way around? (Score:2, Interesting)
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.)
Just like the Boy in the Bubble (Score:4, Interesting)
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!"
Re:Captain Obvious? (Score:5, Interesting)
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).
Re:Captain Obvious? (Score:4, Interesting)
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.
Re:Captain Obvious? (Score:5, Interesting)
Re:must read: "worse is better" (Score:5, Interesting)
In production you have to know how to apply X, Y, Z, B, E, and G. But you don't start by trying to learn all of them at once. You learn simplistic examples that hopefully teach you the theories and best concepts for 'X'.
Re:must read: "worse is better" (Score:3, Interesting)
In their almighty wisdom they thought I wasn't doing as great a job and replaced me with some kid straight out of university who had never programmed in his life. The entire data team crashed, stopped accepting data and had a huge backlog, cost tens of thousands of dollars in lost productivity and project holdups. It was my state government btw and it taught me that my imagination is lacking when it comes to government waste and abuse.
Re:Captain Obvious? (Score:4, Interesting)
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."
It's Terrible Because Nobody Wants to Pay (Score:4, Interesting)
Re:must read: "worse is better" (Score:4, Interesting)
Yeah I still have no idea how to do logging well.
But what I like to do when performance is not an issue is to log everything (DEBUG etc) into a context ring buffer. Then normally only log messages above the configured log threshold will appear in the logs (e.g. INFO, NOTICE, WARNING). The DEBUG stuff won't appear. BUT if a log message above a log the context threshold occurs (e.g. ERROR, CRIT) the contents of the context buffer is logged followed by the actual triggering log. This way I don't have to turn debugging on. It can always be on BUT I don't have my logs full of the debug level logs unless "stuff happens".
This context logging stuff is bad for performance, but so far it's not a problem for the stuff I do (and can be turned off). It does make it easier to figure out what happened while creating less DEBUG noise.
As part of my log messages I also have hashes and dots, e.g.:
DEBUG = one hash = #........
INFO = ##......
NOTICE = ###.....
This way I can easily "grep" log files for logs above a particular threshold. If you're Google or Facebook scale you'll have to do things a bit differently because there'll be zillions of logs, you can't have half a million machines send logs to one log server ;). So you'd need a way to summarize logs.
It might also be nice if the CS lecturers spend some time discussing the merits of different exception handling approaches in various scenarios. Instead of just stuff like this: http://www.cs.auckland.ac.nz/compsci105s2c/lectures/adriana/Lecture06.pdf [auckland.ac.nz]
Doesn't need to be as detailed and extensive as this: http://www.amazon.com/Advances-Exception-Handling-Techniques-Computer/dp/3540419527 [amazon.com]
Just some basics that might open up student eyes to how things work in the real world and more importantly how things could fail, and how one might deal with them.
FWIW I didn't do CS. I did EE. So maybe this stuff is actually covered in some CS courses. I doubt it was covered in my colleagues CS courses though ;).