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."

Comments

must read: "worse is better"

[Polo]

It might be interesting to read The Rise of "Worse is Better"

Re:must read: "worse is better"

[pixelpusher220]

Summarized as follows:

"In theory there's no difference between theory and reality....in reality it's the other way around"

Seriously, real world code is by definition 'real world' and doesn't live by the theoretical pillars of design. It has to deal with actual deadlines, finite resources and of course office politics.

Re:must read: "worse is better"

[icebike]

Summarized as follows:

"In theory there's no difference between theory and reality....in reality it's the other way around"

Seriously, real world code is by definition 'real world' and doesn't live by the theoretical pillars of design. It has to deal with actual deadlines, finite resources and of course office politics.

Exactly.
Where the professor can take 6 months to prepare a small simplistic demo application custom tailored to demonstrate his (pet) coding methods and design standards, in the real world you have to get things done, not in 6 months, not in 6 weeks, and seldom in 6 days. You might have 6 hours on a good day.

Does too much of this quick hacks find its way into production?
Absolutely.
Do bad 2x4s find their way into house construction? Of course.

But corporate world code runs every single day, not twice a semester. Its "good enough".
And if it starts to fail it get rewritten, or patched. The truth of the matter is that corporate
systems are long lived, and few if any are fully understood by the current staff, because the guy who wrote it moved on 8 years ago.
And Yet, it gets the job done day after day, year in and year out, because people watch it and know what to expect.

Do houses fall down because of bad 2x4s? Virtually never. Maybe after years of
remodeling, rewiring, re-plumbing, the place will burn down, but there is usually
a recent idiot involved, rather than the original builder.

We build things "good enough" in this world. Not Perfect.

Captain Obvious?

[Anonymous Coward]

This just in: real world a lot harder than school.

Gee, thanks Slashdot!

Re:Captain Obvious?

[K. S. Kyosuke]

The first thought that occurred to me is the equivalent situation in literature: People go to school, read and learn from Shakespeare, Austen, Melville, Twain, Hemingway, Faulkner, Tolkien...and then they go out and write Twilight and Hunger Games. I guess some people simply aren't cut for it?

Re:Captain Obvious?

[ShanghaiBill]

The 25-line program you write for a school assignment is not the same as the 5000 lines you are writing to implement a set of vague business requirements.

Some of those 25-line programs are not so good either. If you really think students write good code, get a job as a TA and grade some assignments.

Re:Captain Obvious?

[Penguinisto]

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?

[Phrogman]

Then in school they should be recreating the actual real world experience, you know:
* a representative from the "Business" comes to you with a vague concept of what they want, mostly consisting of "Something like X" but more like "Y" with some of the features of "Z" (3 completely different things that have no apparent relationship to each other). After a few days of meetings you determine that what the person wants is based more on the colors used and the layout being pretty to them and not at all on the features or functionality.
* You then seek out a group of various people who actually know what might be required, and grill them to try to get an idea of the features and functionality required. From this you create an initial design document.
* You run the design document that describes what you think are the features and functionality past the people above who all agree you are on the right track. You add more details and they all agree its perfect. Mostly they don't actually understand what you are talking about but they nod their heads sagely and agree because they don't want to look incompetent.
* You begin coding (or possibly get together with a team and fight over things for a few days/weeks/months) and get a prototype built. You show it to those you have spoken with and again its on the right track.
* You code up the first version. You reveal it to people and its "great".
* Then the people start filtering in with design "suggestions" that mean massive changes to what has been written and done, possibly shifting the entire project in a different direction. These conflict with each other and trying to find the middle ground occupies as much of your time as actually trying to write anything.
* The marketing people come into the picture and it turns out that *they* are the ones that really have the authority to make the design decisions, not the people who you originally talked to, but as an added bonus the marketing people don't have the slightest clue about the required features or functionality - just what they think they can sell to customers. Getting their salable features shoe-horned into the program becomes your top priority now.
* The program also has to look "pretty" so the art department enters the picture and they demand massive changes so that the layout is much nicer and easier for them to do, minimizing their workload as much as possible because they are completely overworked and under-budgeted. You meet with artists in rooms that are completely dark and stare at photoshop images that are renderings of what they see the program looking like. It bears no resemblance to what you have been working on and they have made massive changes to everything renaming all the menu entries etc. It is however pretty, or rather the 3 different versions of it are pretty, and you have to wait until marketing determines which one is the best.
* now you are way off schedule because of all the monkeys who are making changes based on whats the most important thing from their perspective.
* Eventually its all nailed down and you hurriedly code the new first version up as fast as possible because of pressure from above to be "done this thing already".
* At the last moment when its done, it gets cancelled to be replaced by some other project which is higher priority, or they announce it must be entirely recoded in a different language/script.

Shove that student into this environment. Get people to play the various roles that are about as knowledgeable as people you will encounter in the corporate environment - which is to say find the most qualified idiots you can and put them in the roles.

 

Obligatory XKCD

[doubleplusungodly]

http://xkcd.com/844/

School code

[phantomfive]

The opposite is true too: code you see in textbooks is often horrible. It omits error checking, often uses global variables, makes assumptions, etc. Someone mentioned that K&R has memory leaks all over the place, because it's more readable.

The goal of textbook code is to be readable, to communicate, not to handle every possible case. This means industry code is often less readable, but more solid. I'm sure I've missed other ways academic code is bad.

Of course a lot of industry code is unreadable and also not solid. That's another issue.

No surprises here.

[csumpi]

Because in real life:

- specs change constantly
- need to work with crap that's already there
- there are deadlines
- need to get stuff done

And I'm pretty sure I'm forgetting some other points.

School v. Reality

[girlintraining]

This just in: Examples provided in school have no practical real world application. Duh. In the real world you have things like deadlines, bosses, and clueless managers. When you screw up in class, the teacher tells you where you messed up and you get a chance to do it again. In the real world, when you screw up you probably won't know what you did, at least not right away. And you're going to have to figure it out while everyone is mad at you, calling your phone, and asking why it died.

I don't know where this idea of the Zen Programmer(tm) comes from with visions of calm blue waters and bright bleached sand and everything is calm, thought out, and composed. Programmers I know hammer down mountain dew like it's nobody's business. They do not spend months debugging and thinking about it academically: If it works, you move on to the next thing. Don't bitch about the quality of the code (manager or academic) in the real world because there are almost no programmers in the corporate world that sit around thinking in O notation and figuring out the best and worst case scenario for every line of code. They bang out 500 lines in a few hours and then hit compile and hope to god it works on the first go.

That's reality people -- you don't have the time, the resources, and if you took the academic attitude to work with you, you'd be cut up and used as shark food by everyone else for being so damn slow and pragmatic when they need things working tonight so they can go home after being there for 15 effing hours to make the latest milestone.

Obvious Observation, Misleading Conclusions.

[VortexCortex]

Yeah, they're right about the state of things, but they get the "why" part totally fucking wrong:

The most common reason for the existence of bad software is bad programmers.

NOPE! Bad software is a result of BAD Code, even good programmers can write bad code...

At the other end of the spectrum, many projects are sabotaged by developers who are “too good”

NOPE! Maybe those scare quotes are there for a reason, but "doing things the most complex way possible" is usually because coding is iterative and there was no way for you to know of the unforeseeable future requirements.

And then there’s “bad” laziness, the kind that leads programmers to cut corners or do things in the quickest possible way, rather than taking the three extra hours to do them right.

NOPE! You're assuming that the programmer WANTED to do things the quickest way possible...

If the system is working, almost no manager will pay just to have you recode a piece of it “the right way,” without adding any new functionality. There’s always something more important that needs to be done—until that quick-and-dirty fix blows up and (because it’s urgent) gets replaced by another quick-and-dirty fix.

BINGO! This. Everything, all of the other bullshit is due to Management. Not just not paying to have things done right (see: Fast, Good, Cheap), but also unrealistic schedules and deadlines, new features being promised by sales without consulting the programmers, etc. Deadlines exist. That's why even a good programmer hacks in a kludge ridden short cut instead of taking the time to do it the right way: There is no time to take! The most common reason for bad software isn't bad programmers, is bad management and terrible working conditions. See also: Getting what you pay for when you outsource the programming department. The outsourced workers will get it done cheaper in less time -- Cheap, FAST -- What's missing here, eh? GOOD Sadly to compete with the fast and cheap the goodness of the software must be sacrificed.

As mentioned above, C++, despite its superficial similarities to Java, is infinitely easier than Java to write impenetrable code in. And one language I’ve been warned about, though I’ve never had the opportunity to use it, is Haskell, an offshoot of ML. According to a friend in academia who’s studied it, it’s “the Taliban version of ML,” in which it’s all but impossible to write readable code.

Just stop talking noob.

In the real world, tight budgets, shortsighted managers, and unreasonable expectations from non-techies almost always conspire to make developers do things too quickly.

You mention this and yet you somehow fail to realize THIS, not Languages, not Laziness, not Ignorance, not Hubris, is what is really the root cause of all the damn evil?! Fuck you, man. You're part of the problem.

In conclusion: Bad software is primarily a result of GREED.