Real World Code Sucks 292
An anonymous reader tips an article at El Reg about the disparity between the code you learn at school and the code you see at work. Quoting:
"There is a kind of cognitive dissonance in most people who've moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is, and this is rarely acknowledged. To be precise: a tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it's outright terrible by any number of measures."
Captain Obvious? (Score:5, Insightful)
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
same... (Score:3, Insightful)
It's no different than business school examples vs real world practice.
School code (Score:5, Insightful)
The goal of textbook code is to be readable, to communicate, not to handle every possible case. This means industry code is often less readable, but more solid. I'm sure I've missed other ways academic code is bad.
Of course a lot of industry code is unreadable and also not solid. That's another issue.
No surprises here. (Score:5, Insightful)
- specs change constantly
- need to work with crap that's already there
- there are deadlines
- need to get stuff done
And I'm pretty sure I'm forgetting some other points.
School v. Reality (Score:5, Insightful)
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.
In Other News... (Score:5, Insightful)
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 . . . (Score:5, Insightful)
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.
most claiming crap code (Score:4, Insightful)
Most of the time the person claiming the code is crap is the one I find to be most to blame.
Re:No surprises here. (Score:4, Insightful)
- 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:School v. Reality (Score:4, Insightful)
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).
Re:must read: "worse is better" (Score:4, Insightful)
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:School code (Score:5, Insightful)
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.
communicating well is hard (Score:4, Insightful)
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:Captain Obvious? (Score:5, Insightful)
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? (Score:5, Insightful)
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:School code (Score:4, Insightful)
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.
You think that's bad (Score:5, Insightful)
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.
Re:must read: "worse is better" (Score:5, Insightful)
"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" (Score:5, Insightful)
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" (Score:4, Insightful)
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?
Re:must read: "worse is better" (Score:5, Insightful)
Re:School v. Reality (Score:5, Insightful)
You're working with the wrong programmers then.
Yes, because it's always possible to work with the best programmers the world can provide. In the *real* world there is a finite availability of top programmers, and they might not be working where you are.
You show yourself to be very naive if you think that every business has the time to let you do TDD, and will provide you with a perfect, experienced team of developers.
Re:must read: "worse is better" (Score:5, Insightful)
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 [ariel.com.au] ;)
Re:Captain Obvious? (Score:5, Insightful)
That implies that all of those people care to spend the time meeting - and they often don't - and also know or are willing to listen to a detailed explanation of what is involved - and they aren't or are not capable of it. Everyone knows the problems, no one admits to their part of the problem.
Also management tends towards Seagull management - arrive suddenly, shit all over everything until everyone is worked up, then leave. Rinse, repeat until the project is done or cancelled.
Honestly I have been through this sort of cycle a few times, and despite the best efforts of the developer side to get management to agree to the design document as defined, the end result is featuritis, people sticking their nose in who shouldn't be able to but who are higher up in the food chain than you (or anyone else in development) is etc.
Half of the art of software design is dealing with people who don't understand it, or care to learn.
the best companies have both (Score:4, Insightful)
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.