6 ms·

What Compsci textbooks don't tell you: Real world code sucks

125 points by experiment0 14y ago

nanidin 14y ago
Not that textbook code is that much better ;)
knightni 14y ago
Most of the time, when stuff I write ends up as 'bad code', it started out as good code, and then got mangled over time due to a series of requirements changes (not necessarily due to bad processes - you often just understand your requirements better as you go along). This is a fairly natural series of events that can be helped by periodic refactoring. Unfortunately, because each change is small, none of them on their own justify the time required for the refactor. That's when you've got to hope you've got a management team that trusts your judgement, and is willing to carve out the time necessary for this stuff. Most people, alas, don't have that.
- watt 14y ago
  Well, first thing, in the Computer Science part of programming, the requirements are very simple and straightforward. For example, implementation of hashing algorithm or HashMap. You just can't compare the requirements of "science" part with requirements of "real world business system". The "science" requirements are almost laughably trivial. And the documentation of business system will run into thousands of pages. Now, you say if you just refactored the code, if you saw the "grand design" and rewrote the code to accommodate every little requirement elegantly and with proper abstractions and so on... I will say you would just end up with system so abstract and general, no-one would understand exactly how it is meeting those requirements. Because you would had generalized every special case (where it should've stayed a special case, and that's that). So in a way, the simple hacked-together awful program might actually make more sense than the elegant and grand abstract program. Because you can follow the hacked-together program, and you can't follow the arhitected program. It's this "abstractions all the way down", where you can hunt abstractions down for "how exactly does it do this one thing" all day, and then find out it's a little config setting in obscure .properties file that actually covers this one business case. (And if it was there right in code, you would be done in 5 minutes. But alas - it's a config option, so to change behaviour, now you must write all infrastructure to support another possible config option.) I say - bad code is just fact of life in real-world business. You should strive to clean it up, make it elegant, abstract and generalize... but really business just needs to to chug along.
  - tluyben2 14y ago
    > You just can't compare the requirements of "science" part with requirements of "real world business system". The "science" requirements are almost laughably trivial. And the documentation of business system will run into thousands of pages. Indeed, and even then usually crap is delivered.
  - knightni 14y ago
    Don't get me wrong, I don't strive for 'perfection'. I passed through the architecture astronaut phase quite some time ago now :-). Equally, I don't think that the opposite end of 'hacked together' is some kind of AbstractAbstractFactoryFactory extravaganza - that's just a different kind of bad code. To me, good code is code that is simple for other people to understand, and takes basic precautions with respect to being not-too-brittle to change. Every so often, I find that once the code has received enough alterations, it needs a bit of TLC.
rasur 14y ago
"You are what you eat", when applied to software is something along the lines of "software's eating the world, and the world is turning to crap". We've all seen it, at least those in the audience that have worked at some corporate of any size.. maybe "start-ups" face similar issues, it's difficult to get a consensus there.
boothead 14y ago
The little bit of haskell FUD in this article made me largely disregard the rest (although I've heard my share of horror stories about the software s big financial institutions). Once you get past the different syntax I find haskell code to be extremely readable.
- tluyben2 14y ago
  Yep, it's a) only syntax (if you cannot get past syntax maybe a you need to get another job) b) a bad example in the article c) an example of how to make code unreadable which goes for every programming language. In general Haskell programmers strive to refactor to a point where you have balance between readable, performant and idiomatic Haskell.
  - p4bl0 14y ago
    "Syntax doesn't matter… unless you're a programmer." ~ Rob Pike. I otherwise agree with your b) and c) points.
    - tluyben2 14y ago
      There is no need to torture yourself with insane syntax and I should express that probably differently, but I find the obsession over syntax usually a lack of skills or experience. For instance, there are hordes of programmers screaming they 'cannot do' Objective C because of it's syntax. That's silly.
- Inufu 14y ago
  Especially since this is obviously obfuscated Haskell. A more readable version: pow = 1 : [ 2*x | x <- pow]
  - pdw 14y ago
    Or even pow = iterate (* 2) 1
- ps258 14y ago
kokey 14y ago
It's not just bad coders, management is also very responsible. If management doesn't make sure code is at least getting documented and shown to co workers, then a lot of bad code gets written only one person understands and can develop into the shape of his own fetish, and become a problem when he leaves. The second point is that I have seen very senior programmers, as in years, e.g. the guys with multiple decades of experience, that are quite used to dealing with this. When they take code over they can read through it, add the necessary comments, and document the structure, and convey it to others.
kolektiv 14y ago
Good grief, what a vast amount of supposition backed up by very little evidence or insight. "People often write bad code." Yes, we know that. "There's more than one reason for this." Yes, we know that too. The rest of the article is just random presumptions thrown together, for what reason I couldn't say. The best developers work in finance because the money's highest? Yeah, OK then... (To be fair, I think there is a qualifying "considered to be" in there somewhere) K is impenetrable? Hmmm. Haskell is an offshoot of ML and unreadable? Umm, factually wrong. There's lots wrong with software at scale, and the pressures of financial institutions along with high budgets etc do produce an interesting set of problems, but this article offers nothing new about anything at all in the field. As an aside, I already don't trust an author when they start off with a claim that textbook code is good code! It's almost universally accepted to be trivialised and simplified to the point of "don't do this in the real world" simply because it has to be. Some of the worst code I've seen has been in textbooks (and that's worst as in "dangerous" rather than as in "badly written and in need of refactoring/replacement/enclosing in concrete). Edit to note: I think it's actually beyond incompetent journalism and in to plain lying to present a piece of code as evidence of Haskell unreadability when the link to that code on SO refers to it clearly as "obfuscated Haskell code".
- pretoriusB 14y ago
  >Good grief, what a vast amount of supposition backed up by very little evidence or insight. "People often write bad code." Yes, we know that. "There's more than one reason for this." Yes, we know that too. YOU AND ME know that. The title of the article is "What Compsci textbooks don't tell you", so I guess it is targeted at people still in college, to show them how things are in the "real world".
  - jurre 14y ago
    Trust me, the example code that I get from my university is proof enough. And it makes me sad, because it makes my peers believe it's acceptable to write such poor code.
    - tluyben2 14y ago
tluyben2 14y ago
I think this article sucks, but of course they are right; by far most real world code is horrible. That goes for academic as well by the way; I cringe when I see the code people get As & Bs for in universities. "It has to work" they say and the prof seems to agree. So you can see, yes also in Python, the most incredible constructions which 'work' but are hardly real code and do not work outside of the required examples. Code in real world companies is mostly horrible, especially when the company gets bigger and older. Spolsky has a bunch of articles about that. To counteract or prevent that you need heaps of money put into it and most companies really don't see the need or actually don't have the funds.
peteretep 14y ago
> 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 Can we stop posting this crap, please? TheReg was kinda edgy and cool circa 1998, but now it just seems a forum for trollish and content free articles.
InclinedPlane 14y ago
Well, not necessarily. There is plenty of good code out there. The dirty little secret of software development is that bad code is an effort sink. Let me run through a few truisms about bad code and see where they lead us, development wise. Bad code is buggier, so it will require fixing more often. Bad code is more difficult to understand and sometimes has non-intuitive side effects or method of operation and so working on it will take longer. Because of the convoluted way that bad code often works, adding features or doing maintenance on it often makes it even more convoluted and difficult to work on. Bad code typically has lower performance, so it will require more attention to improve performance. Due to the above 3 factors this becomes a vicious cycle of sinking effort into the code only to make it that much harder to work on in the future. For these simple reasons bad code becomes a huge time sink. Programming tasks involving good code end up taking up a much smaller portion of the developer-effort budget because it's so much easier to work on that code, while the bad code takes so much more effort and often the code base just ends up even worse than before, perpetuating the phenomenon through to the next cycle of development. The only way out of this cycle is to identify the code that is the main source of bugs and the main sink of effort then budget out more than enough time to tackle it and improve it. But most development shops aren't proactive enough, introspective enough, or set aside enough dev-resources to be capable of doing that. Even though such efforts tend to have an enormous impact on future development.
barrkel 14y ago
It apparently didn't occur to David that the reason why the code in banks suck might be because they don't actually employ "the very best". I live in London, arguably the current world financial capital, but I'd have to be fairly desperate to work for a bank. (Not suggesting I'm the very best, of course, but rather taking banker money is like being a whore.)
- Swannie 14y ago
  Ditto. Poor salary to working conditions to peer respect ratios... let alone the senior management being clueless...
- thibauts 14y ago
  I would say that programmers that have a choice will work on anything but banking software. And it's most likely that talented programmers will be driven by passion and not by money.
- dazzawazza 14y ago
  Two very capable friend of mine went from Game Development to working in different Banks/Trading Houses in London. They both told horror stories of: - Correcting the interviewer on C++ intricacies IN the interview. - Very poor process of dev/test/release cycles - Management of 'uptime' by having c++ devs on call 24/7 with Limo's, hotel rooms etc but no thought to proper testing, regression or postmortem. - Managers that managed by fear and intimidation - People who were clearly there because they were the only ones who could understand the shambles of code they'd written and were paid astronomically to not leave. In general they were mathematicians who were presumably great at maths and poor at engineering software. While they were both very good and have moved on to more interesting ventures they earned more in a few years of pain then they would have in 20 years of game development so it was worth it for them.
- mgkimsal 14y ago
  Excellent catch. "The technology people employed at these companies are considered to be the very best..." Who considers these people 'the very best'? Compsci majors? The hiring manager? Of course people in that sector are going to say "we only hire the best", but at best they're only hiring the best who bother to apply or that can be recruited. Very very very likely "the best" (by other measures) stay the hell away from finance. In some industries, having extreme expertise with specific algorithms and other very deep-knowledge of specific business rules coupled with top-notch programming skills is going to be required for some tasks. Outside of that, by and large, superhuman math/algo skills aren't needed as much as other broader skill sets (inter-departmental relations, listening, etc).
Swizec 14y ago
The worst[1] code I've seen is code produced by academics with the purpose of teaching undergrads. [1] In terms of needing refactoring, poorly named variables and functions, just doing The Wrong Thing you don't ever do in real life.
- thibauts 14y ago
  I'd say academics are very good on theory, but tend to lack the real world experience of working in teams bound by company processes. They make code for machines and students to read, not for other engineers, I suppose.
andybak 14y ago
Note to OP. Linking to the print version might hide some crud but it makes the line length too wide to be comfortable reading.
- SquareWheel 14y ago
  I usually use the print version + Readability for the best of both worlds.
EzGraphs 14y ago
Alan Kay classifies most real world code as pop culture (one of the most helpful categories for thinking about it): http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit... Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? I appreciate this categorization on many fronts: - It explains how non-computer science majors have frequently succeeded. In music, you will never find a classical musician without formal training, but frequently find pop musicians who have little or none. - It shows how some of the same ideas keep being "discovered" by one group while another group sighs and exclaims "we knew about that years ago..." - Pop culture is inherently youthful, prone to extremes, sensitive to new trends. Sound familiar? - It explains a vast amount of decision making that goes on in industry. Rather than choosing the absolute best solution from a somewhat abstract technical perspective, a solution that is new and hip (or fits what I was doing in the hey-day of the bosses youth) is selected. It is over simplistic to simplify real world code as "sucking" (though of course much does). It is like comparing Bach and <fill in your favorite rock/pop star here>. Both produce valid creations that accomplish something, but were made with vastly different intentions and for different purposes.
- EzGraphs 14y ago
  Another Kay quote on the same subject: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.
kris_lander 14y ago
The problem highlighted by this article and the ensuing debate here is that most people in our industry (management and developers alike) talk about good code and bad code in purely subjective terms. Until we learn to talk objectively about the systems we build (where code is just one part of that system) in terms of function (what a system needs to do), performance (how "good" the system has to do the functions) and economics (the resource constraints in building the system) - you know, like proper engineers do, we'll never move forward. The ugly truth is that would appear that most banking systems are "good enough" - i.e. they are competitive in the environment operate in - despite the horrors that undoubtably exist in their implementation. I see a lot of talk about the consequences of "bad code" but few have the evidence to back it up. It is our responsibility as engineers to measure the performance of our systems in the _right_ way so it becomes painfully obvious where we should focus our efforts to improve things.
mmahemoff 14y ago
This begs the question, which textbooks do include or at least address real-world code? The closest I can recall are those with heavy emphasis on refactoring, because gradually moving from bad to good is usually the best one can hope for in the real world. I'm thinking in particular of Bob Martin's Agile Software Development, because I liked how he made the point in the book that he didn't just arrive at this beautiful code, but achieved it through TDD and refactoring. I think "bad code" is actually what the most talented developers excel at (see also Duct Tape Programming http://www.joelonsoftware.com/items/2009/09/23.html http://www.joelonsoftware.com/items/2009/09/23.html). A talented programmer knows when it's worthwhile breaking the rules and, by necessity of getting things done, does so on a frequent basis.
- InclinedPlane 14y ago
  Well, this brings up another problem. And that is that software development is not applied computer science. There are plenty of books which will teach you skills on dealing with real-world code (Refactoring and Working Effectively With Legacy Code being two of the biggies) and there are books that will teach you about other important aspects of development processes (such as Code Complete, Rapid Development, Design Patterns, The Pragmatic Programmer, etc. although those books are showing their age a bit these days) but none of those would be considered computer science textbooks.
  - mmahemoff 14y ago
    True, though I don't think this article is really talking about pure CompSci. That would be about as relevant to Register's audience as books on physics.
- TeeDub 14y ago
  InclinedPlane mentioned "Working Effectively with Legacy Code," and I'd just like to add that's one of the greatest software engineering books out there. Feathers (the author) methodologically chose to copy / inspire some of his examples from code he's worked with as a mentor / developer (some of it from his time @ Thought Works w/ Beck, et al.) The book is similar to Fowler's Refactoring in that it provides some core thought processes / ideology and then a long list of heuristics and techniques for revising/updating legacy code. (I find his definition of "legacy code" as any software without automated testing to be challenging and insightful, especially since it indicts most code written ever. ;) If you get the chance, you could also consider reading "Clean Code", it doesn't have /as much/ "real world" source but is still excellent.
nnq 14y ago
Trollish but true. Things will only change when we start to treat code as knowledge and not just a tool. And to have knowledge and not just data that can incidentally be compiled or executed as a program that does something, you also need: meta-data (comments), documentation (always sucks, probably because writing good docs is as expensive as writing the code itself...), history (vcs solves this only if the commits have meaningful comments, bug-tracker data helps a lot but it would be great to be able to easily get from a piece of code to either the written requirement or the bug-request that the code satisfies/solves) and meaningful organization (the UNIX philosophy of small one-task tools, coupled with exposing these tools through web/services APIs is still one of the best ideas in the field - just don't overengineer the interfaces and protocols, keep them thin, keep them dumb).
ericssmith 14y ago
A more revealing and accurate look at software in the real world is 'Big Ball of Mud': http://www.laputan.org/mud/ http://www.laputan.org/mud/ As a Haskell programmer, I thought the Taliban comment was funny.
- geoka9 14y ago
  As a non-Haskell programmer (who's had to deal with code in Haskell) I think it's spot-on.
elb0w 14y ago
Real world code doesnt suck in my opinion. The issue is that a lot of the time it solves problems that these books don't need to. Its easy to build an alogirthm and print it when you know every edge case. If you would take the first version of most production code put it in a book and write the problem it solves, I'm sure you wouldn't think it sucks. My exp developer 15years, finance industry 7.
queensnake 14y ago
Yet another reason to work at Google. They're anti- both obscure or clever code (see their coding standards), and so far in my own experience, you get the time you need to get the code right. There are periodic 'testing on the toilet' pieces to remind you to refactor ruthlessly as you go, and, on how to bring up and gather support for fixing technical debt, with your team. I haven't seen this at any other place I've worked, quite the opposite. It's a luxury.
tossacct 14y ago
An assumption: code is designed [to get things done]. Another assumption: the [thing to get done] will likely eventually be transformed via evolution or destroyed, as all natural things like rocks and species and hydrogen atoms and gluons and the entire known universe starting[?] with the big bang transforms via evolution or gets destroyed. A conclusion: code that can not be easily changed and evolved will be conveniently destroyed via a complete re-write. This is why "facades" and opaque APIs are so popular - it is theoretically possible to rewrite different components of the code without rewriting the whole entire dang thing. Case in point: http://stackoverflow.com/questions/810129/how-does-whiles-t-work http://stackoverflow.com/questions/810129/how-does-whiles-t-... >>>while (s++ = t++); This is code that is hard to understand(hence the stackoverflow question), making it not easily changed. Not a good sign for the survivability of the code. JoelonSoftware.com makes a sparse point with this example, in that a "good" coder must understand what this does. He leaves the reasoning up to the reader, likely because he is clever enough not to make any claims that can be disagreed with. Luckily I am not this clever and I will make a claim that follows from my assumptions and conclusion above: Claim: a "good" coder needs to understand the above type of obfuscated code so that they can evolve it or destroy it safely when they see it. Note that my claim does not say whether a "good" coder would write code like that. A "good" coder gets the job done, whether it's a write-once-use-once-read-never perl one-liner or a big part of a big program. I only claim that a "good" coder must be able to read it, so that they can change it or destroy it safely.
- stephencanon 14y ago
  > while(s++ = t++); is absolutely trivial to understand if the reader has taken the time to actually learn the language in which the code is written. Saying this is "hard to understand" is like saying that "Ich liebe dich" is hard to understand. I'm sure it might be if the reader has never encountered German, but that's not real complexity, and it's not unreasonable for someone writing in German to assume that her reader has some competency with the language.
  - jblow 14y ago
    I disagree. I have 16 years' experience programming in C++ (and substantial experience in other languages before that), and I find that an important factor in code clarity is not writing stuff like this. Yes, you can understand it, but it takes more brainpower to do so than it should, especially once you get beyond trivial cases. It is much better just to write it the long way.
_pferreir_ 14y ago
In my own experience, the development process is usually to blame, more than the developers themselves, their capabilities (or lack thereof) or their paycheck. The project I work for depends highly on usually inexperienced developers and we're using a development process that is task-oriented but at the same time based on continuous feedback and regular code reviews. Should it be any other way, things would quickly degenerate. That's what happened before I arrived, and we're still (years later) recovering from the damage that that has caused to the code base. Outside the IT industry, most bosses don't want to hear about code. Coding is actually seen as a pretty trivial step in many cases. It's OK to hire an intern to add new feature X. Writing good code is not properly rewarded - as long as it works, it's stable, no-one complains, it's OK. Not to mention stuff such as niche technologies, that usually create a barrier to entry that would-be employees have to overcome, thus concentrating the know-how, power and pay in the hands of a few bored people that won't bother learning the next thing.
OldSchool 14y ago
On this entrepreneurially-focused website I'm going to offer that you can't afford to be an idealist about both business and engineering- probably neither. Good-enough at the right time in the right market trumps perfection without all the outside business forces lining up every time. If you're an artist at heart, no-surprise, it's far more charming to the world if you're financially successful.
dschiptsov 14y ago
The problem of bad software is too big for one post, and there are multiple causation, of course. Mostly it is incompetence, over-management, pay per line of code in a 9 to 5 shifts, while the resulting product is not anyone's problem. It has something to do with forced collectivization and wage labor, while everyone concerned only with oneself. The good analogy is with writing a poetry and professional writing in general. There are many examples of technical and scientific books produced by two or free authors (they could list ten, but actual work was done usually by no more than a couple). But we haven't seen any decent book produced by a mediocre writers on 9 to 5 shifts. The idea that this will work for programming is very naive one. Another analogy is engineering, which is also done by few capable individuals with help of others. There are nothing but failures when mediocre groups trying to engineer anything. On the contrary, we had lots of things invented by capable individuals, things that later were polished by later generations. So, if one looking for an example of good software look at individuals, or small groups lead by one capable visionary, and avoid anything created in sweat-shops. Most of the really good software we have (Lisp, C, Unix, Plan9, Emacs, vi, nginx, redis, postgres, Informix, etc) was created by an individual effort of men of unusual capabilities, and then polished by community. Good software engineering is as rare as good poetry, and it cannot be produced by any amount of a manual labor. There are people who can sell you products and solutions, even ready processes which, they say, will guarantee that you can create good software employing mediocre coders in 9-to-5 shifts. It is all Java or Scrum scams is all about. It is not tools that create software or invent things, it is minds, the same way no typewriter or fountain pen could make one a poet.
michaelochurch 14y ago
This guy shits all over his credibility by turning it into a language war. He clearly is out of his depth on the Haskell issue, and I know credible people who think highly of q and kdb (which are rare outside of finance, but ubiquitous in finance). That said, he's got a point, but the only solution he gives is "Include some comments!" I've seen so many shitty comments that I really think this is no advice at all. Four levels of software maturity. (There are others. This is a simplified model.) Level 1: Your work doesn't exist until it's in version control. It might be amazing to 2012-era programmers that this could be controversial, because even the laggards have reached L1 maturity, but at one time, it was. (See: the Joel test.) Level 2: Your work doesn't exist until it has tests at multiple levels (e.g. unit and integration). Otherwise, it has no enforced semantics. Level 3: Your work doesn't exist until it has well-documented semantics in addition to the tests, which cannot cover all cases. Otherwise, how does one even decide what a "bug" is? Level 4: Your work doesn't exist until you've provided the resources (e.g. a code walk or an interactive module) to teach people how to use it. If you're at Level 1, you won't lose source code. If you're at Level 2, your breakage rate will be reduced, and you can run CI. At Level 3, your system integrity will remain decent because you don't end up with those software-as-spec modules that, over time, corrupt the whole system. Guess what? It takes Level 4 to get good code. Unless there is a culture of teaching (incremental code reviews are not enough) within the company, you will not have good code for very long. Since engineers are intolerant of context switches and in-person teaching doesn't scale, the teaching should be automatic. Interactive modules or, at the least, code walks should come with the technical asset being demonstrated. If people don't know what they are looking at, then how can they be expected to review or maintain code. With the worst code, it's not even clear why it's bad. It's just incomprehensible.
- mikegioia 14y ago
  Come on! He makes one reference to Haskell, links to the SO post on it, admits he has never used it, and all of a sudden he "shits all over his credibility by turning it into a language war"? It's an example of how ugly code can get for goodness sake.
  - spacemanaki 14y ago
gd1 14y ago
What a terrible article. That line of APL is sheer beauty (http://www.youtube.com/watch?v=a9xAKttWgP4 http://www.youtube.com/watch?v=a9xAKttWgP4) - being ignorant of a language's syntax and not willing to invest the time to learn it is no reason to claim it is 'impenetrable'. I'm sure sheet music, replete with quavers and semi-breves and treble clefs is impenetrable the first time you see it, but once learned is far superior to playNote(double hertz, double duration). Worse, it goes against his point just a paragraph earlier. The whole advantage of Q/K/J/Haskell style languages is that once skilled in them, the code is much (as in 10-20 times) denser than the equivalent OO-style code, and the entire flow can be grok'ed with ease. There is much less danger of over-engineering in those languages.
jfb 14y ago
This is why I don't worry about Kurzweil's singularity. The putative Godlike AI will be littered with catch (e) {;} and non reentrant signal handlers and shit. It's the nature if complex systems.
dscrd 14y ago
More important: The code you write in the real world will also suck.
chiquitabacana 14y ago
Sometimes, in big projects, there are excerpts of very nice and elegant code. But to imagine 10,000,000 lines of pure perfection it's impossible. Bsides, real world code can be good code, but it's a different kind of code. Textbook code it's not functional, functional code to me, it's way prettier than some simplified example.

125 points by experiment0 14y ago

Not that textbook code is that much better ;)

Most of the time, when stuff I write ends up as 'bad code', it started out as good code, and then got mangled over time due to a series of requirements changes (not necessarily due to bad processes - you often just understand your requirements better as you go along). This is a fairly natural series of events that can be helped by periodic refactoring. Unfortunately, because each change is small, none of them on their own justify the time required for the refactor. That's when you've got to hope you've got a management team that trusts your judgement, and is willing to carve out the time necessary for this stuff. Most people, alas, don't have that.

watt 14y ago
Well, first thing, in the Computer Science part of programming, the requirements are very simple and straightforward. For example, implementation of hashing algorithm or HashMap. You just can't compare the requirements of "science" part with requirements of "real world business system". The "science" requirements are almost laughably trivial. And the documentation of business system will run into thousands of pages. Now, you say if you just refactored the code, if you saw the "grand design" and rewrote the code to accommodate every little requirement elegantly and with proper abstractions and so on... I will say you would just end up with system so abstract and general, no-one would understand exactly how it is meeting those requirements. Because you would had generalized every special case (where it should've stayed a special case, and that's that). So in a way, the simple hacked-together awful program might actually make more sense than the elegant and grand abstract program. Because you can follow the hacked-together program, and you can't follow the arhitected program. It's this "abstractions all the way down", where you can hunt abstractions down for "how exactly does it do this one thing" all day, and then find out it's a little config setting in obscure .properties file that actually covers this one business case. (And if it was there right in code, you would be done in 5 minutes. But alas - it's a config option, so to change behaviour, now you must write all infrastructure to support another possible config option.) I say - bad code is just fact of life in real-world business. You should strive to clean it up, make it elegant, abstract and generalize... but really business just needs to to chug along.
- tluyben2 14y ago
  > You just can't compare the requirements of "science" part with requirements of "real world business system". The "science" requirements are almost laughably trivial. And the documentation of business system will run into thousands of pages. Indeed, and even then usually crap is delivered.
- knightni 14y ago
  Don't get me wrong, I don't strive for 'perfection'. I passed through the architecture astronaut phase quite some time ago now :-). Equally, I don't think that the opposite end of 'hacked together' is some kind of AbstractAbstractFactoryFactory extravaganza - that's just a different kind of bad code. To me, good code is code that is simple for other people to understand, and takes basic precautions with respect to being not-too-brittle to change. Every so often, I find that once the code has received enough alterations, it needs a bit of TLC.

rasur 14y ago

"You are what you eat", when applied to software is something along the lines of "software's eating the world, and the world is turning to crap". We've all seen it, at least those in the audience that have worked at some corporate of any size.. maybe "start-ups" face similar issues, it's difficult to get a consensus there.

boothead 14y ago

The little bit of haskell FUD in this article made me largely disregard the rest (although I've heard my share of horror stories about the software s big financial institutions). Once you get past the different syntax I find haskell code to be extremely readable.

tluyben2 14y ago
Yep, it's a) only syntax (if you cannot get past syntax maybe a you need to get another job) b) a bad example in the article c) an example of how to make code unreadable which goes for every programming language. In general Haskell programmers strive to refactor to a point where you have balance between readable, performant and idiomatic Haskell.
- p4bl0 14y ago
  "Syntax doesn't matter… unless you're a programmer." ~ Rob Pike. I otherwise agree with your b) and c) points.
  - tluyben2 14y ago
    There is no need to torture yourself with insane syntax and I should express that probably differently, but I find the obsession over syntax usually a lack of skills or experience. For instance, there are hordes of programmers screaming they 'cannot do' Objective C because of it's syntax. That's silly.
Inufu 14y ago
Especially since this is obviously obfuscated Haskell. A more readable version: pow = 1 : [ 2*x | x <- pow]
- pdw 14y ago
  Or even pow = iterate (* 2) 1
ps258 14y ago

kokey 14y ago

It's not just bad coders, management is also very responsible. If management doesn't make sure code is at least getting documented and shown to co workers, then a lot of bad code gets written only one person understands and can develop into the shape of his own fetish, and become a problem when he leaves. The second point is that I have seen very senior programmers, as in years, e.g. the guys with multiple decades of experience, that are quite used to dealing with this. When they take code over they can read through it, add the necessary comments, and document the structure, and convey it to others.

kolektiv 14y ago

Good grief, what a vast amount of supposition backed up by very little evidence or insight. "People often write bad code." Yes, we know that. "There's more than one reason for this." Yes, we know that too. The rest of the article is just random presumptions thrown together, for what reason I couldn't say. The best developers work in finance because the money's highest? Yeah, OK then... (To be fair, I think there is a qualifying "considered to be" in there somewhere) K is impenetrable? Hmmm. Haskell is an offshoot of ML and unreadable? Umm, factually wrong. There's lots wrong with software at scale, and the pressures of financial institutions along with high budgets etc do produce an interesting set of problems, but this article offers nothing new about anything at all in the field. As an aside, I already don't trust an author when they start off with a claim that textbook code is good code! It's almost universally accepted to be trivialised and simplified to the point of "don't do this in the real world" simply because it has to be. Some of the worst code I've seen has been in textbooks (and that's worst as in "dangerous" rather than as in "badly written and in need of refactoring/replacement/enclosing in concrete). Edit to note: I think it's actually beyond incompetent journalism and in to plain lying to present a piece of code as evidence of Haskell unreadability when the link to that code on SO refers to it clearly as "obfuscated Haskell code".

pretoriusB 14y ago
>Good grief, what a vast amount of supposition backed up by very little evidence or insight. "People often write bad code." Yes, we know that. "There's more than one reason for this." Yes, we know that too. YOU AND ME know that. The title of the article is "What Compsci textbooks don't tell you", so I guess it is targeted at people still in college, to show them how things are in the "real world".
- jurre 14y ago
  Trust me, the example code that I get from my university is proof enough. And it makes me sad, because it makes my peers believe it's acceptable to write such poor code.
  - tluyben2 14y ago

tluyben2 14y ago

I think this article sucks, but of course they are right; by far most real world code is horrible. That goes for academic as well by the way; I cringe when I see the code people get As & Bs for in universities. "It has to work" they say and the prof seems to agree. So you can see, yes also in Python, the most incredible constructions which 'work' but are hardly real code and do not work outside of the required examples. Code in real world companies is mostly horrible, especially when the company gets bigger and older. Spolsky has a bunch of articles about that. To counteract or prevent that you need heaps of money put into it and most companies really don't see the need or actually don't have the funds.

peteretep 14y ago

> 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 Can we stop posting this crap, please? TheReg was kinda edgy and cool circa 1998, but now it just seems a forum for trollish and content free articles.

InclinedPlane 14y ago

Well, not necessarily. There is plenty of good code out there. The dirty little secret of software development is that bad code is an effort sink. Let me run through a few truisms about bad code and see where they lead us, development wise. Bad code is buggier, so it will require fixing more often. Bad code is more difficult to understand and sometimes has non-intuitive side effects or method of operation and so working on it will take longer. Because of the convoluted way that bad code often works, adding features or doing maintenance on it often makes it even more convoluted and difficult to work on. Bad code typically has lower performance, so it will require more attention to improve performance. Due to the above 3 factors this becomes a vicious cycle of sinking effort into the code only to make it that much harder to work on in the future. For these simple reasons bad code becomes a huge time sink. Programming tasks involving good code end up taking up a much smaller portion of the developer-effort budget because it's so much easier to work on that code, while the bad code takes so much more effort and often the code base just ends up even worse than before, perpetuating the phenomenon through to the next cycle of development. The only way out of this cycle is to identify the code that is the main source of bugs and the main sink of effort then budget out more than enough time to tackle it and improve it. But most development shops aren't proactive enough, introspective enough, or set aside enough dev-resources to be capable of doing that. Even though such efforts tend to have an enormous impact on future development.

barrkel 14y ago

It apparently didn't occur to David that the reason why the code in banks suck might be because they don't actually employ "the very best". I live in London, arguably the current world financial capital, but I'd have to be fairly desperate to work for a bank. (Not suggesting I'm the very best, of course, but rather taking banker money is like being a whore.)

Swannie 14y ago
Ditto. Poor salary to working conditions to peer respect ratios... let alone the senior management being clueless...
thibauts 14y ago
I would say that programmers that have a choice will work on anything but banking software. And it's most likely that talented programmers will be driven by passion and not by money.
dazzawazza 14y ago
Two very capable friend of mine went from Game Development to working in different Banks/Trading Houses in London. They both told horror stories of: - Correcting the interviewer on C++ intricacies IN the interview. - Very poor process of dev/test/release cycles - Management of 'uptime' by having c++ devs on call 24/7 with Limo's, hotel rooms etc but no thought to proper testing, regression or postmortem. - Managers that managed by fear and intimidation - People who were clearly there because they were the only ones who could understand the shambles of code they'd written and were paid astronomically to not leave. In general they were mathematicians who were presumably great at maths and poor at engineering software. While they were both very good and have moved on to more interesting ventures they earned more in a few years of pain then they would have in 20 years of game development so it was worth it for them.
mgkimsal 14y ago
Excellent catch. "The technology people employed at these companies are considered to be the very best..." Who considers these people 'the very best'? Compsci majors? The hiring manager? Of course people in that sector are going to say "we only hire the best", but at best they're only hiring the best who bother to apply or that can be recruited. Very very very likely "the best" (by other measures) stay the hell away from finance. In some industries, having extreme expertise with specific algorithms and other very deep-knowledge of specific business rules coupled with top-notch programming skills is going to be required for some tasks. Outside of that, by and large, superhuman math/algo skills aren't needed as much as other broader skill sets (inter-departmental relations, listening, etc).

Swizec 14y ago

The worst[1] code I've seen is code produced by academics with the purpose of teaching undergrads. [1] In terms of needing refactoring, poorly named variables and functions, just doing The Wrong Thing you don't ever do in real life.

thibauts 14y ago
I'd say academics are very good on theory, but tend to lack the real world experience of working in teams bound by company processes. They make code for machines and students to read, not for other engineers, I suppose.

andybak 14y ago

Note to OP. Linking to the print version might hide some crud but it makes the line length too wide to be comfortable reading.

SquareWheel 14y ago
I usually use the print version + Readability for the best of both worlds.

EzGraphs 14y ago

Alan Kay classifies most real world code as pop culture (one of the most helpful categories for thinking about it): http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit... Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? I appreciate this categorization on many fronts: - It explains how non-computer science majors have frequently succeeded. In music, you will never find a classical musician without formal training, but frequently find pop musicians who have little or none. - It shows how some of the same ideas keep being "discovered" by one group while another group sighs and exclaims "we knew about that years ago..." - Pop culture is inherently youthful, prone to extremes, sensitive to new trends. Sound familiar? - It explains a vast amount of decision making that goes on in industry. Rather than choosing the absolute best solution from a somewhat abstract technical perspective, a solution that is new and hip (or fits what I was doing in the hey-day of the bosses youth) is selected. It is over simplistic to simplify real world code as "sucking" (though of course much does). It is like comparing Bach and <fill in your favorite rock/pop star here>. Both produce valid creations that accomplish something, but were made with vastly different intentions and for different purposes.

EzGraphs 14y ago
Another Kay quote on the same subject: http://queue.acm.org/detail.cfm?id=1039523 http://queue.acm.org/detail.cfm?id=1039523 In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were. So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.

kris_lander 14y ago

The problem highlighted by this article and the ensuing debate here is that most people in our industry (management and developers alike) talk about good code and bad code in purely subjective terms. Until we learn to talk objectively about the systems we build (where code is just one part of that system) in terms of function (what a system needs to do), performance (how "good" the system has to do the functions) and economics (the resource constraints in building the system) - you know, like proper engineers do, we'll never move forward. The ugly truth is that would appear that most banking systems are "good enough" - i.e. they are competitive in the environment operate in - despite the horrors that undoubtably exist in their implementation. I see a lot of talk about the consequences of "bad code" but few have the evidence to back it up. It is our responsibility as engineers to measure the performance of our systems in the _right_ way so it becomes painfully obvious where we should focus our efforts to improve things.

mmahemoff 14y ago

This begs the question, which textbooks do include or at least address real-world code? The closest I can recall are those with heavy emphasis on refactoring, because gradually moving from bad to good is usually the best one can hope for in the real world. I'm thinking in particular of Bob Martin's Agile Software Development, because I liked how he made the point in the book that he didn't just arrive at this beautiful code, but achieved it through TDD and refactoring. I think "bad code" is actually what the most talented developers excel at (see also Duct Tape Programming http://www.joelonsoftware.com/items/2009/09/23.html http://www.joelonsoftware.com/items/2009/09/23.html). A talented programmer knows when it's worthwhile breaking the rules and, by necessity of getting things done, does so on a frequent basis.

InclinedPlane 14y ago
Well, this brings up another problem. And that is that software development is not applied computer science. There are plenty of books which will teach you skills on dealing with real-world code (Refactoring and Working Effectively With Legacy Code being two of the biggies) and there are books that will teach you about other important aspects of development processes (such as Code Complete, Rapid Development, Design Patterns, The Pragmatic Programmer, etc. although those books are showing their age a bit these days) but none of those would be considered computer science textbooks.
- mmahemoff 14y ago
  True, though I don't think this article is really talking about pure CompSci. That would be about as relevant to Register's audience as books on physics.
TeeDub 14y ago
InclinedPlane mentioned "Working Effectively with Legacy Code," and I'd just like to add that's one of the greatest software engineering books out there. Feathers (the author) methodologically chose to copy / inspire some of his examples from code he's worked with as a mentor / developer (some of it from his time @ Thought Works w/ Beck, et al.) The book is similar to Fowler's Refactoring in that it provides some core thought processes / ideology and then a long list of heuristics and techniques for revising/updating legacy code. (I find his definition of "legacy code" as any software without automated testing to be challenging and insightful, especially since it indicts most code written ever. ;) If you get the chance, you could also consider reading "Clean Code", it doesn't have /as much/ "real world" source but is still excellent.

nnq 14y ago

Trollish but true. Things will only change when we start to treat code as knowledge and not just a tool. And to have knowledge and not just data that can incidentally be compiled or executed as a program that does something, you also need: meta-data (comments), documentation (always sucks, probably because writing good docs is as expensive as writing the code itself...), history (vcs solves this only if the commits have meaningful comments, bug-tracker data helps a lot but it would be great to be able to easily get from a piece of code to either the written requirement or the bug-request that the code satisfies/solves) and meaningful organization (the UNIX philosophy of small one-task tools, coupled with exposing these tools through web/services APIs is still one of the best ideas in the field - just don't overengineer the interfaces and protocols, keep them thin, keep them dumb).

ericssmith 14y ago

A more revealing and accurate look at software in the real world is 'Big Ball of Mud': http://www.laputan.org/mud/ http://www.laputan.org/mud/ As a Haskell programmer, I thought the Taliban comment was funny.

geoka9 14y ago
As a non-Haskell programmer (who's had to deal with code in Haskell) I think it's spot-on.

elb0w 14y ago

Real world code doesnt suck in my opinion. The issue is that a lot of the time it solves problems that these books don't need to. Its easy to build an alogirthm and print it when you know every edge case. If you would take the first version of most production code put it in a book and write the problem it solves, I'm sure you wouldn't think it sucks. My exp developer 15years, finance industry 7.

queensnake 14y ago

Yet another reason to work at Google. They're anti- both obscure or clever code (see their coding standards), and so far in my own experience, you get the time you need to get the code right. There are periodic 'testing on the toilet' pieces to remind you to refactor ruthlessly as you go, and, on how to bring up and gather support for fixing technical debt, with your team. I haven't seen this at any other place I've worked, quite the opposite. It's a luxury.

tossacct 14y ago

An assumption: code is designed [to get things done]. Another assumption: the [thing to get done] will likely eventually be transformed via evolution or destroyed, as all natural things like rocks and species and hydrogen atoms and gluons and the entire known universe starting[?] with the big bang transforms via evolution or gets destroyed. A conclusion: code that can not be easily changed and evolved will be conveniently destroyed via a complete re-write. This is why "facades" and opaque APIs are so popular - it is theoretically possible to rewrite different components of the code without rewriting the whole entire dang thing. Case in point: http://stackoverflow.com/questions/810129/how-does-whiles-t-work http://stackoverflow.com/questions/810129/how-does-whiles-t-... >>>while (s++ = t++); This is code that is hard to understand(hence the stackoverflow question), making it not easily changed. Not a good sign for the survivability of the code. JoelonSoftware.com makes a sparse point with this example, in that a "good" coder must understand what this does. He leaves the reasoning up to the reader, likely because he is clever enough not to make any claims that can be disagreed with. Luckily I am not this clever and I will make a claim that follows from my assumptions and conclusion above: Claim: a "good" coder needs to understand the above type of obfuscated code so that they can evolve it or destroy it safely when they see it. Note that my claim does not say whether a "good" coder would write code like that. A "good" coder gets the job done, whether it's a write-once-use-once-read-never perl one-liner or a big part of a big program. I only claim that a "good" coder must be able to read it, so that they can change it or destroy it safely.

stephencanon 14y ago
> while(s++ = t++); is absolutely trivial to understand if the reader has taken the time to actually learn the language in which the code is written. Saying this is "hard to understand" is like saying that "Ich liebe dich" is hard to understand. I'm sure it might be if the reader has never encountered German, but that's not real complexity, and it's not unreasonable for someone writing in German to assume that her reader has some competency with the language.
- jblow 14y ago
  I disagree. I have 16 years' experience programming in C++ (and substantial experience in other languages before that), and I find that an important factor in code clarity is not writing stuff like this. Yes, you can understand it, but it takes more brainpower to do so than it should, especially once you get beyond trivial cases. It is much better just to write it the long way.

_pferreir_ 14y ago

In my own experience, the development process is usually to blame, more than the developers themselves, their capabilities (or lack thereof) or their paycheck. The project I work for depends highly on usually inexperienced developers and we're using a development process that is task-oriented but at the same time based on continuous feedback and regular code reviews. Should it be any other way, things would quickly degenerate. That's what happened before I arrived, and we're still (years later) recovering from the damage that that has caused to the code base. Outside the IT industry, most bosses don't want to hear about code. Coding is actually seen as a pretty trivial step in many cases. It's OK to hire an intern to add new feature X. Writing good code is not properly rewarded - as long as it works, it's stable, no-one complains, it's OK. Not to mention stuff such as niche technologies, that usually create a barrier to entry that would-be employees have to overcome, thus concentrating the know-how, power and pay in the hands of a few bored people that won't bother learning the next thing.

OldSchool 14y ago

On this entrepreneurially-focused website I'm going to offer that you can't afford to be an idealist about both business and engineering- probably neither. Good-enough at the right time in the right market trumps perfection without all the outside business forces lining up every time. If you're an artist at heart, no-surprise, it's far more charming to the world if you're financially successful.

dschiptsov 14y ago

The problem of bad software is too big for one post, and there are multiple causation, of course. Mostly it is incompetence, over-management, pay per line of code in a 9 to 5 shifts, while the resulting product is not anyone's problem. It has something to do with forced collectivization and wage labor, while everyone concerned only with oneself. The good analogy is with writing a poetry and professional writing in general. There are many examples of technical and scientific books produced by two or free authors (they could list ten, but actual work was done usually by no more than a couple). But we haven't seen any decent book produced by a mediocre writers on 9 to 5 shifts. The idea that this will work for programming is very naive one. Another analogy is engineering, which is also done by few capable individuals with help of others. There are nothing but failures when mediocre groups trying to engineer anything. On the contrary, we had lots of things invented by capable individuals, things that later were polished by later generations. So, if one looking for an example of good software look at individuals, or small groups lead by one capable visionary, and avoid anything created in sweat-shops. Most of the really good software we have (Lisp, C, Unix, Plan9, Emacs, vi, nginx, redis, postgres, Informix, etc) was created by an individual effort of men of unusual capabilities, and then polished by community. Good software engineering is as rare as good poetry, and it cannot be produced by any amount of a manual labor. There are people who can sell you products and solutions, even ready processes which, they say, will guarantee that you can create good software employing mediocre coders in 9-to-5 shifts. It is all Java or Scrum scams is all about. It is not tools that create software or invent things, it is minds, the same way no typewriter or fountain pen could make one a poet.

michaelochurch 14y ago

This guy shits all over his credibility by turning it into a language war. He clearly is out of his depth on the Haskell issue, and I know credible people who think highly of q and kdb (which are rare outside of finance, but ubiquitous in finance). That said, he's got a point, but the only solution he gives is "Include some comments!" I've seen so many shitty comments that I really think this is no advice at all. Four levels of software maturity. (There are others. This is a simplified model.) Level 1: Your work doesn't exist until it's in version control. It might be amazing to 2012-era programmers that this could be controversial, because even the laggards have reached L1 maturity, but at one time, it was. (See: the Joel test.) Level 2: Your work doesn't exist until it has tests at multiple levels (e.g. unit and integration). Otherwise, it has no enforced semantics. Level 3: Your work doesn't exist until it has well-documented semantics in addition to the tests, which cannot cover all cases. Otherwise, how does one even decide what a "bug" is? Level 4: Your work doesn't exist until you've provided the resources (e.g. a code walk or an interactive module) to teach people how to use it. If you're at Level 1, you won't lose source code. If you're at Level 2, your breakage rate will be reduced, and you can run CI. At Level 3, your system integrity will remain decent because you don't end up with those software-as-spec modules that, over time, corrupt the whole system. Guess what? It takes Level 4 to get good code. Unless there is a culture of teaching (incremental code reviews are not enough) within the company, you will not have good code for very long. Since engineers are intolerant of context switches and in-person teaching doesn't scale, the teaching should be automatic. Interactive modules or, at the least, code walks should come with the technical asset being demonstrated. If people don't know what they are looking at, then how can they be expected to review or maintain code. With the worst code, it's not even clear why it's bad. It's just incomprehensible.

mikegioia 14y ago
Come on! He makes one reference to Haskell, links to the SO post on it, admits he has never used it, and all of a sudden he "shits all over his credibility by turning it into a language war"? It's an example of how ugly code can get for goodness sake.
- spacemanaki 14y ago

gd1 14y ago

What a terrible article. That line of APL is sheer beauty (http://www.youtube.com/watch?v=a9xAKttWgP4 http://www.youtube.com/watch?v=a9xAKttWgP4) - being ignorant of a language's syntax and not willing to invest the time to learn it is no reason to claim it is 'impenetrable'. I'm sure sheet music, replete with quavers and semi-breves and treble clefs is impenetrable the first time you see it, but once learned is far superior to playNote(double hertz, double duration). Worse, it goes against his point just a paragraph earlier. The whole advantage of Q/K/J/Haskell style languages is that once skilled in them, the code is much (as in 10-20 times) denser than the equivalent OO-style code, and the entire flow can be grok'ed with ease. There is much less danger of over-engineering in those languages.

jfb 14y ago

This is why I don't worry about Kurzweil's singularity. The putative Godlike AI will be littered with catch (e) {;} and non reentrant signal handlers and shit. It's the nature if complex systems.

dscrd 14y ago

More important: The code you write in the real world will also suck.

chiquitabacana 14y ago

Sometimes, in big projects, there are excerpts of very nice and elegant code. But to imagine 10,000,000 lines of pure perfection it's impossible. Bsides, real world code can be good code, but it's a different kind of code. Textbook code it's not functional, functional code to me, it's way prettier than some simplified example.