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."
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
It's no different than business school examples vs real world practice.
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
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!
Most of the time the person claiming the code is crap is the one I find to be most to blame.
Got Code?
It might be interesting to read The Rise of "Worse is Better"
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.
-1, Too Many Layers Of Abstraction
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.
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
"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.
People in cars cause accidents....accidents in cars cause people
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.
Sig Battery depleted. Reverting to safe mode.
It's not even that. These academic examples are small and trivial. They don't have to adapt or integrate with other systems. They are toy examples and it's really damn easy to make those 'perfect.' How many god damn quick sort examples in Haskell convert to anything in the really real world?
To be honest more often than not poor code will just be about getting something out there with the minimum work, rather than because of deadlines. The code is usually boring, and/or it's already poor, so few will come along and sort it out to make things easier down the line (especially when even the best rewrites are usually more risky than a minor hack to a hacked up system, in the short term).
// MD_Update(&m,buf,j);
True but I haven't seen much academic example code that has plenty of logging in them.
In the real world much good code is filled with exception handling and logs. Because for almost anything that you try or call something wrong/else could happen or something could send you a SIGTERM or similar. You'd leave out the logging in the high performance processing loops, but in the real world those often are only a very small part of the code.
So it's not just most real world code that sucks in the real world, most academic style code would also suck too. ;)
Yes there are different logging systems, but you can pick one or two as examples - after all there are also many computer programming languages and most academic courses still teach at least one programming language.
Anyway the story also reminds me of: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html ;)
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