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"
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
http://xkcd.com/844/
---
It's no different than business school examples vs real world practice.
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.)
It's "rarely acknowledged" because it's just a given...
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.
"First they came for the slanderers and i said nothing."
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.
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.
#fuckbeta #iamslashdot #dicemustdie
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.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
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.
God, schmod. I want my monkey man!
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.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
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.
Most of the time the person claiming the code is crap is the one I find to be most to blame.
Got Code?
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.)
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.
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.
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.
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."
The Atlantic: Bad software runs the World
This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
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.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
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.
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!
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".
I've always held that 90% of anything is bad with respect to books, movies, music etc. After 10 years, the good authors tend to stand out.
Ah, Slashdot... where a post about the importance of "people skills" can't go for more than a sentence without calling someone a "moron" or an "asshole".
I get the feeling that Anonymous Coward was actually this guy.
I don't care if it's 90,000 hectares. That lake was not my doing.
Code is bad because of deadlines, everyone seems to agree.
Bad is relative though. If the software satisfies its business case, and ultimately doesn't have unmanageable maintenance costs associated with it, it's basically good regardless of its failure to meet standards of elegance and clarity.
People write good real-world code all the time, and most of it is open-source. You can attribute bad industry code to greed, and that's valid, but it doesn't necessarily imply that the result is bad. Greed isn't going anywhere and greed builds some useful stuff amidst all the messes it creates.
Even in the projects where time is not a constraint, growing complexity often leads to programmers making design compromises. These aren't necessarily as heinous as what you find in profit-driven code, but they exist because software is hard to get right when the problem being solved (i.e., the set of requirements) is almost always a moving target.
There is always a compromise between toiling endlessly in the realm of over-engineering, or shipping a release some time in the next century.
When I first graduated college and got a programming job, I thought the code was a bit shit too. Then I learned about deadlines and most importantly Bit Rot. I soon realized that you need both strokers and crankers to make a successful company (I like bowling terms).
Crankers bang out code like there is no tomorrow. When good managers find these people, they immediately put them in the department of developing new features. Competition is fierce, and a lot of times it doesn't matter about quality but about who gets there first. End of story.
Strokers take their time with code. They are fit for the "support queue," debugging, and any specific jobs that require needlework precision. I work in this department. I fix a lot of code made by Crankers, taking in both memory-efficiency and speed-efficiency. So when a customer finally does have 10,000 loads which the Cranker didn't foresee in his/her code, I fix it, and the customer is happy. I also provide a lot of options to the user instead of forcing the user down one path. Lastly, I do jobs that require excellent quality. Do not give money-critical new features to Crankers; give them to Strokers. I actually have used a lot of the the computer sciencey things that I learned in college like Big O, various Dijkstra algorithms, etc.
Tweeners are the in-betweens. They are good for the basic infrastructure/architecture. They write the base library fast and with decent enough quality. For example, they may write layers around the database, GUI, etc. to make life easier. If you don't have a Tweener, then use a Stroker. If you need the product out fast though, use a Cranker and then a Stroker later on to refactor, or use a Cranker and Stroker in unison.
To make a killer software company, you need all three. And the companies that last a long time, have managers that know how and where to place these people.
The G
Call me crazy, but i think we spend too much time on complex OOP based code. No I'm not making this up, I might know more languages than you, but I've also had the unfortunate opportunity of working on more shit code than most people. We need to go back to basics. When a company can hire a 3rd party team to write a 3rd party CRM cheaper than it is to modify an internal CRM there is a problem. Pay attention to this next part: When a class library becomes so complex it takes more time to maintain the library than to write new functionality, you have a problem. It should be easy to understand a code-base without spending days learning an API. code needs to be more adaptable to chancing situations. When a pharma company can spend $600,000 per year to maintain a 3rd party CRM because a first party CRM costs millions to mod, there is a problem. Just my observation though. *glares at top 20 pharma companies* thx for the awesome paycheck.
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.
Crappy, hard to maintain code helps you stay employed
How would you feel if the people that made your car shared that sentiment? It's attitudes like that that give the profession a bad name. Take some pride in your work and don't be the guy that's cursed by everyone who comes after you.