Real World Code Sucks 292
An anonymous reader tips an article at El Reg about the disparity between the code you learn at school and the code you see at work. Quoting:
"There is a kind of cognitive dissonance in most people who've moved from the academic study of computer science to a job as a real-world software developer. The conflict lies in the fact that, whereas nearly every sample program in every textbook is a perfect and well-thought-out specimen, virtually no software out in the wild is, and this is rarely acknowledged. To be precise: a tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it's outright terrible by any number of measures."
must read: "worse is better" (Score:5, Interesting)
It might be interesting to read The Rise of "Worse is Better" [jwz.org]
Re:must read: "worse is better" (Score:4, Insightful)
It might be interesting to read The Rise of "Worse is Better" [jwz.org]
That's a great article for high-brow programmers who want to triple-plus-abstract and design-pattern everything. You know... the folks who Joel Spolsky calls "architects astronauts". However, notice that this article is readable and thoughtfully characterizes the two coding styles it trying to differentiate. Fundamentally, this person knows their craft.
This is unlike some of my coworkers, who still embedd SQL straight into their GUI's. (I know of one of our apps where all the methods have the same 30+ parameters being slopped around [to represent a row from table X] because the original dev team couldn't be bothered to create a class called "X" to represent the concept of X and so pass around 1 reference.)
These people aren't heroic real-world veterans who sagely ignore the pretentious chatterings of academics... they're simply folks who don't understand how to express themselves clearly in code, much less the runtime environment, compilation process, or other fundamentals of the basic tools they've worked with for the past ~5 years.
Re: (Score:2)
Re:must read: "worse is better" (Score:5, Insightful)
"In theory there's no difference between theory and reality....in reality it's the other way around"
Seriously, real world code is by definition 'real world' and doesn't live by the theoretical pillars of design. It has to deal with actual deadlines, finite resources and of course office politics.
Re:must read: "worse is better" (Score:5, Insightful)
Summarized as follows:
"In theory there's no difference between theory and reality....in reality it's the other way around"
Seriously, real world code is by definition 'real world' and doesn't live by the theoretical pillars of design. It has to deal with actual deadlines, finite resources and of course office politics.
Exactly.
Where the professor can take 6 months to prepare a small simplistic demo application custom tailored to demonstrate his (pet) coding methods and design standards, in the real world you have to get things done, not in 6 months, not in 6 weeks, and seldom in 6 days. You might have 6 hours on a good day.
Does too much of this quick hacks find its way into production?
Absolutely.
Do bad 2x4s find their way into house construction? Of course.
But corporate world code runs every single day, not twice a semester. Its "good enough".
And if it starts to fail it get rewritten, or patched. The truth of the matter is that corporate
systems are long lived, and few if any are fully understood by the current staff, because the guy who wrote it moved on 8 years ago.
And Yet, it gets the job done day after day, year in and year out, because people watch it and know what to expect.
Do houses fall down because of bad 2x4s? Virtually never. Maybe after years of
remodeling, rewiring, re-plumbing, the place will burn down, but there is usually
a recent idiot involved, rather than the original builder.
We build things "good enough" in this world. Not Perfect.
Re:must read: "worse is better" (Score:4, Insightful)
It's not even that. These academic examples are small and trivial. They don't have to adapt or integrate with other systems. They are toy examples and it's really damn easy to make those 'perfect.' How many god damn quick sort examples in Haskell convert to anything in the really real world?
Re:must read: "worse is better" (Score:5, Interesting)
In production you have to know how to apply X, Y, Z, B, E, and G. But you don't start by trying to learn all of them at once. You learn simplistic examples that hopefully teach you the theories and best concepts for 'X'.
Re:must read: "worse is better" (Score:5, Insightful)
True but I haven't seen much academic example code that has plenty of logging in them.
In the real world much good code is filled with exception handling and logs. Because for almost anything that you try or call something wrong/else could happen or something could send you a SIGTERM or similar. You'd leave out the logging in the high performance processing loops, but in the real world those often are only a very small part of the code.
So it's not just most real world code that sucks in the real world, most academic style code would also suck too. ;)
Yes there are different logging systems, but you can pick one or two as examples - after all there are also many computer programming languages and most academic courses still teach at least one programming language.
Anyway the story also reminds me of: http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html [ariel.com.au] ;)
Re:must read: "worse is better" (Score:4, Interesting)
Yeah I still have no idea how to do logging well.
But what I like to do when performance is not an issue is to log everything (DEBUG etc) into a context ring buffer. Then normally only log messages above the configured log threshold will appear in the logs (e.g. INFO, NOTICE, WARNING). The DEBUG stuff won't appear. BUT if a log message above a log the context threshold occurs (e.g. ERROR, CRIT) the contents of the context buffer is logged followed by the actual triggering log. This way I don't have to turn debugging on. It can always be on BUT I don't have my logs full of the debug level logs unless "stuff happens".
This context logging stuff is bad for performance, but so far it's not a problem for the stuff I do (and can be turned off). It does make it easier to figure out what happened while creating less DEBUG noise.
As part of my log messages I also have hashes and dots, e.g.:
DEBUG = one hash = #........
INFO = ##......
NOTICE = ###.....
This way I can easily "grep" log files for logs above a particular threshold. If you're Google or Facebook scale you'll have to do things a bit differently because there'll be zillions of logs, you can't have half a million machines send logs to one log server ;). So you'd need a way to summarize logs.
It might also be nice if the CS lecturers spend some time discussing the merits of different exception handling approaches in various scenarios. Instead of just stuff like this: http://www.cs.auckland.ac.nz/compsci105s2c/lectures/adriana/Lecture06.pdf [auckland.ac.nz]
Doesn't need to be as detailed and extensive as this: http://www.amazon.com/Advances-Exception-Handling-Techniques-Computer/dp/3540419527 [amazon.com]
Just some basics that might open up student eyes to how things work in the real world and more importantly how things could fail, and how one might deal with them.
FWIW I didn't do CS. I did EE. So maybe this stuff is actually covered in some CS courses. I doubt it was covered in my colleagues CS courses though ;).
Re: (Score:3)
Re: (Score:3)
Do houses fall down because of bad 2x4s? Virtually never
Houses are engineered structures. We have building codes which demand so many studs per so many feet because the math (or experimental home building, often experimenting with the buyer's money) has been done to figure out that only a vanishingly small percentage of homes will experience a lumber-related failure if you use at least this much lumber, even though modern lumber is crap in every way except for being milled smooth. But choosing the wrong operator in the wrong function can result in your program p
Re:must read: "worse is better" (Score:5, Insightful)
Re: (Score:3, Interesting)
In their almighty wisdom they thought I wasn't doing as great a job and replaced me with some kid straight out of university who had never programmed in his life. The entire data team crashed, stopped accepting data and had a huge backlog, cos
Re: (Score:3)
Summarized as follows:
"In theory there's no difference between theory and reality....in reality it's the other way around"
Seriously, real world code is by definition 'real world' and doesn't live by the theoretical pillars of design. It has to deal with actual deadlines, finite resources and of course office politics.
True that, but none of those facts intrinsically preclude people from laying out some structure into the code they churn.
Proper indentation, sticking to the object/verb pattern of naming objects (or data types) and methods (or functions), closing the resources you open, programming defensively (instead of nillie willie happy go lucky programming), keeping your functions small. All those things good developers can use and deploy as they put out fires in the real world and all the challenges therein.
A go
Captain Obvious? (Score:5, Insightful)
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
Re:Captain Obvious? (Score:5, Funny)
Re:Captain Obvious? (Score:5, Interesting)
It's even worse than that.
These folks learn the classics, but then go out and are forced to make a living by making new editions of Twilight, Hunger Games, etc. As a bonus, they're not allowed (by edict and budget) to change more than 25% of the nouns (in aggregate, not as categories).
Re: (Score:3)
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
The reason is pretty obvious. The 25-line program you write for a school assignment is not the same as the 5000 lines you are writing to implement a set of vague business requirements.
Re:Captain Obvious? (Score:5, Insightful)
The 25-line program you write for a school assignment is not the same as the 5000 lines you are writing to implement a set of vague business requirements.
Some of those 25-line programs are not so good either. If you really think students write good code, get a job as a TA and grade some assignments.
Re:Captain Obvious? (Score:4, Interesting)
This, and even the *book* is wrong half the time. Given the pressure to come out with a "new edition" every couple of years that many publishers and authors face, they re-write many parts of the books, including examples and problems. Often, it's clear that what the author wrote hasn't even been compiled before, as there are glaring syntax errors. (Obviously, some books are better at this than others.)
Most of the people I work with produce much better-looking code than a college student. Interns come in periodically and help prove that point; they write for ease of coding, not ease of reading or maintenance or reuse or anything nice like that. The code from more experienced people is by no means perfect, but they've at least seen both good examples and bad examples when they have to touch somebody else's code, and they tend to pick up a few of the good habits while dropping a few of the bad ones.
Re:Captain Obvious? (Score:5, Insightful)
Then in school they should be recreating the actual real world experience, you know:
* a representative from the "Business" comes to you with a vague concept of what they want, mostly consisting of "Something like X" but more like "Y" with some of the features of "Z" (3 completely different things that have no apparent relationship to each other). After a few days of meetings you determine that what the person wants is based more on the colors used and the layout being pretty to them and not at all on the features or functionality.
* You then seek out a group of various people who actually know what might be required, and grill them to try to get an idea of the features and functionality required. From this you create an initial design document.
* You run the design document that describes what you think are the features and functionality past the people above who all agree you are on the right track. You add more details and they all agree its perfect. Mostly they don't actually understand what you are talking about but they nod their heads sagely and agree because they don't want to look incompetent.
* You begin coding (or possibly get together with a team and fight over things for a few days/weeks/months) and get a prototype built. You show it to those you have spoken with and again its on the right track.
* You code up the first version. You reveal it to people and its "great".
* Then the people start filtering in with design "suggestions" that mean massive changes to what has been written and done, possibly shifting the entire project in a different direction. These conflict with each other and trying to find the middle ground occupies as much of your time as actually trying to write anything.
* The marketing people come into the picture and it turns out that *they* are the ones that really have the authority to make the design decisions, not the people who you originally talked to, but as an added bonus the marketing people don't have the slightest clue about the required features or functionality - just what they think they can sell to customers. Getting their salable features shoe-horned into the program becomes your top priority now.
* The program also has to look "pretty" so the art department enters the picture and they demand massive changes so that the layout is much nicer and easier for them to do, minimizing their workload as much as possible because they are completely overworked and under-budgeted. You meet with artists in rooms that are completely dark and stare at photoshop images that are renderings of what they see the program looking like. It bears no resemblance to what you have been working on and they have made massive changes to everything renaming all the menu entries etc. It is however pretty, or rather the 3 different versions of it are pretty, and you have to wait until marketing determines which one is the best.
* now you are way off schedule because of all the monkeys who are making changes based on whats the most important thing from their perspective.
* Eventually its all nailed down and you hurriedly code the new first version up as fast as possible because of pressure from above to be "done this thing already".
* At the last moment when its done, it gets cancelled to be replaced by some other project which is higher priority, or they announce it must be entirely recoded in a different language/script.
Shove that student into this environment. Get people to play the various roles that are about as knowledgeable as people you will encounter in the corporate environment - which is to say find the most qualified idiots you can and put them in the roles.
Re: (Score:2)
Re: (Score:2)
Because an incredible percentage of products get canceled and the marketing people have learned not to waste their time on some shiny new idea that's probably going to get canceled anyway. Wait a few months and see if the project survives and it's worth investing your time, because if you touch/interact with a project and it's canceled, that of course makes you look bad and has wasted your time. There's the additional benefit that, if the developers are late, that gives you a scapegoat if your marketing cam
Re: (Score:3)
That's not the way businesses operate, and the larger they are the more layers of BS things filter through. The person who champions the project hands it off to a subordinate, who hands it off again, etc. By the time it gets to the poor sap who had to bid out the project you're lucky if you get a cocktail napkin sketch of a UI concept and a few vague notes about what it should do.
There is another form of this that I deal with quite often, where upper management concieves of something that is totally impra
Re: (Score:2)
Honestly, this should be the final project of any decent software development course.
Re:Captain Obvious? (Score:5, Interesting)
Re: (Score:3)
Even your longer example doesn't do enough justice to how much of this problem is management based. This article was terribly biased toward blaming programmers for these issues. Schedule pressure to release on a date no matter what causes more bugs than anything else. Having some sort of deadline is necessary; if left on their own, programmers like to tinker with stuff forever. But you can only compress things so much, and management requirements are often impossible to hit. The standard example here i
Re: (Score:2)
Of god that is so true it is not even funny. :-)
"Politics" (and ego) is the number one reason "Real World" software sucks so much.
--
"If engineers built buildings the way programmers write code then the first time a woodpecker came along it would destroy civilization."
-- Murphy's Computers Laws (Murphy was an optimist!)
http://www.murphys-laws.com/murphy/murphy-computer.html [murphys-laws.com]
Re:Captain Obvious? (Score:5, Funny)
* Meskimen's Law: There's never time to do it right, but always time to do it over.
* Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent.
http://www.panopticoncentral.net/2010/08/01/murphys-computer-law/ [panopticoncentral.net]
Re:Captain Obvious? (Score:5, Insightful)
That implies that all of those people care to spend the time meeting - and they often don't - and also know or are willing to listen to a detailed explanation of what is involved - and they aren't or are not capable of it. Everyone knows the problems, no one admits to their part of the problem.
Also management tends towards Seagull management - arrive suddenly, shit all over everything until everyone is worked up, then leave. Rinse, repeat until the project is done or cancelled.
Honestly I have been through this sort of cycle a few times, and despite the best efforts of the developer side to get management to agree to the design document as defined, the end result is featuritis, people sticking their nose in who shouldn't be able to but who are higher up in the food chain than you (or anyone else in development) is etc.
Half of the art of software design is dealing with people who don't understand it, or care to learn.
Re:Captain Obvious? (Score:4, Interesting)
The creaping featuritis thing amazes me to this day. I am a codeslinger, if you want it I'll write it. But I will tell you if I think you're making a mistake.
One of my old bosses put it well when a customer was questioning my opinion on some of their stuff I was pushing back on.
"If he thinks it's a bad enough idea to tell you that you shouldn't have him do it, you should f'ing listen. You do remember he bills by the hour? If he's telling you it's not something you want him to do he's doing you a favor. And if he won't do it there's no way in hell we'll do it for you, he's the guy we send people to for crazy shit."
Re: (Score:3)
...to say nothing of the fact that instead of writing a program from scratch, you're forced to maintain others' programs instead, or to add what you write to existing (fundamentally crap, poorly-maintained) code.
Yay?
Re: (Score:3)
I recall reading about someone being brought in to replace the (sole) developer for a key piece of business software because the previous one had been fired. (Caveat: I have no idea if this is true and can't recall where I encountered it).
They opened up the source code to give it a check and discovered that the previous developer had used variable names that varied mostly in the number of letters used. So you had variables named like:
$m, $mm, $mmm, $mmmm, $mmmmm, $mmmmmm,
$sa, $saa, $saaa, $saaaa
and so on. N
Re: (Score:2)
Not at all, most of the real world problems are problems you see solved in academia, very well. The code quality is a direct result of the "coding to the business need" principle, where everything is done based on a business identified function/schedule.
The persistent problem with purely competitive environments is that there will always be an incentive to beat the other guy, at any cost.
Re: (Score:2)
Perhaps more precisely, that the code produced in the "real world" is often "graded", in the immediate term, by a PHB that will be satisfied if it superficially appears to work (they'll eventually get upset at the costs produced by less-obvious defects a
Re: (Score:2)
This just in: real world a lot harder than school.
Gee, thanks Slashdot!
PHB: Nonsense! Programming is dead easy. My 10-year-old nephew wrote a program just the other day. It makes a little square box bounce around on the screen. We don't need these overpriced prima-donnas spouting techno-babble about Separations of Concerns or stuff like that. A half-hour and you can have web pages on the screen and ready for production tomorrow. All You Have To Do Is...
Obligatory XKCD (Score:5, Funny)
same... (Score:3, Insightful)
It's no different than business school examples vs real world practice.
Re:same... (Score:4, Funny)
And English class samples (such as books and essays that they have you read) versus the comments you read on YouTube.
Sounds like sour grapes to me. (Score:3, Interesting)
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.)
I think he's mostly correct (Score:5, Interesting)
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.
Re: (Score:2)
Given (Score:3)
It's "rarely acknowledged" because it's just a given...
School code (Score:5, Insightful)
The goal of textbook code is to be readable, to communicate, not to handle every possible case. This means industry code is often less readable, but more solid. I'm sure I've missed other ways academic code is bad.
Of course a lot of industry code is unreadable and also not solid. That's another issue.
Re:School code (Score:5, Insightful)
I'm sure I've missed other ways academic code is bad.
The biggest difference is that academic code is _short_. If your whole code base is 10k lines, it's easy to cover all the requirements in a clean design. If you are dealing with millions of lines, there's all kinds of oddball unforeseen interactions and requirements that pop up way late in the game.
Re:School code (Score:4, Insightful)
This is what I came here to say. (Disclaimer: I'm a hardware engineer and most of the code I write is in HDL.)
There are two factors at work.
1. With the exception of big thesis-style projects, most academic work is scoped for you by the nature of the assignment or the teacher. This is almost never true in the real world.
2. When options are available, the proper way to write code is the way that is most readable and supportable. However, the most readable way to write a given piece of code varies by its scope.
Thus, as you work on real-world code, you might design something a certain way because it's the cleanest, most readable way you know. Then, later, as the scope of the project is made more clear, either through your own investigation or through changing business requirements, you have to modify the code, but you don't have enough time to toss it all out and start over with a new design that is the most cleanest, readable way to do things given the new requirements. This is most especially true when the scope changes in little steps, each one of which seems small enough to not be a big deal.
My example is with state machine design. For a simple system that moves between a few states and has a few Moore outputs, a single-process state machine with good state names and a few comments is readable and supportable - it all fits on one page. But if I'm designing a 50-process state machine to handle a big, complex process (and can't break it down into multiple machines for timing or whatever reasons), then I'll use a multi-process state machine, with state and nextstate separated, and probably a dedicated process for each I/O or group of I/O signals, where each one can get it's own page-sized bit of code and comments. The latter style is much harder to read and follow for simple systems, but if the former type morphs into the latter type, I need to cut it out and start over. That's only possible when time permits, and I don't own my time when I'm on the job.
And all of this assumes that you even bothered to write the code the most readable and supportable way the first time. Far too often the first time code is written, it's written to get "something out there working" so the analog guys or marketing can test their stuff or show it off. And then you don't get time to even fix that code into something readable in the first place. With a project manager and a few software and analog engineers waiting on you, demanding time to do things right the first time can be challenging.
Re: (Score:3)
Textbook code is meant to illustrate only the thing being discussed. A book would be less readable if every snippet contained the proper boilerplate for exception handling, pre-execution checks, malloc+free tracking, etc... That's usually covered in separate sections, and the professional coder should be aware of the need even if K&R didn't lecture him on it.
Re: (Score:3)
Good as in what?
Good as in "pedagogically sound"? As that is the sole purpose of the code in question, if it meets that criteria, then it's good code.
Colleges and universities aren't trade schools, you know.
No surprises here. (Score:5, Insightful)
- specs change constantly
- need to work with crap that's already there
- there are deadlines
- need to get stuff done
And I'm pretty sure I'm forgetting some other points.
Re:No surprises here. (Score:4, Insightful)
- Requirements are messy (even not counting the fact that they change constantly)
- Textbook code is designed to look clean, but often ignores important edge cases for the sake of simplicity. (See previous point.)
- Cleaning up the code may potentially introduce bugs, so once the code gets past QA, it's often considered untouchable until a demonstrable problem is found.
I'm sure there's even more...
(Test-Driven Development (TDD) is supposed to help address that last point, but A) it's not always perfect, and B) it's not universally used.)
Re: (Score:3)
I rather take the blame when a new bug is introduced by refactoring a piece of code so it can be used from multiple sites, than create another duplication. I then usually mumble something a
Re:No surprises here. (Score:4)
- No one is willing to fix code that already exists because it works "good enough"
- No one is willing to expend the resources (read time and money) to go back and rewrite bad piece of code.
- Fear of new code exposing how bad the other code is.
(32 years of real world coding.)
Re: (Score:2)
Re: (Score:3)
Another one: in real world you get stuff wrong.
School v. Reality (Score:5, Insightful)
This just in: Examples provided in school have no practical real world application. Duh. In the real world you have things like deadlines, bosses, and clueless managers. When you screw up in class, the teacher tells you where you messed up and you get a chance to do it again. In the real world, when you screw up you probably won't know what you did, at least not right away. And you're going to have to figure it out while everyone is mad at you, calling your phone, and asking why it died.
I don't know where this idea of the Zen Programmer(tm) comes from with visions of calm blue waters and bright bleached sand and everything is calm, thought out, and composed. Programmers I know hammer down mountain dew like it's nobody's business. They do not spend months debugging and thinking about it academically: If it works, you move on to the next thing. Don't bitch about the quality of the code (manager or academic) in the real world because there are almost no programmers in the corporate world that sit around thinking in O notation and figuring out the best and worst case scenario for every line of code. They bang out 500 lines in a few hours and then hit compile and hope to god it works on the first go.
That's reality people -- you don't have the time, the resources, and if you took the academic attitude to work with you, you'd be cut up and used as shark food by everyone else for being so damn slow and pragmatic when they need things working tonight so they can go home after being there for 15 effing hours to make the latest milestone.
Re: (Score:3)
Really? Generally speaking, when I was in school, when I turned in a homework assignment, I was told where I messed up, and then went on to the next assignment. Only rather rarely was I given even one assignment to fix any of my previous mistakes, as far as coding went, and the only time there was any kind of "keep fixing it until it's fixed" mentality to any school-related project was my whole-year-long senior project... which was part of a program designed to give us real-world experience by giving us act
Re: (Score:2)
Real world code is not like the code students are assigned in school.
Re: (Score:2)
when I was in school, when I turned in a homework assignment, I was told where I messed up, and then went on to the next assignment.
Me too. They changed that though when the parents complained that their precious snowflake wasn't getting first place in everything; So they abolished competitions. Now there's no such thing as an 'F' in many schools, and they have about half a dozen more letters to represent just how exactly their kid didn't 'F'ail. It is (as my teenage sis would say) "ridonkulus".
Yes, sometimes due to deadlines (or simple cost-benefit analysis), not everything will always be perfect when it ships, but I'd certainly always take code written by a company and designed to be shipped, over code designed to be written and turned in as a homework assignment...
So would I: Because there's a use for one, rarely for the other. Articles like this are like saying "We shouldn't use cars because they pollute"
Re:School v. Reality (Score:4, Insightful)
Don't bitch about the quality of the code (manager or academic) in the real world because there are almost no programmers in the corporate world that sit around thinking in O notation and figuring out the best and worst case scenario for every line of code. They bang out 500 lines in a few hours and then hit compile and hope to god it works on the first go.
That's reality people -- you don't have the time, the resources, and if you took the academic attitude to work with you, you'd be cut up and used as shark food by everyone else for being so damn slow and pragmatic when they need things working tonight so they can go home after being there for 15 effing hours to make the latest milestone.
You're working with the wrong programmers then. See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone. By the way if you're working 15 hour days it means you're mismanaging your manager and their expectations (and/or you suck at your job).
Re:School v. Reality (Score:5, Insightful)
You're working with the wrong programmers then.
Yes, because it's always possible to work with the best programmers the world can provide. In the *real* world there is a finite availability of top programmers, and they might not be working where you are.
You show yourself to be very naive if you think that every business has the time to let you do TDD, and will provide you with a perfect, experienced team of developers.
Re: (Score:2)
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.
Wow, speak for yourself. I DO think of this on every line of code I write.
Of course, the vast majority of code is either O(n), O(n^2), or O(1), so usually this isn't actually hard, unless you put vectors in your stacks or something.
The question is, why aren't you thinking about how long your code will take to execute?
Re: (Score:2)
so what you're saying is that programmers need to stop being such fucking wusses that they put up with shit working conditions like 15 hour work days?
or maybe they should form a union.
Re: (Score:2)
Hardware and software was a lot simpler back 30 years or more. One of our courseworks was to write keyboard and network card device drivers along with a text editor and simple chat programs. A keyboard driver could be written using BIOS interrupts in page of code. Same with a network card driver and text editor/chat program. Even source code control was done using SCCS which meant that only one file could be checked out at a time by one person.
Applications programming was straightforward - create a main win
From the article (Score:2)
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?
Re:From the article (Score:5, Funny)
The last page bashes Haskell using a snippet from Uncyclopedia as anecdotal evidence that it is "all but impossible to write readable code" in Haskell.
Beyond it is another dimension: a dimension of whinge, a dimension of fallacy, a dimension of diminished journalistic integrity. You're moving into a land of more shadow than substance, of vague and half-baked wit; you've just crossed over into the Register.
School != World (Score:2)
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.
In Other News... (Score:5, Insightful)
Water is wet, the sky is (perceived as) blue, the world *did not* end, etc.
On a more serious note I wouldn't describe any of the code examples I encountered in school as perfect or "well-thought-out" specimens." Nearly every one of them was a trivial case which ignored most error cases and expected the client human/system/software to be well-behaved. I've often thought that Comp. Sci. students (3rd or 4th year) should be forced to pick up someone else's code and refactor it into something workable. I'm not talking about the disgustingly huge and unmaintainable messes that we work with out in the real world, but something big enough to give them an inkling of the kind of scope they'll be expected to deal with.
I also think that if you're not learning TDD in school these days you're not getting your money's worth, and you'd actually be jeopardizing your career by not learning this early, as it is a life-saver out in the real world.
A soccer team analogy . . . (Score:5, Insightful)
In the academic world, if you were tasked with picking a perfect team, you would steal players from Real Madrid, FC Barcelona, a fistful of Germans, Franck Ribery, etc.
In the real world, if you are tasked with managing a programming project, you don't get to pick the best. You are given some young kids with more energy than sense, an old, wise, but disgruntled experienced guy, who nobody listens to, a few folks who really don't give a damn, and most of them really truly detest each other. So you try to make out as well as you can, with what you've got.
Hey, Mercedes are great cars, why isn't every car built like them? Well, not everyone can afford a Mercedes, and maybe most folks can get by with just a Ford.
It's just the reality of life vs. theoretical academics. Despite the physics problems you solved in college, there are no frictionless surfaces. Or the ones that are available, you just can't afford.
Re:A soccer team analogy . . . (Score:4, Informative)
Wrong. My Benz has 11 airbags. My Fordrd does not. My Benz has massive brakes that can bring me to a stop in 1/3 less distance. The list goes on and validates the previous posters point.
most claiming crap code (Score:4, Insightful)
Most of the time the person claiming the code is crap is the one I find to be most to blame.
other way around? (Score:2, Interesting)
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" pr
Academic (Score:2)
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.
Re: (Score:3)
IME, the exact opposite is true; code in textbooks is far more often to address a specifically defined problem domain correctly (often, a problem defined in such a
and in IT / admin jobs CS is way off base to the p (Score:2)
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.
Obvious Observation, Misleading Conclusions. (Score:5, Informative)
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.
Re: (Score:2)
You make a good point about greed, but I think it's "e. all of the above."
I have seen developers that were so bad they couldn't write anything good if they tried. Managers typically don't know enough or don't have time to do anything about it. Besides, they are already trying to add 2 more people. If they fire that guy, they have to add 3.
The worst failures we have at my current company (which hires very well) are problems caused by too smart developers being too clever, creating code that is unmanage
How to make real code that is good (Score:3)
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.
communicating well is hard (Score:4, Insightful)
From TFA: "Good software, misleadingly, is usually easy to read, but it’s not easy to write."
What is misleading about that? The same could be said for any of the formal mechanisms we've invented for expressing our thoughts and ideas to other humans. Good oratories, good lectures, good books, good journal articles, and so on, are all easy to consume, but speaking or writing well requires tremendous effort and practice.
Amount of code (Score:2)
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
Just like the Boy in the Bubble (Score:4, Interesting)
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!"
Perfect is the enemy of good (Score:2)
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."
The Author Clearly Never Had A Job As A Programmer (Score:2)
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.
Best code I've seen ... (Score:2)
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
Related, featured on /. a few months ago (Score:3)
The Atlantic: Bad software runs the World [theatlantic.com]
You think that's bad (Score:5, Insightful)
Obviously the author has never tried to untangle outsource code. If he thinks home grown code is bad, wait until he wades through a bowl of Bangalore spaghetti code. Yummy.
Although I did make a lot of money sorting through that crap. Many companies would just assume outsource code would work when they needed it and couldn't figure out how come their wonder app, that they got done for half of what U.S. programmers would have cost, kept crashing.
Re: (Score:3)
It's all relative (Score:3)
The real world sucks, the code is just inside it (Score:2)
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 beg to differ with the author (Score:2)
Real world code rocks (Score:2)
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.
Reality (Score:3)
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.
the best companies have both (Score:4, Insightful)
Crankers bang out code like there is no tomorrow. When good managers find these people, they immediately put them in the department of developing new features. Competition is fierce, and a lot of times it doesn't matter about quality but about who gets there first. End of story.
Strokers take their time with code. They are fit for the "support queue," debugging, and any specific jobs that require needlework precision. I work in this department. I fix a lot of code made by Crankers, taking in both memory-efficiency and speed-efficiency. So when a customer finally does have 10,000 loads which the Cranker didn't foresee in his/her code, I fix it, and the customer is happy. I also provide a lot of options to the user instead of forcing the user down one path. Lastly, I do jobs that require excellent quality. Do not give money-critical new features to Crankers; give them to Strokers. I actually have used a lot of the the computer sciencey things that I learned in college like Big O, various Dijkstra algorithms, etc.
Tweeners are the in-betweens. They are good for the basic infrastructure/architecture. They write the base library fast and with decent enough quality. For example, they may write layers around the database, GUI, etc. to make life easier. If you don't have a Tweener, then use a Stroker. If you need the product out fast though, use a Cranker and then a Stroker later on to refactor, or use a Cranker and Stroker in unison.
To make a killer software company, you need all three. And the companies that last a long time, have managers that know how and where to place these people.
Call me crazy (Score:3)
It's Terrible Because Nobody Wants to Pay (Score:4, Interesting)
Re: (Score:3)
Are you kidding? I do systems programming code all day In C/C++, and the hacker code in the ANSI C book is a steamy pile of crap. We would have security problems, and hard to find bugs all over the place. This is not to mention that our static analysis tools would prevent such code getting into our code base.
Try the Enterprise Java books, instead. J2EE has a built-in security framework. It's not very sophisticated, but it's well-tested and it intercepts many types of exploits before they can get anywhere near the application code.
On the other hand, I've seen many DIY login/security systems over the years and most of them are total tissue paper security-wise.
So what do all the Enterprise Java books use for examples? DIY login screens!
Re: (Score:2)
Hehe, systems programming in Java, that would be a thing.
Re: (Score:2)
Re: (Score:3)
Crappy, hard to maintain code helps you stay employed
How would you feel if the people that made your car shared that sentiment? It's attitudes like that that give the profession a bad name. Take some pride in your work and don't be the guy that's cursed by everyone who comes after you.
Re: (Score:2)
Now, go back to your bitching about nonsense.
And don't forget to apply the only insightful solution suggested by the article (after whining about various kinds of crap you should expect in real-world code, the last phrase):
there’s one simple and completely painless way to prevent future generations from cursing you when they look at your code: Include some comments!
If you can explain what your are doing, good chances that your code has some merits. If you can't, then nobody will be able to understand it.
Re: (Score:3)
Ah, Slashdot... where a post about the importance of "people skills" can't go for more than a sentence without calling someone a "moron" or an "asshole".
I get the feeling that Anonymous Coward was actually this guy [youtube.com].