Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Real World Code Sucks

Soulskill posted about a year and a half ago | from the so-does-real-world-math-and-real-world-cooking dept.

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

cancel ×

292 comments

Sorry! There are no comments related to the filter you selected.

must read: "worse is better" (5, Interesting)

Polo (30659) | about a year and a half ago | (#42364769)

It might be interesting to read The Rise of "Worse is Better" [jwz.org]

Re:must read: "worse is better" (1)

Anonymous Coward | about a year and a half ago | (#42364973)

The article isn't even talking about "worse is better" or "the right thing". Those are both design approaches with different tradeoffs. The article is talking about just badly done code. Badly done code doesn't follow a design methodology, that's part of the problem. Bad isn't a pattern, and bad can't be described simply.

Re:must read: "worse is better" (5, Insightful)

pixelpusher220 (529617) | about a year and a half ago | (#42365403)

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" (5, Insightful)

icebike (68054) | about a year and a half ago | (#42365721)

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.

Re:must read: "worse is better" (0)

Anonymous Coward | about a year and a half ago | (#42365587)

Are we talking about PHP? Because I agree.

Re:must read: "worse is better" (4, Insightful)

firewrought (36952) | about a year and a half ago | (#42365133)

It might be interesting to read The Rise of "Worse is Better" [jwz.org]

That's a great article for high-brow programmers who want to triple-plus-abstract and design-pattern everything. You know... the folks who Joel Spolsky calls "architects astronauts". However, notice that this article is readable and thoughtfully characterizes the two coding styles it trying to differentiate. Fundamentally, this person knows their craft.

This is unlike some of my coworkers, who still embedd SQL straight into their GUI's. (I know of one of our apps where all the methods have the same 30+ parameters being slopped around [to represent a row from table X] because the original dev team couldn't be bothered to create a class called "X" to represent the concept of X and so pass around 1 reference.)

These people aren't heroic real-world veterans who sagely ignore the pretentious chatterings of academics... they're simply folks who don't understand how to express themselves clearly in code, much less the runtime environment, compilation process, or other fundamentals of the basic tools they've worked with for the past ~5 years.

Re:must read: "worse is better" (1)

PRMan (959735) | about a year and a half ago | (#42365309)

It might be, if it weren't black on gray with no contrast. But since it is, I'll never know.

Captain Obvious? (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42364791)

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

Gee, thanks Slashdot!

Re:Captain Obvious? (5, Funny)

K. S. Kyosuke (729550) | about a year and a half ago | (#42364971)

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? (5, Interesting)

Penguinisto (415985) | about a year and a half ago | (#42365351)

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? (2)

Smallpond (221300) | about a year and a half ago | (#42365087)

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

Gee, thanks Slashdot!

The reason is pretty obvious. 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.

Re:Captain Obvious? (5, Insightful)

ShanghaiBill (739463) | about a year and a half ago | (#42365323)

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? (3, Interesting)

Macman408 (1308925) | about a year and a half ago | (#42365521)

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? (5, Insightful)

Phrogman (80473) | about a year and a half ago | (#42365355)

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.

 

Re:Captain Obvious? (1)

Anonymous Coward | about a year and a half ago | (#42365491)

Suicide among teenagers is bad enough, man.

Re:Captain Obvious? (0)

Anonymous Coward | about a year and a half ago | (#42365605)

^ wonderful post. perfectly captures what i've had to deal with many times.

Re:Captain Obvious? (2)

Penguinisto (415985) | about a year and a half ago | (#42365371)

...to say nothing of the fact that instead of writing a program from scratch, you're forced to maintain others' programs instead, or to add what you write to existing (fundamentally crap, poorly-maintained) code.

Yay?

Re:Captain Obvious? (1)

Austerity Empowers (669817) | about a year and a half ago | (#42365095)

Not at all, most of the real world problems are problems you see solved in academia, very well. The code quality is a direct result of the "coding to the business need" principle, where everything is done based on a business identified function/schedule.

The persistent problem with purely competitive environments is that there will always be an incentive to beat the other guy, at any cost.

Re:Captain Obvious? (1)

DragonWriter (970822) | about a year and a half ago | (#42365519)

Not at all, most of the real world problems are problems you see solved in academia, very well. The code quality is a direct result of the "coding to the business need" principle, where everything is done based on a business identified function/schedule.

Perhaps more precisely, that the code produced in the "real world" is often "graded", in the immediate term, by a PHB that will be satisfied if it superficially appears to work (they'll eventually get upset at the costs produced by less-obvious defects and poor design, but at the point they often won't be punishing anyone for it, except probably by making them "fix" it -- to the same flawed standards as before -- if they are still around.)

Re:Captain Obvious? (1)

RabidReindeer (2625839) | about a year and a half ago | (#42365463)

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

Gee, thanks Slashdot!

PHB: Nonsense! Programming is dead easy. My 10-year-old nephew wrote a program just the other day. It makes a little square box bounce around on the screen. We don't need these overpriced prima-donnas spouting techno-babble about Separations of Concerns or stuff like that. A half-hour and you can have web pages on the screen and ready for production tomorrow. All You Have To Do Is...

Obligatory XKCD (5, Funny)

doubleplusungodly (1929514) | about a year and a half ago | (#42364799)

Re:Obligatory XKCD (0)

Anonymous Coward | about a year and a half ago | (#42365283)

This is why those of us who can work fast and well make so much money.

Re:Obligatory XKCD (1)

Anonymous Coward | about a year and a half ago | (#42365705)

Obligatory website: http://thedailywtf.com/ [thedailywtf.com]

same... (2, Insightful)

jimpop (27817) | about a year and a half ago | (#42364823)

It's no different than business school examples vs real world practice.

Re:same... (4, Funny)

Anonymous Coward | about a year and a half ago | (#42364893)

It's no different than business school examples vs real world practice.

And English class samples (such as books and essays that they have you read) versus the comments you read on YouTube.

Sounds like sour grapes to me. (2, Interesting)

Jane Q. Public (1010737) | about a year and a half ago | (#42364845)

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 think he's mostly correct (4, Interesting)

Chirs (87576) | about a year and a half ago | (#42364997)

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.

Given (2)

vanyel (28049) | about a year and a half ago | (#42364857)

It's "rarely acknowledged" because it's just a given...

Its a joke right? (0)

Anonymous Coward | about a year and a half ago | (#42364867)

Are you kidding? I do systems programming code all day In C/C++, and the hacker code in the ANSI C book is a steamy pile of crap. We would have security problems, and hard to find bugs all over the place. This is not to mention that our static analysis tools would prevent such code getting into our code base.

Re:Its a joke right? (2)

RabidReindeer (2625839) | about a year and a half ago | (#42365493)

Are you kidding? I do systems programming code all day In C/C++, and the hacker code in the ANSI C book is a steamy pile of crap. We would have security problems, and hard to find bugs all over the place. This is not to mention that our static analysis tools would prevent such code getting into our code base.

Try the Enterprise Java books, instead. J2EE has a built-in security framework. It's not very sophisticated, but it's well-tested and it intercepts many types of exploits before they can get anywhere near the application code.

On the other hand, I've seen many DIY login/security systems over the years and most of them are total tissue paper security-wise.

So what do all the Enterprise Java books use for examples? DIY login screens!

not true (1)

technosaurus (1704630) | about a year and a half ago | (#42364871)

Most of the code that I spent time reading was my own, and trust me - it wasn't perfect... probably should have bought the text book.

School code (5, Insightful)

phantomfive (622387) | about a year and a half ago | (#42364879)

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.

Re:School code (4, Insightful)

GGardner (97375) | about a year and a half ago | (#42365191)

I'm sure I've missed other ways academic code is bad.

The biggest difference is that academic code is _short_. If your whole code base is 10k lines, it's easy to cover all the requirements in a clean design. If you are dealing with millions of lines, there's all kinds of oddball unforeseen interactions and requirements that pop up way late in the game.

Re:School code (3, Insightful)

SydShamino (547793) | about a year and a half ago | (#42365369)

This is what I came here to say. (Disclaimer: I'm a hardware engineer and most of the code I write is in HDL.)

There are two factors at work.
1. With the exception of big thesis-style projects, most academic work is scoped for you by the nature of the assignment or the teacher. This is almost never true in the real world.
2. When options are available, the proper way to write code is the way that is most readable and supportable. However, the most readable way to write a given piece of code varies by its scope.

Thus, as you work on real-world code, you might design something a certain way because it's the cleanest, most readable way you know. Then, later, as the scope of the project is made more clear, either through your own investigation or through changing business requirements, you have to modify the code, but you don't have enough time to toss it all out and start over with a new design that is the most cleanest, readable way to do things given the new requirements. This is most especially true when the scope changes in little steps, each one of which seems small enough to not be a big deal.

My example is with state machine design. For a simple system that moves between a few states and has a few Moore outputs, a single-process state machine with good state names and a few comments is readable and supportable - it all fits on one page. But if I'm designing a 50-process state machine to handle a big, complex process (and can't break it down into multiple machines for timing or whatever reasons), then I'll use a multi-process state machine, with state and nextstate separated, and probably a dedicated process for each I/O or group of I/O signals, where each one can get it's own page-sized bit of code and comments. The latter style is much harder to read and follow for simple systems, but if the former type morphs into the latter type, I need to cut it out and start over. That's only possible when time permits, and I don't own my time when I'm on the job.

And all of this assumes that you even bothered to write the code the most readable and supportable way the first time. Far too often the first time code is written, it's written to get "something out there working" so the analog guys or marketing can test their stuff or show it off. And then you don't get time to even fix that code into something readable in the first place. With a project manager and a few software and analog engineers waiting on you, demanding time to do things right the first time can be challenging.

Re:School code (1)

Anonymous Coward | about a year and a half ago | (#42365225)

Another difference between real world code and school code...

Real world code is actually doing something at this moment in the real world, unlike theoretically perfect academic example code.

Just sayin...

Re:School code (2)

arielCo (995647) | about a year and a half ago | (#42365341)

Textbook code is meant to illustrate only the thing being discussed. A book would be less readable if every snippet contained the proper boilerplate for exception handling, pre-execution checks, malloc+free tracking, etc... That's usually covered in separate sections, and the professional coder should be aware of the need even if K&R didn't lecture him on it.

True (0)

Anonymous Coward | about a year and a half ago | (#42364881)

I must agree... The company i work for now has amassed some of the shittiest code ive seen in my whole life and ive been coding professionally for 12 years now.

No surprises here. (5, Insightful)

csumpi (2258986) | about a year and a half ago | (#42364885)

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.

Re:No surprises here. (1)

Anonymous Coward | about a year and a half ago | (#42364945)

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

No, I think you covered the most relevant ones pretty well.

Re:No surprises here. (1)

Anonymous Coward | about a year and a half ago | (#42364995)

The consequences of making a mistake (bug) are very low for most software: just fix it and release a new version. When the consequences are higher (medical equipment software, Mars rover) the code quality will probably be better too.

Re:No surprises here. (0)

Anonymous Coward | about a year and a half ago | (#42365029)

- you have less resources than the scope of work would actually require if done idealy

Re:No surprises here. (3, Insightful)

Xtifr (1323) | about a year and a half ago | (#42365107)

- Requirements are messy (even not counting the fact that they change constantly)
- Textbook code is designed to look clean, but often ignores important edge cases for the sake of simplicity. (See previous point.)
- Cleaning up the code may potentially introduce bugs, so once the code gets past QA, it's often considered untouchable until a demonstrable problem is found.

I'm sure there's even more...

(Test-Driven Development (TDD) is supposed to help address that last point, but A) it's not always perfect, and B) it's not universally used.)

Re:No surprises here. (3)

jnaujok (804613) | about a year and a half ago | (#42365109)

You forgot:

- No one is willing to fix code that already exists because it works "good enough"
- No one is willing to expend the resources (read time and money) to go back and rewrite bad piece of code.
- Fear of new code exposing how bad the other code is.

(32 years of real world coding.)

Re:No surprises here. (2)

gutnor (872759) | about a year and a half ago | (#42365173)

Another one: in real world you get stuff wrong.

  • * Because you are just human and if you code 8 hours a day, 250 days a year, a few of your numerous mistakes will made it through to the client.
  • * Then you get stuff wrong because you are not alone, and communication between humans is hard, so hard that it is another profession altogether. Something will eventually be lost in translation situation between you, your team, your bosses, your client.
  • * More importantly, unlike in the books, most of the choices you make do not have a right or a wrong answer. You chose a solution and you know if you right down the line.

Being wrong require costly rework, or the mythical "phase 2".

Last one: code in books and academia sucks.

Re:No surprises here. (0)

Anonymous Coward | about a year and a half ago | (#42365375)

* Because you are just human and if you code 8 hours a day, 250 days a year, a few of your numerous mistakes will made it through to the client.

8 hours a day? I want your job.

Re:No surprises here. (0)

Anonymous Coward | about a year and a half ago | (#42365349)

Some other possibilities:

- The company had half or more of the project done by the lowest bidder.
- There are mutually exclusive requirements that *must* be fulfilled, by any means possible.
- The two best programmers have two completely different styles and each threatens to quit if forced to conform to the other's standards.

Re:No surprises here. (0)

Anonymous Coward | about a year and a half ago | (#42365353)

Those are good points.

From an Object Oriented standpoint though as soon as you run into transactions, sessions, and databases,

1) Data gets ripped out into data objects
2) Behavior gets sucked into services
3) There goes your "objects"

More generally, code gets written in horizontal layers rather than vertically as it really should, this is again, because of using the same underlying technology.

Also, Rails, Grails, etc perpetuate this by encouraging the lumping of all controllers together, all services together (at least in examples). There is no emphasis on the actual domain and what actually makes good sense to logically clump together, that would actually lead to much more robust code. Unit tests are not usually technically logically thought out components that are tested, just end-to-end tests that happen to cover a component rather.

Its hard to fight quick and dirty when requirements are changing as you code. Disheartening, the system works against you, really.

School v. Reality (5, Insightful)

girlintraining (1395911) | about a year and a half ago | (#42364887)

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.

Re:School v. Reality (2)

neminem (561346) | about a year and a half ago | (#42364939)

Really? Generally speaking, when I was in school, when I turned in a homework assignment, I was told where I messed up, and then went on to the next assignment. Only rather rarely was I given even one assignment to fix any of my previous mistakes, as far as coding went, and the only time there was any kind of "keep fixing it until it's fixed" mentality to any school-related project was my whole-year-long senior project... which was part of a program designed to give us real-world experience by giving us actual real-world assignments paid for by companies. (The company I was working for that year hired me when I graduated, and I'm still working there!)

Yes, sometimes due to deadlines (or simple cost-benefit analysis), not everything will always be perfect when it ships, but I'd certainly always take code written by a company and designed to be shipped, over code designed to be written and turned in as a homework assignment...

Re:School v. Reality (1)

betterunixthanunix (980855) | about a year and a half ago | (#42365083)

Homework assignments are different from real-world code. Homework assignments are rarely built on code written by other people. Homework assignments are rarely checked for robustness against bad inputs; students usually know exactly what sort of input to expect and need not worry about anything else. Homework is usually small -- rarely do you see homework assignments exceed 1000 program statements in any language.

Real world code is not like the code students are assigned in school.

Re:School v. Reality (1)

girlintraining (1395911) | about a year and a half ago | (#42365179)

when I was in school, when I turned in a homework assignment, I was told where I messed up, and then went on to the next assignment.

Me too. They changed that though when the parents complained that their precious snowflake wasn't getting first place in everything; So they abolished competitions. Now there's no such thing as an 'F' in many schools, and they have about half a dozen more letters to represent just how exactly their kid didn't 'F'ail. It is (as my teenage sis would say) "ridonkulus".

Yes, sometimes due to deadlines (or simple cost-benefit analysis), not everything will always be perfect when it ships, but I'd certainly always take code written by a company and designed to be shipped, over code designed to be written and turned in as a homework assignment...

So would I: Because there's a use for one, rarely for the other. Articles like this are like saying "We shouldn't use cars because they pollute" and then suggest we all switch to bicycles until the One Perfect And True Green Solution(tm) arises, perhaps powered by crystals shoved up your butt or some other damn thing. There are programmers who build things academically, and there are programmers who build things like engineers. Engineers give you a best fit solution for a given amount of resources. Academics will always be trying to modify your requirements to fit with this latest paper by some guy who said that the bogo sorting genetic algorithm has the lowest O notation for your use case ever and... zzzzzz... you're already asleep. -_-

Re:School v. Reality (3, Insightful)

SirLurksAlot (1169039) | about a year and a half ago | (#42365131)

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.

You're working with the wrong programmers then. See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone. By the way if you're working 15 hour days it means you're mismanaging your manager and their expectations (and/or you suck at your job).

Undergraduate OS class and reality. (0)

Anonymous Coward | about a year and a half ago | (#42365223)

This conflict is why, when I taught Operating Systems, I assigned code modification tasks. I had never been taught how to work on other people's code, and it is a skill _every_ professional programmer will need. The programming project was to modify an OS (Minix at the time, now I'd use FreeBSD or Ubuntu) in some relatively non-trivial way. Lectures included a trip through "how to read code you don't understand" and "how to investigate if something looks fishy."

Re:School v. Reality (1)

phantomfive (622387) | about a year and a half ago | (#42365529)

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.

Wow, speak for yourself. I DO think of this on every line of code I write.

Of course, the vast majority of code is either O(n), O(n^2), or O(1), so usually this isn't actually hard, unless you put vectors in your stacks or something.

The question is, why aren't you thinking about how long your code will take to execute?

Re:School v. Reality (1)

cas2000 (148703) | about a year and a half ago | (#42365707)

so what you're saying is that programmers need to stop being such fucking wusses that they put up with shit working conditions like 15 hour work days?

or maybe they should form a union.

From the article (1)

phantomfive (622387) | about a year and a half ago | (#42364899)

Wow, check out this quote from the article:

in casual discussion, developers and tech managers will talk about all the wonderful things their system does, the stellar technical skills of their team, and how much their users love them — and all that may be true.

Do developers and tech managers really go around talking about how much their users love them? Why have I never met any of these developers and tech managers?

Re:From the article (4, Funny)

Samantha Wright (1324923) | about a year and a half ago | (#42364957)

The last page bashes Haskell using a snippet from Uncyclopedia as anecdotal evidence that it is "all but impossible to write readable code" in Haskell.

Beyond it is another dimension: a dimension of whinge, a dimension of fallacy, a dimension of diminished journalistic integrity. You're moving into a land of more shadow than substance, of vague and half-baked wit; you've just crossed over into the Register.

My life is hell (0)

Anonymous Coward | about a year and a half ago | (#42364901)

Picture this kids: Object-oriented jscript based Classic ASP website using a VB6 DLL querying a SQL server databse with stored procedures longer than 20,000 lines, very poorly commented and not documented at all. Plus there's hardcoded bullcrap in with all that code that should have been made database driven, functions that are redundant, variable declarations and comments in Indian (not English). And then there's enough views-upon-views-upon-views in the database to make your head spin and causing all the slowness in the world, client very angry because it takes so long to deconstruct and boil it all down to a single stored procedure so they can get some performance back.

DIE IN A FIRE WHOMEVER YOU ARE WHO WROTE THIS CRAP!!!

Re:My life is hell (1)

gagol (583737) | about a year and a half ago | (#42365625)

Crappy, hard to maintain code helps you stay employed...

Just like the movies (1)

overmoderated (2703703) | about a year and a half ago | (#42364929)

In the real world, there no chance that a single man takes out entire armies. There is also no chance that CSI detectives drive Hummers. Academic code is better, because the purpose is entirely different. Once you start coding for a company, you basically become a code monkey under strict financial and other constraints. It's slave labor.

Re:Just like the movies (0)

Anonymous Coward | about a year and a half ago | (#42365209)

It's slave labor.

Are you not being compensated?

Are you not permitted to find alternative employment?

Then it's not slave labor.

Period.

School != World (1)

fahrbot-bot (874524) | about a year and a half ago | (#42364977)

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.

Life is messy and the real world is complex; deal with it.

In Other News... (4, Insightful)

SirLurksAlot (1169039) | about a year and a half ago | (#42364981)

Water is wet, the sky is (perceived as) blue, the world *did not* end, etc.

On a more serious note I wouldn't describe any of the code examples I encountered in school as perfect or "well-thought-out" specimens." Nearly every one of them was a trivial case which ignored most error cases and expected the client human/system/software to be well-behaved. I've often thought that Comp. Sci. students (3rd or 4th year) should be forced to pick up someone else's code and refactor it into something workable. I'm not talking about the disgustingly huge and unmaintainable messes that we work with out in the real world, but something big enough to give them an inkling of the kind of scope they'll be expected to deal with.

I also think that if you're not learning TDD in school these days you're not getting your money's worth, and you'd actually be jeopardizing your career by not learning this early, as it is a life-saver out in the real world.

A soccer team analogy . . . (4, Insightful)

PolygamousRanchKid (1290638) | about a year and a half ago | (#42364983)

In the academic world, if you were tasked with picking a perfect team, you would steal players from Real Madrid, FC Barcelona, a fistful of Germans, Franck Ribery, etc.

In the real world, if you are tasked with managing a programming project, you don't get to pick the best. You are given some young kids with more energy than sense, an old, wise, but disgruntled experienced guy, who nobody listens to, a few folks who really don't give a damn, and most of them really truly detest each other. So you try to make out as well as you can, with what you've got.

Hey, Mercedes are great cars, why isn't every car built like them? Well, not everyone can afford a Mercedes, and maybe most folks can get by with just a Ford.

It's just the reality of life vs. theoretical academics. Despite the physics problems you solved in college, there are no frictionless surfaces. Or the ones that are available, you just can't afford.

Re:A soccer team analogy . . . (0)

Ryanrule (1657199) | about a year and a half ago | (#42365365)

Fords these days are better put together than MB's

Re:A soccer team analogy . . . (3, Informative)

LDAPMAN (930041) | about a year and a half ago | (#42365503)

Wrong. My Benz has 11 airbags. My Fordrd does not. My Benz has massive brakes that can bring me to a stop in 1/3 less distance. The list goes on and validates the previous posters point.

Yes. (0)

Anonymous Coward | about a year and a half ago | (#42364987)

When I first came out of university, I came in contact with a C++ code base consisting of ~100 000 files, with hundreds of developers working on the code.

There are files of 10 000 lines of code or more. There's code that used to be good, but got missed up by so many people doing small changes, slowly turning it to crap.
There's also the code that was always crap, and just became crap on top of more crap.

And every so often, you find a little jewel, and try to make sure it doesn't become crap.
Or you refactor some code in hope of making it somewhat decent.

But that's just a whole lot harder than what you read about it 'in theory'. In practice, you have to get your features done, and the time to improve code is limited. It's possible, but it's not easy. And some people simply don't care about quality or don't want to spend any time on it, that doesn't exactly help.

Skimmed article - more than it deserves. (1)

Anonymous Coward | about a year and a half ago | (#42364989)

Everyone is a moron who doesn't code to the style they were taught.

I was taught at Yale that a programming language was just syntax - algorithms are what's important. All this horseshit about the right tool for the job was just that - horseshit.

I've personally witnessed some awesome code written by so called "morons" and some shitty code written by "geniuses".

What's the difference? people skills.

That's right asshole, programmers are just as gullible to smooth talkers as people to politicians.

Now, go back to your bitching about nonsense.

most claiming crap code (3, Insightful)

codepunk (167897) | about a year and a half ago | (#42365011)

Most of the time the person claiming the code is crap is the one I find to be most to blame.

Re:most claiming crap code (0)

Anonymous Coward | about a year and a half ago | (#42365643)

Because they just took over spaghetti code they won't touch with a pitchfork?

Good. They probably saved your company alot of errors and customer grievances.

other way around? (2, Interesting)

Anonymous Coward | about a year and a half ago | (#42365043)

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

Wrong Comparison (1)

bossk538 (1682744) | about a year and a half ago | (#42365061)

Wrong comparison. Most programmers don't write for textbooks, and those that do I would think are exceptionally good coders. A more apt comparison would be between the code written for CS students for academic projects and that written by working professionals in the field.

Academic (1)

zieroh (307208) | about a year and a half ago | (#42365063)

Personally, I find academic code -- that found in textbooks and other teaching materials -- to be poor specimens. These are examples that teach methods and concepts, but utterly fail to account for edge cases and real-world scenarios. Real-world code may not always be pretty, but it is a lot more comprehensive than what you will find in textbooks.

The author of the TFA is, IMHO, misguided.

Re:Academic (2)

DragonWriter (970822) | about a year and a half ago | (#42365607)

Personally, I find academic code -- that found in textbooks and other teaching materials -- to be poor specimens. These are examples that teach methods and concepts, but utterly fail to account for edge cases and real-world scenarios. Real-world code may not always be pretty, but it is a lot more comprehensive than what you will find in textbooks.

IME, the exact opposite is true; code in textbooks is far more often to address a specifically defined problem domain correctly (often, a problem defined in such a way that edge cases which might be important in a "real world" program are outside of the problem domain, but nevertheless the specified domain is correctly addressed -- the exception being code in textbooks that exists specifically to support exercises which address identifying and addressing edge cases that are within the problem domain), whereas with real world code it is often the case that the problem domain is -- even if you are lucky enough to have design documentation accompanying the code -- poorly specified, and quite often the code is not correct for the problem domain and fails to account for edge-cases and real-world scenarios that occur both in the defined problem domain (to the extent that such a thing exists) and the actual domain in which the program is applied.

Though its true that the real world code is often more "comprehensive", if by that you mean the opposite of "concise" rather than the opposite of "incomplete".

Never met anyone who learned to code in school (0)

Anonymous Coward | about a year and a half ago | (#42365067)

You go there only to get the paper.

and in IT / admin jobs CS is way off base to the p (1)

Joe_Dragon (2206452) | about a year and a half ago | (#42365117)

and in IT / admin jobs CS is way off base to the point where a tech school is like a real workplace (IT setup wise) and in a tech school you learn very hands on VS the theory of it all.

Extra word in the headline (0)

Anonymous Coward | about a year and a half ago | (#42365125)

You could leave out "Code" and it would still be true. We live in an imperfect sublunary realm, not the eternally ideal empyrean.

We hire only the best (0)

Anonymous Coward | about a year and a half ago | (#42365127)

Every company I've interviewed at, and by extension, every company I've ever worked for (a subset), told me that their software devs were the best and the brightest. Top notch people, all of them.

And then I got there and dived into the code. Well, it's never been all bad,

And then my captcha for posting this is trough, as in pig trough. How'd they know. ;-)

Obvious Observation, Misleading Conclusions. (5, Informative)

VortexCortex (1117377) | about a year and a half ago | (#42365139)

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.

Re:Obvious Observation, Misleading Conclusions. (1)

PRMan (959735) | about a year and a half ago | (#42365435)

You make a good point about greed, but I think it's "e. all of the above."

I have seen developers that were so bad they couldn't write anything good if they tried. Managers typically don't know enough or don't have time to do anything about it. Besides, they are already trying to add 2 more people. If they fire that guy, they have to add 3.

The worst failures we have at my current company (which hires very well) are problems caused by too smart developers being too clever, creating code that is unmanageable for anyone with less than 140 IQ and stellar recall skills, which less than 10% of programmers have. And we have some very poor beginner developers that can write working, easily-readable, easily-maintainable code. I'll take that any day.

There are developers that never get around to anything and then rush at the last minute. That's largely gone away now due to Agile. But laziness is typically good as lazy developers tend to use libraries and write as little as possible, leading to the less bugs, more readable code, etc.

And the final reason is everything is cheaped out and rushed.

Re:Obvious Observation, Misleading Conclusions. (0)

Anonymous Coward | about a year and a half ago | (#42365667)

+1

Managerial problem (0)

Anonymous Coward | about a year and a half ago | (#42365175)

Do you promote writing 5,000 lines of spaghetti code that 95% of the mortal coders can relate to and maintain? Or do you thank your guru for writing 500 lines of crisp, clean code that nobody will be able to maintain when the guru quits?

The crisp, clean implementation has fewer if statements because the corner cases are covered by the well chosen constructs. The clean methods have a simple loop in the middle and 25 lines of code. Methods of ordinary coders have 150 lines of meandering code with confused and misleading comments that apparently made sense to somebody at one time.

However, that meandering corresponds more closely to the thought processes of the mortal coder and the superfluous if statements give them a better conviction that all corner cases are covered. In reality, the clean method covers them all and the meandering code ignores a few crucial special cases, but the mortal maintainer of the code will see just the opposite.

How to make real code that is good (2)

Brett Buck (811747) | about a year and a half ago | (#42365185)

The article appears to mostly be self-indulgent/elitist crap, but there is a kernel of reality in it.

      What some of my colleagues and I have done to avoid the "obscure features" problem of "expert coders" is to ban their use. A particular language we use permits many fairly obscure features that lend themselves to writing mystery code. We simply don't use them unless absolutely necessary. This is embedded spacecraft code, we only need basic relational statements, math functions, and minimal pointer use. So we don't use some of the more obscure features (doubly-defining tables, unnecessarily complex data structures, the more bizarre capabilities of pointers, etc). The code is still maintainable 30 years later, people can pick it up and read it from cold, and modify it with ease and safety.

Between This and the Last Story (0)

Anonymous Coward | about a year and a half ago | (#42365193)

I'd say the front page is a direct result of how vacation days increase with the amount of time someone has been at a company. The last two stories were clearly written by recent college grads, because anyone with more than eight months of experience knows that code standards are important and not all of your coworkers write the best code. I just assume they made the front page because all of the folks with experience have today off and weren't around to submit better stories.

Not me, though. I hate Christmas.

communicating well is hard (3, Insightful)

binarstu (720435) | about a year and a half ago | (#42365199)

From TFA: "Good software, misleadingly, is usually easy to read, but it’s not easy to write."

What is misleading about that? The same could be said for any of the formal mechanisms we've invented for expressing our thoughts and ideas to other humans. Good oratories, good lectures, good books, good journal articles, and so on, are all easy to consume, but speaking or writing well requires tremendous effort and practice.

Re:communicating well is hard (0)

Anonymous Coward | about a year and a half ago | (#42365273)

The statement isn't even true. I stepped through a linked list using a double pointer and I had to explain to someone on code review what I was doing, line by line.

Amount of code (1)

shdowhawk (940841) | about a year and a half ago | (#42365235)

I don't think i've seen school code that ever made it past 1,000-2,000 lines of code

My last few projects were in the 100,000+ lines of code range (multiple employees)

Regardless of school code being good or bad, it's easy to write good code when you have clear business rules for needs to get done and you only have to write something small

Just like the Boy in the Bubble (3, Interesting)

Dave Emami (237460) | about a year and a half ago | (#42365241)

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:Just like the Boy in the Bubble (1)

bio_end_io_t (2771123) | about a year and a half ago | (#42365419)

Right on. Schools do a horrible job of teaching how to code. Too much theory; not enough memory alignment or thinking about cache boundaries. Not enough about error checking or the graceful handling of errors. But hey! They teach Chomsky Normal form!

Re:Just like the Boy in the Bubble (0)

Anonymous Coward | about a year and a half ago | (#42365699)

School is about memorization and regurgitating crammed texts.
You can automate the process and optimize exam results using computer technology.
Thus, modern schools are redundant.
It'd even be a fun exercise! ;-)

Do you want to be a machine, or human? If you wanna be a machine, you're already outsourced.

Perfect is the enemy of good (1)

gestalt_n_pepper (991155) | about a year and a half ago | (#42365277)

Ideally, we'd all sit in a room and model our system, identify the classes, define all the member functions, embed all the unit tests, error conditions and comments first, and then as an afterthought, fill in the code.

The requirements of the real world, of course, make this impossible. The real world says, "get it out on time and good enough to make money."

when you devise the problem and solution... (0)

Anonymous Coward | about a year and a half ago | (#42365317)

I'd like to see a textbook case of converting a legacy spreadsheet codebase to support an email client, or some other such nonsense.. I'd be a whole lot more interesting than another freaking Fibonacci sequence generator. If you control the problem and the solution, of course it's a cakewalk.

The Author Clearly Never Had A Job As A Programmer (1)

assertation (1255714) | about a year and a half ago | (#42365357)

The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen

The person who wrote that clearly never had a job as a programmer.

These days, you can't even count on code from computer books compiling, let alone being exemplars of good code.

Best code I've seen ... (1)

PPH (736903) | about a year and a half ago | (#42365383)

... was written by the groups that used it.

Management gave us (Engineering) a task to complete. Either do it by hand or automate it. They didn't care. Just get it done right, on time and for a reasonable budget.

The code started to get shitty when the computing group found us writing our own tools and took the task away. The code stank, but it was blamed on poorly defined requirements (which they collected). The s/w folks didn't have any responsibility for actually performing our work and missing schedule was our problem, not theirs. As long as we waited patiently in line for their change process, they didn't get dinged for delays. And to top it all off, when they took over our apps (NLP of engineering requirements documents to produce executable code), they just started pulling claims of NP-hard out of their backsides as to why they were getting into trouble. We (Engineering) would never have dreamed of lobbying management for the responsibility for a task and then turned around and claimed we didn't understand how to do it.

You think that's bad (4, Insightful)

HangingChad (677530) | about a year and a half ago | (#42365397)

Obviously the author has never tried to untangle outsource code. If he thinks home grown code is bad, wait until he wades through a bowl of Bangalore spaghetti code. Yummy.

Although I did make a lot of money sorting through that crap. Many companies would just assume outsource code would work when they needed it and couldn't figure out how come their wonder app, that they got done for half of what U.S. programmers would have cost, kept crashing.

It's all relative (2)

davidbrit2 (775091) | about a year and a half ago | (#42365415)

This is why I use Access a lot. Compared to the awful ERP and operational software that's out there, the little things I throw together look perfectly fine. And if I can go from concept to deployed application in an afternoon, then that's less cost to the business. We had an old RMA tracking application written in VB6, that had the database server name hard-coded. I spent a couple of hours with Access, totally rewrote it, and actually made it better. I certainly wouldn't write an entire accounting system in Access (probably), but in a world of software written with necessary business constraints and compromises in mind, do as the Romans do.

Haskel bashing (0)

Anonymous Coward | about a year and a half ago | (#42365433)

I am working with Haskell for a long time and don't understand the Haskell bashing in that article. Hard to understand code samples can be created in any language and give zero insight into how working with that language is like. I think the guy just wanted to post an unqualified rant and does not deserve the Slashdot attention he got.

TL;DR: That article is pretty ignorant.

Academia is not the real world (1)

Anonymous Coward | about a year and a half ago | (#42365633)

I bet most academics who preach about how to write good code have never worked in the real world or written a program more than 10k long

Academic Code Blows (1)

Anonymous Coward | about a year and a half ago | (#42365639)

Most programmers I've known that spent their life in academia write crap. I've seen very well engineered software "in the wild" by seasoned experts (i.e. +10,000 hrs of real world coding). Also, most academics or new grads have little to no experience with Software Engineering practices such as Agile, Scrum, TDD, etc. Not saying that any one of these automatically makes you better. But unless you written unit tests (many of them), you have no idea how to do it. Alot of academics will "analyze" their code, and let the compiler have a go at it. If their "analysis" and the compiler think its okay, then its okay. I always say "1 test is worth 1000 expert opinions". That is why I test my code, and why I've learned so much by testing my code.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>