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...
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.
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.
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."
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.
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
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?
"First they came for the slanderers and i said nothing."
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!!!
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.
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.
It must have been something you assimilated. . . .
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!
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.
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.
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.)
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.
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.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
You go there only to get the paper.
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.
You could leave out "Code" and it would still be true. We live in an imperfect sublunary realm, not the eternally ideal empyrean.
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. ;-)
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.
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.
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.
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.
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.
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."
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
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."
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."
Please do not read this sig. Thank you.
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 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.
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.
Have gnu, will travel.
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.
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.
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
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.
I woked as a texg writer at a large company that I won't name. The group I was in developed test tools for internal use company use, nothing that got shipped to clients. They had 600,000-odd lines of C code in the tool set. One day I did some grepping through it. I cannot recall everything I checked, but all my results were awful. Things I do recall: A couple of thousand uses of functions that could fail like fopen() or malloc() without the idiom (fp = fopen(...)) != NULL or the same with ==. I checked a few manually, and none had any other error checks. Only about 5% of switch() statements had a default case. There were under 10 uses of the assert() macro in the whole set, all in one guy's code.
In the real world the goal is good enough; not perfect. The definition for good enough comes from the customer; not necessarily the end customer, but like Dell for computer components. Is it any wonder that less time is spent cleaning up the code after it is proven to work? Also in the real world the code will be worked on for years with bug fixes and enhancements (an old patched up house isn't is pretty as a brand new house). I see no surprises here.
It's not that real world code in particular sucks. The world sucks. The code is in it. If nature provided practically unlimited general computing power really easily, code would be frickin beautiful. Computing power is woefully constrained, so code, the tools the process it, and the systems that execute it are woefully constrained. So, bad code becomes easy to write.
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.
Do you cook by following a fancy french cookbook line by line? Do you drive like on DMV test? Then why do you expect anyone to code by textbook?
Real world code is great because it works, solve a problem and puts food on the table of company's employees. If it becomes so successful that the problems are noticeable, then there is enough funding to write version 2.0. But in the beginning its more important for the product to be out of the door as soon as possible.
Real world code is written by all sort of people with all sort of background. A majority of code is from folks that has no computer science background. In my case, majority of code is from physics/math majors with experience writing Matlab.
ask the math folks how to write a double array vs array of pointers
So, "real world" code isn't clean and elegant. So what? Get over it. In case you haven't noticed it, most of us out here don't look like high school or college athletes, either. Life is a compromise between avoiding problems and getting things done. Look at the problem you've been dealt, do the best you can with it, and go on to the nest one.
Management has dictatorial powers and they hide behind your bullshit argument to cover their asses when shit hits fan.
Unit tests allow you to refactor without fear.
BLASPHEMY.
At least from the point of view of the executive manglement team.
The last time I saw a mid level manager require written documentation from more than one stakeholder (marketing, business analysts, etc.) at a time, he was FIRED, for "being inflexible". This after he offered *many times* to help shepherd the process including discussing the effort of various options that might be chosen for implementing the ideas under discussion. Also after >3 years of trying to implement under-specified, over-promised features whose priority was always greater than refactoring and cleanup as the application experienced shifts in functional emphasis to match changing market conditions.
I've been doing this stuff since 1977 and the most consistent statement that could be made about top management people was "he or she has never felt the pain of an ink pen in hand". Fear of commitment. Frequently we who had to keep things going just did as much work as possible, hoping for the best. Unfortunately, even with the willingness to get into the work, our vision was necessarily limited, and consequently so was our success rate.
Beyond a certain point, high level managers become extremely risk-averse. It's explainable: The challenges of getting details right are many, and the likelihood of success is small due to the vicissitudes of most business marketplaces. I believe this is why there's lots of talk about "taking risks" but truth be told, risk taking is such a fear-inducing process that it's never used.
With that complaint out of the way, I agree with your premise. I merely observe that I've seen it carried through about once or twice in 35 years.
The one other major contributor to "maintenance hell" that I've seen is fad-based programming. At some point, someone comes up with the idea that new technology X is the bee's knees, and starts to apply it extensively in the code-base (without having any significant prior experience in it). This doesn't work so well, and it winds up being dead weight rather than beneficial. This may be because X was just hype, or because the programmer really didn't know how to use X properly (and your damn production code was the WRONG place to conduct your learning experience).
I prefer this one:
http://www.osnews.com/story/19266/WTFs_m
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.
yeah, right
welcome to the real world, where screws don't fit, the parts are poorly designed, etc etc
what on earth gives you programmers the arrogance to think that you are any different then anyone else ?
you really think great design and engineering are found outside of coding ?
get real - sturgeons rule applys equally to everyone and everything
a few years ago, Boeing had the smart idea of asking the ground crew what they wanted in a new plane.
The guys at O'hare in chicago said, you know, it would be nice if we could open the fuel tank without having to take off our gloves....
Most code I've seen in textbooks is written assuming that everything will work (very little error handling) and that the code will be used by people who know how to use software and can accept garbage-in/garbage out. Most of those examples wouldn't make it into a real product.
Of course, I admit that a lot of the code I work with is a mess. It would be great if we could afford to fix it, but if it works it's hard to get management to spend the effort.
So it is hacked, poorly designed, and gets more fragile with each fix/change. Experience coders know: You may not have time to do it right, but you'll have time to do it again. I was surprised to see all the comments justifying crappy code.
Having owned and programmed my own software company for twenty years now, absolutely real-world code is crap. It's horrible. At least 30% of my code is detrimental to my business, and at least 50% is just plain embarassing. But that's never been the point. If the point were to write good code, I'd need another source of income.
I work for small and medium businesses. And each and every client couldn't care less about the code. They ask the same questions: "will the bad code still work?" and "will you be there to fix the problems when it doesn't?". Since the answer to each is "yes, absolutely", the bad code would be a waste of time to write better. Every client will choose more bad code over less good code every time.
And it makes sense. Another feature is something a business can flex. Better code isn't.
So much of my code is ugly, some holds together well but just barely, and some requires my personal input or maintenance on a routine basis. But my clients don't care what work the code does and what work I do. It's all the same to their bottom-line.
As for the article's last comment that comments improve things, that's absolutely incorrect. Bad code may be bad, but with enough time and focus anyone who knows the language can figure out what the code does. Bad comments, on the other hand, are a con job. And since comments become stale as code grows and changes, comments are terrible things.
So instead, I format my bad code in a very legible manner. It may be bad, it may be slow, and it may be weird, but read it enough times and you'll know what it's doing. There are no comments to confuse you.
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.
Usually when I am coding something I have some task that needs to be done. Often it's something that is thrown together using CPAN modules, but the end result is something that gets the job done. Could it have been done better or more efficient in another language or by a better programmer? Probably. But honestly for most tasks today computing power isn't a problem or near the expense time is. I'm still surprised at the fact that some of our core scripts and programs we use are things I put together years ago in as little as an afternoon. But they ain't broke so no one bother to "fix it".
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
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.
"I would rather play Chiquita Banana and have my swimming pool than play Bach and starve." - Xavier Cugat
PS
I resent Hunger Games being associated with Twilight, much deeper despite some surface similarities
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
After 20+ years of programming professionally, I've learned that even if I can get all my code into a good framework and documented and tested and 90% or so ship-shape, someone in the company will think of some new requirement that creates a whole new series of knots in my software. A sales guy just has to have some special terms for this quarter's "hot" customer, or a new product we sell has an accounting code convention that doesn't fit with the rest of the system, or marketing wants to combine products into some hitherto-unforseen chimera of a product. It just never ends.
I joking call it "Domain Specific Knowledge", but it is the ever-changing petty demands of actual people and business conditions that constantly thwart our attempts to structure our world using logic.
Bad code is the result of bad programmers. End of story. If you blame management for your bad code, it's because you suck. A real professional is able to work with people who are not in their field in order to create something that is useful to those people.
Me and my team has been TOLD to lower our quality on a couple of occasions. Because it is not good business to raise customers expectations and standards. It makes it harder to sell low quality stuff. I get that completely and have no problem with it.
A lot of the software that is produced in academia is horrible. No meaningful error messages, strange behaviour in corner cases, incomplete and sometimes inconsistent documentation (if there's any documentation except for a few incomprehensible examples). And that's only the user's perspective. If you look at the source code (provided that it was released at all) you can be in for a few surprises as well. Software development is never perfect and people in academia who should know better often make the most blatant mistakes.
so why isn't the the code coming from them perfect?
I suppose you guys have never seen real world PLC code. Code that runs on Programmable logic controller.
It is simply unbelievable how bad software can be written. Sometimes I'm really astonished, why not about 80% of all the factories worldwide just blow up given the crappy PLC code on their manufacturing machines.
Code reviews. Seriously. We use Atlassian Fisheye, and it's a great tool for this. Code reviews mean you have more people who will know what you wrote and how you wrote it. Your code might help them be better programmers; their comments might help you be a better programmer.
Oh, and unit-test everything. Writing unit tests will also force you to write better code (smaller functions, more tightly defined, fewer code paths), because it's a pain to write a good unit test for poorly-written code.
Different people create things that they think constitute "good" code, and to that person it makes perfect sense. But to another person that's an unmaintainable mess or unclear. Fortunately code reviews can help this situation. But sometimes a developer could have spent a lot of work re factoring (really re-designing) parts of a system, and by the time the code review comes, you can spend some time helping make it a little clear, but if the whole design is unclear often you are stuck with it and things go live.
The way much code ends up more readable is by introducing abstractions, but if those abstractions only make sense to one developer (or a group of developers who are all best buds) then they don't really help and can make things more complicated.
In reality some people say 500 line methods are unclear, and often they are. But if the object oriented alternative has really shoddy naming, and people were unreasonable so multiple class hierarchies are involved, each one throwing code in constructors, and multiple methods which often have side effects in multiple objects...that 500 line "bad code" starts looking pretty good to the alternatives. But to the developer who wrote the object oriented solution, his code is good and the 500 line method was a monstrosity.
Sometimes even the same developer changes his/her mind about code being good/bad. Six months ago, it was good, now it sucks....
And there also seems to be no universal agreement. At work they have coding standards, but they are constantly changing. Heck for a while design patterns were considered the stuff.....use them wherever you can. Then design patterns were too complicated....use them sparingly. The definition of good vs unmaintainable mess is constantly changing.
So due to this whole "good" vs "bad" being not universal and the definition of "good" changing over time...it is hard to justify taking the time to do something "right" when often you end up with the same unmaintainable mess. In fact over 4 jobs (about to start number 5) I have not met code that I think is a pleasure to work with or is GREAT. I definitely think some was better than other code, but even that wasn't great. And when I look back at code I did, often I am not thrilled and think I could do better. But the reality is that at the time of designing the system, there was no way to anticipate when things changed, and the deadlines were pretty arbitrary/tight. If someone says you have 1 day to get this web page done....I would start writing inline HTML/Database queries to crank something out probably in 1.5-2 days (and possibly try to convince someone to let me write it in Perl for a 1 day special).
this is a generalized academia versus the real world diatribe. In effect what they don't teach in academia is that software is not done in a "lab" where each person's skillset is on par with each other. A real world project is decomposed into a tremendously vast amount of work tasks that need to be choreographed to manage resource availability , resource skillset, organizational dynamics , organizational politics, competency of management, and elasticity to scope creep. Let's also add in that the resources may be in different countries. So add into that the cultural differences, managing two sets of holidays, language differences, time delay's, that they may not have the availability to get their questions answered or understand the requirements thoroughly due to the availability of the SME's and the time differences...
I work for a well funded company and I am a manager of development projects. You have an organic team and can't expect that each person is interchangeable. In addition, we all at times function above and below our abilities due to external distractions and pressures. The same thing happens in sports. Just because you are the top of your game, you will have off days or off weeks. In addition to the project you have the long term picture of trying to grow the resources you have. If you can afford to do so, you try and grow the junior resources to handle the harder challenges. In doing so, you expect the code quality to be less than what is done in capable hands.
And management isn't prone to having off days or also being grown to a higher level of competency. It's a generalization to think that all software managers are idiots and that if it was just code and people coding the world would be a great place. What is often forgot is that the code is part of a larger ecosystem full of users, other systems, changing requirements and business processes and politics.
How Professors Program:
Show up at "work" at 9 or 10.
Have coffee and pastries at a faculty meeting.
Sit down at desk and code for several hours.
Break for lunch, office hours, check out the hot coeds (maybe even do one...who knows)
Back to programming until 4.
Leave for the day.
Repeat, except for all Federal, State, and Local Holidays.
Get the book published
Require ALL the incoming students but it at $89.95
How a Real World Developer Programmer:
Show up at work at 7.
Consume a breakfast taco with bad coffee at your desk while reading emails sent by managers last night at 10PM
Prepare your Status report, listing changes that occurred since you last status report...last night at 6.
Attend the morning status meeting
Go to meeting with users to get vital information so you can move forward. Except they cancel.
Sit down to code.
Answer call from user wondering "where we are at".
Code some more.
Reboot your computer
Answer call from help desk. The CSC controlled Virus scanner has kicked off at 10 AM instead of 10PM and is killing the server....find and Pause it.
Code some more
Meeting with supervisor, recapping everything you recapped yesterday.
Code some more
Reboot your computer
Lunch. Surf the web while eating instant noodles.Half the sites blocked by CSC.
Post on Slashdot, see your Karma destroyed when you post that has been no Warming for the Last 16 years.
Talk about the Hot blonde down stairs and how she has a nice ass.
Code some more.
Help Desk call about the server running out of disk space because some idiot "Power user" is using a temp table to do a million line query of some kind, for some reason.
Compact the TempDB, nicely tell the "power user" to use real tables (which are on the SAN drive.)
Reboot computer
Code some more.
Going away party for yet another person being laid off. At least this time they weren't secretly escorted from the building.
Leave the premises, drive to Quickie Mart to pick up a Monster drink and donuts. Say hello to Apoo.
Code some more.
Try to move test app to the test system. CSC blocks you due to some new restrictions.
Track down supervisor (who is in his own personal Hell) to make the move for you.
Meet with users to show the latest version of the app.
Users add 53 new requirements and tells you that most of what you've done is not needed anymore due to process changes.
Deliberately walk back to your desk via the aisle the Hot Blonde works in. She's not there,
Reboot computer.
Start working on new Status Report
Help Desk call...ID10T issue.
Finish Report, email it.
Leave for the day.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Until about 2004, we were able to refactor and improve the quality of code.
Now, those changes must be approved by management. And management never approves refactoring changes and always approves adding new features.
It used to be easy to improve code... now it's almost impossible in any sox controlled environment.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Crappy code is caused only by crappy programmers in the first place. Make excuses about spec changes all you want, but a good programmer will adapt, or has already forseen this, and still writes good code.
Nicely said. It's true that code shares characteristics of the world at large because it exists to model that world.
Though I can't verify your premise that the world sucks, I can still enjoy it as rhetoric. Certainly the world is complex, and so our efforts to reduce that complexity to something more tractable will meet with varying success. Here are a couple of examples that go against the claims in TFA:
If nature provided practically unlimited general computing power really easily, code would be frickin beautiful.
Ah, but it does. What is DNA if not code for operating a certain broad class of 3D printers? But as to whether the code is beautiful, who can say? We can only observe that it produces functional results for the most part. The very fact of its existence in such compact and enduring complexity is a sort of beauty, but is the code itself elegant, efficient, pretty, readable?
We know that most of the gene in a given strand of DNA are turned off. Does that mean that the code is inefficient, or are these sequences like the methods of an enormous class library, written by the brutal evolutionary hand of trial and error, now dormant but having the potential to be activated should appropriate conditions develop? Sure, we don't need gills today, but sea levels are rising.
Parity: What to do when the weekend comes.
I am in general agreement that most code out in the "wild" is terrible. However, this assessment may be due to the proposition that very programmer thinks that every other programmer's code is a piece of sh*t.
The worst code I see is from the f'ng contractors who put out crappy code that they never have to look at again. They produce code I would be ashamed of. Too many programmers put out shitty code just because they can. I've been coding for 35 years and I've seen more than my share of crappy code. As eWalz above says, when the existing code takes days to interpret, it becomes unusable.
My solution is to rewrite every bit of crappy code I come across. Yep, I take my chances that I will screw up systems from coast to coast. After I've figured out what the code does, I rewrite it to do the same thing 50 times more efficiently. Once I've tested it, and the users have tested it, I'm pretty confident that it right. The benefits are immeasurable. Now I know that code from the inside out, every single line. If a problem comes up, I have a pretty good idea what happened before II even look at the code.
If my rewrite doesn't work as it should well, I was looking for a job when I found this one. Fortunately,up to this point it's only gotten me a reputation as an excellent programmer.
Working but fragile code delivered today is more valuable than working and maintainable code delivered tomorrow. This is true even though we all know that maintainable code costs less in the long run--that's what the software engineering books say, and they make a solid case. It's true because if the sales don't start coming in as soon as possible there may not be a long run for maintenance. It's hard for me to day this and hopefully without being too discouraging, but the extra time it takes to write maintainable code (not gold-plated code) is, all too often, not rewarded. I say that as a programmer/software engineer/developer/what-have-you for thirty years. I've seen some aggressively stupid code in production. Once, I had to debug a particular function that was ginormous. Thirty-three printed pages long. Hundreds-upon-hundreds of lines of C++. One big honking loop. Written by my manager, who got promoted because he wrote it, it worked (mostly, amazingly), and it was on-time (or close). Apparently, he missed the lecture on stepwise refinement and functional decomposition. When a bug was found, of course, I had to struggle through to find the error. The time it took to understand the code was not appreciated. (Refactoring? Bah, Humbug!) There's the conundrum for a lot of developers. The person who wrote the cruft is rewarded and maintenance can end up being a thankless job. Please don't get me wrong. I've revisited code I'd written in the heat of deadline pressure and found it less than concise too. I'm definitely not holier than thou or anyone else. Although I pretty much try to limit my functions to much less than the length of a single printed page (60 lines). It's unfortunate that the writer of the original article compares code in the field (the "wild" as the author says) to text book code. This is not a good comparison. Text book code is not good production code almost by definition, mostly because it never contains sufficient error checking and handling. If it did, it would obscure the logic. This doesn't invalidate the gist of his argument though, because, from my experience too, code in the wild is generally pretty hairy. Possible solutions? Of course, to borrow a phrase from Fred Books, there's no silver bullet. I do believe we can gradually and incrementally improve the overall maintainability of the national code base. I can envision two potential solutions (at this moment): 1) Tapping legendary 10x developers and 2) High-quality, low-cost (open-source?) static analysis tools integrated into IDEs. 1) The apocryphal 10-times programmer. I say apocryphal, because I have yet to see any one of these programmers identified by name in the literature. Purportedly, the 10-times programmer delivers high-quality code on time--the first time. Great, more power to them, but supposedly they're only about 10% of the programming workforce. Can't we find a way to get these mythical creatures to share some of their secret powers with the rest of us journeymen? Maybe they're just born coding machines. Either way, I suppose we'd have to identify them first. 2) A good, configurable static analysis tool, built into the IDE that runs automatically as you type or at build-time or check-in. Not just lint, but one that can assess conformity to generally (or locally) recognized (published) best practices. Let's hope and strive for the best. Happy holidays.