A very good friend of mine is in the midst of an avalanche of work. He has a lot of open contracts, and has been abandoned by a fellow developer that was helping him with his workload. So, with three huge clients breathing down his neck he has been working non stop for weeks now.
One client contacted him about the iPad application he is building for them, he let him know "I paid another developer to look at your code, he says it really sucks."
When he told me this story, I had to chuckle a bit, and think of all the times I had decided that other people's code sucked. When I first started out, and I looked at code that definitely sucked hard, I scrapped it, and started from scratch in a way I knew was way better. As I matured I looked back and realized that what I had destroyed was a well accepted design pattern, and what I created was a mess of a mess pattern.
Lesson learned.
After some growth I encountered code that I thought sucked ever so often. At this point I wasn't decimating things all together, I would find specific parts of code that I found intolorable and rewrite it. About 9 times out of 10, when I got more than halfway there I'd run into an issue that made me say "Ooooh, that's why they did it that way" and revert it or use the same "sucky" logic with my syntax.
Now that I am a little more seasoned, I can tell you with all confidence that I never look at a solution that someone else created and say "Oh, this code sucks." I know that there really is no quick way to tell if code is good or bad without understanding the entire solution. Sure, sometimes things can look sloppy, or poorly done, or undocumented (in my case, not self documenting), however, you never know what was going through the head of the developer that wrote it. More often than not there is a reason why they have done things this way, and there is no hard and fast way to tell what the context is without being elbow deep in it.
So, when I hear that someone has looked at someone else's code base and determined that it sucked I smile and remember what it was like to be so new and sure of myself. So sure that I was an amazing developer, and that I knew what was best in every problematic situation. I miss that swagger, but I appreciate what I have learned, and that is the only person's code that sucks is my own, and the reason why it sucks is I just haven't learned how to make it better yet.
What a wonderful concept! Perhaps the title of this post should have been "ONLY YOUR Code Sucks." That's something every developer should take to heart. I've seen the same thing in my day: developers who think they're so amazing they can pass judgement on a 10K-line codebase after thirty minutes of casual perusal.
ReplyDeleteThis reminds me of the introduction to one of the programming books I've read: "Good software, first and foremost, works."
All concerns beyond that are fodder for pontificating programmers. No one else cares.
Very solid and responsible perspective to have. It is very easy to glance through code and dismiss it as the work of a hack, instead of trying to learn from the mindspace they were in when they wrote it. Just because something is done differently than the way you would have done it does not make it bad/sucky. I always tell myself - "there's always someone more clever than you."
ReplyDeleteSometimes it really could just be the Dunning-Kruger Effect. :)
Nice post, regardless.
I almost agreed with you, I do remember that I use to say "Why did he do that that way? it's too long" or "It's too much code for that tiny task..." when I was young and looked at some design pattern that I didn't know. But now with a lot more experiences I still tell people their code sucks, not because the developer itself sucks but because the way how he works the problem out at THE moment sucked...
ReplyDeleteI know that if the same developer looked at the same issue at the same time than me (after he developed it), he probably will do it differently. If he doesn't see his mistake... That it's another problem!
Also in my opinion the code is just 10% of the work so the sentence you code suck is actually not meaning what you really mean.
In the case of your friend, you have to add the fact that the new developer want the job... And as a human being is always going to lie to get what it want. More I know developers who make the client feel like he needs to redo everything when he actually just change two lines of code, and charge the client for a brand new full application.
more about being tactical than anything else..
ReplyDeleteyou will probably find that there is something particular wrong with just about anyone's code persay once doing code reviews as there are about 50 million ways to skin a snake.
as long as it does what its supposed to do and has no fundamental issues (i.e. standard memory leakage, performance tie ups, security flaws) .. who is to say what is right and wrong as it fulfills the previously stated requirements
nice post.. I think the best way to comment about someone's coding is to pair with them while they're coding. This way you're closest to their thinking and the solution.
ReplyDeleteMost other techniques have high degree of inefficiency.
Well put. Thanks for sharing
Good advice. When I have to disassemble someone else's code I usually have to force myself to stop from jumping right in to "fix" something. I have now learned over time to take the time to sketch out on paper the logic flow and dependencies so I don't back myself in a corner further down the road. As you pointed out, many times it is not obvious what the developer is doing until you take time to really study it. One of the first things I learned was structure, structure, structure.
ReplyDeletesee, this is why you add comments to your code...
ReplyDeleteI will say this much: it is always a treat to see well constructed and easy to read code. But I will also say that one of the issues I almost always run into, mainly because I do a lot of database work in addition to development, is that databases and SQL code written by others nearly always DOES suck. And more than anything I just blame people's inexperience with database design and development, because a lot of developers just do "whatever works" to get the database running and don't consider normalization, indexes, well chosen keys, et cetera. Whenever I see a retail application (that I need to integrate with or pull data from) running on top of MS SQL Server that has ONE BIG TABLE in it, I twitch uncontrollably.
ReplyDeleteYour post reminds me a lot of how my eagerness to proclaim "your code sucks" has changed as I have matured as a developer.
ReplyDeleteIt is harrowing to learn that you don't know everything, but a crucible through which you must pass in order to really grow as a developer.
All code can be improved upon. I look at code I've written a few months ago and say "my code sucks" on a regular basis.
In the absence of a fully functional automated test suite - refactoring or scrapping code that currently works is dangerous and can be only marginally productive until you understand what the current code is doing and why.
Lately, I would rate code on two main metrics
- How well does the code work?
- How easily can the code be changed?
Love the new http://girldeveloper.com site design.
Learning to say "My Code Sucks" can be a good thing too...
ReplyDeletehttp://coderoom.wordpress.com/2010/04/22/7-reasons-to-hate-your-code/
I think its a human tendancy to think that whatever one does is the best. Looking at others code and not understanding it completely might make one think that its not written correctly.
ReplyDeleteI have personally learnt a lot by looking at the code others have written. Some of the things like simple design and proper naming conventions as well as consistancy in naming go a long way in helping understand the code better.
I've learned that the hard way quite a few times.
ReplyDeleteThough, if I think something can be done more efficiently i'll take some time to redo it but only after i've studied every step of the other persons code.
This reminds me of the old Joe Spolsky article, "Things You Should Never Do, Part I". ( http://www.joelonsoftware.com/articles/fog0000000069.html )
ReplyDeleteOn the other hand, there isn't always some deeper reasoning behind sucky code. Sometimes, even after you understand it completely, it really does just suck.
I can't even count the number of times I've declared that some code sucks, and then discovered via version control history that I wrote it. Working on the same code base for six years can be a humbling experience.
ReplyDeleteAnother alternative is that the code does suck; but the original code was pretty good. But then another developer went in and made some changes without fully understanding what was going on; and then another developer did the same thing; and the first guy left for another opportunity, and eventually...well, things were the way they were because they got to be that way.
ReplyDeleteI'd have agreed with you up until a few weeks ago, when I inherited the worst code I've ever come across, after more than 14 years in this business. Not only is there no internal logic, there are sections where someone began writing something and just quit in the middle, so parts of the code simply don't work. Oh, and there are over 6000 lines of aged PHP code - every possible function for the entire site is on one page (oh, and there was no version control of any kind - it was all live, as if we went back to 1996). It's a perfect storm of bad code (and that's coming from someone who's certainly been guilty of writing my own bad code in the past). Sometimes, you really do need to scrap it all and start over - but I agree it's rare.
ReplyDeleteThis is why the commit comments when checking in code are so important, you should write _why_ you made the change, not what you did. I can see what you did by looking at the code.
ReplyDeleteAnd some code definitely does suck (not mine... ;)
Ingo Rammer used to be fond of pointing out (and he might still be) that no one comes to work wanting to a do a bad job. They do a bad job because they are constrained by budget, timescales, distractions, process, knowledge or experience.
ReplyDeleteAn all too common experience for all of us is that a client prioritizes delivery on a given date over quality (BDD/TDD etc) and then complains that the quality of the code is poor. The problem is that they did not pay for code quality, but time-to-market.
So the question is often better phrased as: why did we not match process to expectations better?
Your post sucks!
ReplyDelete(just kiddin' :)
But actually, I mostly disagree with the main statement that says that usually the code doesn't suck, or that you can't really tell..
I've been teaching programming and software design for years, and worked as a code/design reviewer.
Code CAN suck (or just be not that good) in ohhh so many very noticeable ways..
Code can be unreadable or not readable enough. Coding standards, naming conventions, and of course good name choosing - These are all fundamentals for proper coding. Coding is in many aspects like writing (human language). Not all people write properly. Actually, most people do not! The code should be self-explanatory (good code rarely needs comments/documentation).
And what about code reusing? So many bad programmers tend to use code duplications (sometimes large and noticeable portions, and sometimes small but still avoidable ones).
What about all the rest of basic design issues like good encapsulation, loosely-coupling, modularity, plug-ability, scalability, maintainability, performance, etc.
Some faults regarding these issues can be very easily noticed in a quick code review. It is important to state, though, that code/design review should be held along with the one who wrote/designed it.
To sum it up - Sometimes you can easily look at some code and say it sucks, in a large range of ways. Sometimes, the code doesn't suck, but it can surely be graded and/or get reviewer comments and should be re-factored. This is what code reviews are all about, and they are very important.
P.S.
I strongly disagree with the one who commented and quoted the phrase "Good software, first and foremost, works".
I often tell my students that "It works!" is not the target of your work. far far from it.
I often look back at code I've written and think to myself, "What was I thinking?". At some point of time I started writing stories about why the code ended up the way it did. Most often this would be as a commit message in version control, or part of the bug that the code was for. Now whenever I ask myself that question, I simply look up version control's annotation for that line and I know.
ReplyDelete@Mike Caprio: Even in the database case, sometimes you really do have to have ONE BIG table because that's the best way to solve the problem. I had a case where I needed to sustain 6000 inserts per second forever. Having multiple tables would have made this impossible, so I had to throw out fields that were not essential, and denormalize everything else. I finally ended up with two tables but designed in a way that it was okay to insert bad records into the second table as long as they weren't referenced in the first. The system sustains 8000 inserts per second and has been running for 2 years handling several terabytes of data.
On my last contract I was called in to replace another contractor who didn't care for the code in a few of the base classes. So, naturally, he rewrote it. The size of the projects that rested on those base classes is literally beyond my ability to describe. Suffice to say it that size-wise it was something along the lines of MS Office.
ReplyDeleteRacing against the inevitable deadline set in stone by the Marketing Department, the unsung heroes of IT did a build, tested a few sections they knew had been modified, shouted down all objections and released the new version into the wild.
It blew.
The resulting rock slide was unfortunate in that it didn't hit marketing. Too bad. The code, by the way, didn't suck.
Nice said!
ReplyDeleteI will remember this post when I graduate from school and become a developer.
I think actually the truth is that almost all the code out there does suck. There is huge swathes of code that has no tests, has long methods with high cyclomatic complexity and has badly named variables/methods/classes etc all over the place.
ReplyDeleteIts really easy to spot bad code in an automated way. Code coverage + cyclomatic complexity/method length tell you in an instant that the code base sucks and almost all code bases fail this most basic of tests. Of course as a test it can't find all code bases that suck, only the ones that did the bare minimum to try to not suck. The design can still be utter rubbish, but at least you've got some tests so you can start to change it.
This is the quote I always think of when ever any developer says "that code sucks", with out knowing any context of the problem:
ReplyDelete---
* your program (n): a maze of non-sequiturs littered with clever-clever tricks and irrelevant comments. Compare MY PROGRAM.
* my program (n): a gem of algorithmic precision, offering the most sublime balance between compact, efficient coding on the one hand, and fully commented legibility for posterity on the other. Compare YOUR PROGRAM.
---
I wrote about this a couple years ago on my blog:
http://coderjournal.com/2008/05/software-developers-never-change/
Welcome to experience!
ReplyDeleteNice post. I have seen plenty of crappy code in my life and written plenty of crappy code. And I have had to maintain plenty of other people's crappy code. And no, I am not saying all code I saw was crappy. :-)
ReplyDeleteBut I am not buying the general argument. In my experience there is a line. There are some things that can be contextual to the environment, requirements etc. There are other things that there is just no excuse for EVER. For example magic strings all over the place, cryptic variable and method names, overly complex monolithic methods, high coupling / god classes. There is no value to gain by doing these....it is just sloppy.
Now that being said....it takes time to learn how to write good code (a lot of time). It is a continual learning experience.
I laugh when I look back on some of the horrendous code I wrote in the past, some of which was mission criticl. I feel good when I look at the code I write know because I say how much I have learned, Two years from now I will look back and say it sucks!
That's all good though, that is how it should be!
Recently I was contacted with an offer to take over a project. The owners of the company were adamant that the developer who had abandoned them was terrible and the code was awful. When I looked at it, it seemed pretty decent. As I talked to the owners about the project it was clear that the problem was not the developer. It was clear that taking on this project would be a *really* bad idea.
ReplyDeleteI remember when I was younger I probably would have though the code did suck, especially after getting introduced to it with nothing but negativity. It is nice to know that as I've matured in my technical ability my own humility has come along for the ride.
I still make internal assessments that someone's code sucks, but can also say the same thing about my own code when it does suck. I can generally also tell you why it sucks and why decisions were made to contribute to that suckiness, either in code comments or in a ticket system someplace.
ReplyDeleteWhat *really* sucks is getting code that has obvious bizarre aspects to it, and having *no one* to ask why it was done that way. Yes, I completely understand people get in to binds and don't always know the most elegant way to do something, or perhaps they are simply being pragmatic and cutting the least important corners. But for goodness' sake, document why you're doing something you know to be suboptimal.
It creates a bit of empathy on my part when I'm having to take over your sucky code.
The code very well may suck because client X has changed their mind 5 times on a fixed bid project, and the developer is just making something barely functional to get their check and get out of the hell that is that client and/or project. Fine - been there, done that. But document that so others coming after you have some notion of why you left the code (or the whole project) in such a state - it may save future generations a lot of headache.
An earlier comment - "how easily can the code be changed?" - is a key that I use when evaluating both my own code and inherited code. That 'change' may be made easier by sane variable names, good structure, documentation (historical and logical), and lots of version control history. Trying to rollback to a commit which has 92 changes (not 92 changed files, but 92 distinct changes addressing loads of different issues at the same time) is a horrible experience. It makes the version control almost worthless, and possible dangerous.
Another bad example of version control use: I've got a colleague who is working on a project with a team who don't like to use version control because it keeps bumping the numbers up. After 3 years, they had collected about 45-50 commits, on a codebase with hundreds of thousands of lines. My colleague had done 8 commits in a single day, and was told to not do so many commits because it was confusing things. Rather than tagging, they just rolled up everything in to one commit, and everyone 'knew' commit 43 was 'live' at a certain time.
Take the time to understand the tools you use - it'll help make the entire experience of dealing with your code (and that of others) less sucky.
BTW - I'm *guilty* of all the things I'm bitching about here, am aware of how to get better, and moving in the right direction. If you've ever had to deal with my code from 5-10 years ago, I apologize.
When people compare themselves to others, they compare themseles at their best.
ReplyDeleteAlmost everybody writes shitty code when they have to fit into time constraints, to fit in with existing code, etc.
I agree with your post, but on the other side of the coin perhaps if the other developers had better comments you wouldn't have had to code half of a module before you understood why they did it like that. Same for the normal design pattern. I had one project where a previous programmer had to deliver source code as part of contact. He ran the source code through an obfuscater and at the top put this comment that said: "Good luck with this Superman." Thats the only rewrite I have ever done.
ReplyDelete-James
No, sometimes code really truly does suck. But that's why there are mandatory code reviews :)
ReplyDeleteWith maturity all code no longer sucks but some code still does suck. Usually the flaws are obvious and specific. Coder doesn't use any classes (or even functions). Code has lots of security vulnerabilities, etc. You've learned a better attitude but I'm not convinced you learned to code.
ReplyDeleteThere's one certain aesthetic to good code that differentiates it from shitty code at a moment's glance.
ReplyDeleteGood code tells two stories the same way; one to the computer and one to humans. If those stories diverge, the code sucks. The suck code that can be differentiated so fast is code that lacks in the human story.
I've seen that programers whom write well are able to both produce excellent code and quickly pinpoint this common case of bad code. For other cases, it can be hard to judge whether something is elegant or over-engineered without wrapping your brain around the whole problem.
my stinky stunk
ReplyDeleteEverytime I look at code and think "this code sucks" it's generally for the following reasons:
ReplyDelete- Poorly formatted code... writing this is not good:
for (int i; i 9999) { while (true) { if (i > 99999) { break; } else { i++; } } } else { continue; } }
- Poorly defined naming conventions. Global variables should be instantly recognizeable. As should Properties, public/private methods, etc.
- No comments / poorly named methods and variables (either use comments or variables that have decent names .. doesn't have to be both unless even with good variable / method names it's tricky to understand)
- Methods that do too much for no reason ... addXtoY(int x, int Y) should not return (x+y) * 3
- Finally, code logic that's repeated multiple times. Shows a lack of forethought. A particular piece of logic that gets performed multiple times should be in it's own method / helper class
If you break too many of those rules too many times.. your code sucks. If I look at your code + documentation and have to spend 6 hours trying to figure out wtf you were doing in addXtoY(int x, int y, int z)... your code sucks.
Your business logic must be valid. But for me, your code should read clean, should be well laid out, and should be documented (in some form).
Plain and simple.
I read code that sucks all the time. But I've been doing this long enough that finding code that sucks doesn't mean I delete it and rewrite it — I just fix it, so it stops sucking.
ReplyDeleteThere are three main reasons code deserves the crown of "suck", and they are
1. Sloppiness
2. Lack of comprehension by the author
3. Laziness.
Laziness includes both the making poor decisions because they seem easier and not understanding fully understanding the surrounding program.
Sometimes that means going through a three-step process to make the code not suck:
1. Reformat
2. Dissect
3. Re-arranging the program
Step 1 is optional, some poorly written programs are formatted clearly and written. Step 2 is critical. Half of the weird crap you find is a result of laziness, but the other half is hacky bug fixes that fixed real bugs. Step 3 is the glory step, because more often than not it results in deleting a plenty of code.
But in any case, this story sounds foolish. No consultant should ever say to their client "your code sucks" unless they don't want to do business with that client and all of their business network ever again.
I second u dude...one of the projects i was working on, the code written by earlier developers really sucked...i cud not make head or tail of it...so i started my own design and after a few thousand lines of code, i think my own code sucks too, though it is a little better than the original code...
ReplyDeleteDoes your friend need some help? Have him email me :-)
ReplyDeleteNice post :) I bookmarked your blog.
ReplyDeleteIt's a good point that people often say other peoples code sucks when they don't understand it. (Same seems to hold for other technologies, tools, etc)
your blog sucks! :)
ReplyDelete@Dave Swersky: Who has a 10k-line codebase? With that small amount of code, you probably *could* look at it for 30 minutes and decide if it sucks or not.
ReplyDeleteSucky code is actually fairly easy to spot: it's code you can't read, or code you can't understand--if there are "oh, *that's* why they did it that way" moments *after* you break something, then the code sucked in that it didn't make it *obvious* why they did it that way through the code (preferable) or comments and accompanying documentation.
No, there is a some serious sucky code out there - my favorite was a 10,000 line one aspx page code behind. Ran the entire app (didn't help that it was in suck vb.net code).
ReplyDeleteAll these apologist stroking the ego of saying 'yeah, there is no sucky code' - just not true.
In all professions there are those that try to get off the hook cheap, or aren't trained and create messes. Our early profession has much of that.
Does it mean it has be a 'you suck and I'm better than you' approach? No. We don't need swagger, but we need people in our profession that know what a code smell is - and do a better job.
I hope in the future there are some qualifications into writing some code so we can get rid of some of the hacks creating some seriously aweful code to maintain.
In your experience, rather than say 'there is no sucky code' - instead, grow to educate on how to spot code smells and learn best practices for refactoring it. Better yet, when you get in charge of writing your own app, think through what your doing vs. just spewing out logic without much thought of how the parts should interact!
Definitely read up on Joel:
ReplyDeletehttp://www.joelonsoftware.com/articles/fog0000000069.html
I find basically two different kind of code, is it just a mash up of api-calls all over the place. Or has the programmer gone to some extent to express his intentions.
ReplyDeleteI feel this is the difference between good and bad code in a larger code base.
Yeah, I had the "Your code sucks according to this guy I asked to do an audit" experience once. Turned out the client lied, because the guy he supposedly paid to do the audit was a friend of mine and had never done any work for him ever. We were both pissed.
ReplyDeleteMe, because my code didn't suck, and him, because his name had been misused as a bludgeon.
Your post reminds me of this: http://www.youtube.com/watch?v=L_vcy7I0zIM
ReplyDeleteEver since I have watched this I have gotten this irritating feeling of "I might be incompetent" when ever I start thinking I am a good software developer.
I don't know about your code, but your font choice does suck :-)
ReplyDeletevery nice article.
ReplyDeleteI disagree. Just like any human creation (like music or art), there is good code and there is bad code. One may say that it's a matter of taste, but then there is bad taste as well. And some music really sucks.
ReplyDeleteSo if you think some code sucks, it probably sucks because it's bad and it doesn't even deserve a closer look.
"I paid another developer to look at your code, he says it really sucks."
ReplyDeleteShould any customer be surprised to hear that response? The only other possible response is, "No, that code is fine. DO NOT hire me to fix it."
PS- Blog lady, it looks like the 80's threw up on your wallpaper. I like it.
As a designer who writes code, I can't tell you how much I appreciate this ...
ReplyDeleteAfter recently having an argument with a female friend of mine about how women don't usually take up programming because it's a boring "guy's job", I am delighted and refreshed to stumble upon your blog. :)
ReplyDeleteI really enjoyed this post, and couldn't agree more. Just curious, what languages do you have the most fun in?
By the way, just to clarify, she was the one defending programming as a "guy's job". I was appalled, personally. :)
ReplyDeleteMike Caprio hit the nail on the head with regard to SQL. Most developers write SQL that really does suck, and I can say that with a great deal of confidence since I spend 90% of my time working in the language.
ReplyDeleteMost developers are lazy and don't bother formatting or making their SQL code readable. This is not a big issue in most other languages these days thanks to IDEs that auto-format the code. So at least the code will be well formatted even if it might suck in some other way.
Working with other developers' SQL code, usually the first thing I need to do is re-format the whole thing. In that language I can tell right away if the code sucks. If you didn't even take the time to make it readable it's likely to have many other problems too.
Nice post. v1 of my code almost always sucks since I'm just trying to nail down particular parts of a feature. However some devs in my organization strive for "done-done" code and I believe that is one of the leader factors of leaving code behind that sucks.
ReplyDeleteFolks will get burnt by not leaving time to refactor (change it for the better, not b/c you feel like it needs to change) and leave endless amounts of sucky code buried in applications. One PM told me "the only requirement was that it has to work" - sadly too many folks bought into this.
If the coder can change, and wants to, I'll help them make the changes. If they refuse I'm OK with leaving them behind and raise a sustainability flag.
Peer reviews are a great place to start for this (co-located or not) and has worked well for teams I've worked on. If both parties agree the code is sucky, then both parties can change it. This isn't always a 15-minute task either but a prudent one nonetheless.
Shouting "this code sucks!" and finding your own name in the author line really sucks .. but I must admit, it happens less and less the more seasoned you get :-)
ReplyDeleteGood point!
That's a nice sentiment, but sometimes code really does suck. A year or two ago I performed a security audit for a new client and what I saw shocked me. The previous developers had taken 18 months to give them a barely functioning, unmaintainable mess. This web app was vulnerable to XSS, CSRF and session attacks, it stored credit card info (including CV2 codes) in a txt file that was publically available, the admin section had no proper authentication (IIRC it allowed anyone to acces it as long as they had a plaintext cookie with loggedIn=1).
ReplyDelete"you never know what was going through the head of the developer that wrote it." is why that developer needed to leave comments. There's usually some reason for any particular hack, but if that reason isn't apparent to the next coder who comes along, the original author made a mistake.
ReplyDeleteFor some reason everyone knows that code is much harder to read than write yet they pretend that's not the case as if to admit it was weakness.
ReplyDeleteThis has to be the worst fucking article I have ever read... this isn't even an article... it's a fucking diary post...seriously... who fucking cares?!
ReplyDeleteIf you weren't a girl this article would have received zero interest.
It's sad how desperate and pathetic the geeky male Internet audience is for female action in their geeky, mostly male, developers profession.
I want my five minutes back, I want my lost IQ point back, I want my small bit of fracture faith in humanity not being a bunch of fucking losers back.
Shame on you and shame on all you who responded because you saw "girldeveloper"...
...fucking face palm x1,000.
I agree with Paul and the others that say most code in the wild sucks from an elegance and readability perspective.
ReplyDeleteAll of us who have written a lot of code for sometime have a huge body of sucky code, as we have all learned how to be less sucky over time. Even now, code not reviewed after some time after initial writing tends to suck to some degree.
Whether it works within the context it was written or has tests is another matter.
Bottom line is for anything non-trivial, you can always do better. Not all code that sucks deserves to be rewritten when there is always more code to be written.
Way to go! I really like this blog. Soo many people are afraid of color. Great post. After reddit showed this to me I've got you in my favorites and rss feed reader.
ReplyDeleteGreat post, but sometimes the code does actually suck.
ReplyDeleteI'll be happy to work with what you wrote, provided your code hasn't killed the flexibility and extensibility that I need to get something done.
Bad Code is one thing, but there is no excuse for Ugly code.
Totally agree...
ReplyDeleteDownloaded Quake 3 Arena code a few weeks ago as I'm taking a peek into "serious" OpenGL and I can assure you some parts of it looked like crap to me (first glance). Then I decided to take another look, as it was FREAKING Quake 3. Know what? It's a nicely crafted piece of software with some cool dirty hacks (most of them I hardly understand).
It's not just "programmer" types that act like this, either.
ReplyDeleteOur programming team is currently working on a major plugin for the BuddyPress social networking platform.
At least once a week some new web developer drops by the support forum and launches into a lengthy explanation of how we should restructure the application. This is often followed by a post a few weeks later along the lines of "cancel all those changes, I've actually *installed* the plugin now and see why it runs that way" ... lol
^F^
s/ever so often/every so often/
ReplyDeleteWay to say the same thing in the last four paragraphs.
ReplyDeleteGreat article.
ReplyDelete"About 9 times out of 10, when I got more than halfway there I'd run into an issue that made me say "Ooooh, that's why they did it that way" and revert it or use the same "sucky" logic with my syntax."
Well the code is still 'buggy' in the sense that it didn't convey to you the reasons for doing it in a sucky way. While comments are typically overused in code we do need to consider other developers, which means meaningful names, and especially comments identifying non-obvious reasons for coding it in a quirky way.
Code is about communicating with programmers and compilers :)
You are beginnning to understand the Tao.
ReplyDeletehttp://www.canonical.org/~kragen/tao-of-programming.html
Good mama's girl! LOL! :P
ReplyDeleteI was just commenting that I never know if I am too stupid to understand someone else's code, or if their code is just so stupid as to defy logic. I suspect that it is somewhere in between.
ReplyDeleteVery solid post. Even as a manager of software developers, I strongly caution people against claiming some chunk of code sucks. Such comments are typically made without knowing even a fraction of the circumstances surrounding the original development and (more importantly IMHO) not checking to see if the author is sitting right next to them. That can seriously demoralize the developer and/or negatively impact team dynamics if those kind of claims are tolerated.
ReplyDeleteThat's probably much like how your friend felt after hearing the client had essentially gone behind his back to get the code checked. Code reviews can be very beneficial when done correctly, but behind the back checking and purely critical comments is the complete opposite of that notion. Code can certainly be bad/suck, but without an absolutely full understanding of the requirements and other constraints, and/or the developer right beside you to explain decisions, a blanket "your code sucks" statement can easily be one that is sorely misinformed.
With that, I have two remaining thoughts:
1) Your friend, if he hasn't already, should maybe consider firing the devious client. That would probably reduce his stress level a bit, not to mention allow him more time to finish up his other assignments. The trust of the relationship has already been broken by bringing someone else in just to judge the code.
2) If your friend is still overloaded with work, I'd be interested in chatting him to see if he could use any assistance. I like to keep up on my computer hacking skills, so I can be reminded of what's like to write code that sucks. :)
Cheers!
I've been asked to do this before and have been on the receiving end. The strange thing is, each time I've been asked to look at code I have been told by the customer, in no uncertain terms, what they want the outcome to be. Sometimes they have been in a legal battle with another supplier and need someone to say that the code is of a low quality to back up their case. On another occasion an IT department was desperate to keep its in-house developed software whilst the management wanted to replace it.
ReplyDeleteAll code sucks except mine.
ReplyDeleteBut if someone thinks like me then my code sucks too.
Most code sucks, but as long as it's understandable and there is a pattern I totally don't mind, what pisses me off is people accessing the database in the wrong place and stuff like that. I don't mind people driving slow, what really pisses me off is people driving the wrong way down a one-way street
ReplyDelete"About 9 times out of 10, when I got more than halfway there I'd run into an issue that made me say "Ooooh, that's why they did it that way" and revert it or use the same "sucky" logic with my syntax. "
ReplyDelete-> That really made me smile. Every day.
lol.
"Damn, why the hell did I do that... That sucks..."; and ten minutes later: "Oooooooooh. Riiiight. That's why... So where's my backup? Errm, shit... F##K..!!! Why oh why!?"
Now that I am nearly 50 years old, I have to completely agree with you. I went through the same stages. Computer science is still in it's infancy.
ReplyDeleteWell said. I guess I have thought the same thing. I never had it come full circle back directly in my face but I am sure it was said behind my back. Your point about seeing the whole picture, is very insightful. Without understanding the deadline, overall goal, and vision you are only seeing a small part of the picture. This will make me think twice about being so critical in the future.
ReplyDeleteOne of the other comments talks about the important thing is that the software works. What a great measuring stick! In reality I always make choices when handling my code and deciding how flexible it should be. I usually ask these 3 questions:
1. Will this be changing alot?
2. Am I expected to handle these changes?
3. Will this effect the timeline?
4. Will this effect the stability of the applictation?
Once I know the answer to these I go to the sponsor and give them the options.
We are all "noobs" at first...
ReplyDeleteBut I'm not ashamed to say that I look back on my own code all the time and see things I could have done more efficiently.
Thinking we are too smart to learn anything new in life is just arrogant and it's really just giving yourself a threshold to your knowledge gain...
So before talking down, remember you're a total "noob" to the future you... and there's always a bigger fish ^_^
I think most code I have looked at was good code, I think the method they took to solve a problem is usually what "sucks".
ReplyDeleteUsing reflection when an interface would make the code faster and less prone to fail because there is no method "getValue" etc. The code is usually pretty cool in fact, just silly :)
I have to agree with you CD. But if people (me included), would just put a comment here and there, explaining why they did it like that, IT would be a better place.
ReplyDeleteI think in most cases first system implementation does not suck, but when time after time, after time client requests some "easy" improvements, your codebase turns to poo. It is a gradual thing. Those quick fixes pile one on the other. Your manager don't give time and money to redesign system properly, and result is always the same: crapy, bloated system with dissatisfied users and unhappy developers.
ReplyDeleteI'd have to say good code gets the job done in the most efficient way. That being the case your code will be easily enough followed. I worked for a company for 3 years where we had great dev guys, however they were limited to "HOW" it should be done. It was either the managers way or the highway. Having said that the manager had lots of experience however if he could not understand your code at first glance it was just plain wrong. I'm now working for a different company where I am free to code my way and I believe my code has greatly improved.
ReplyDeleteGood post, don't say someone else's code sucks till you can understand it, and if you can't understand it perhaps you should work on your own coding skills
Great article! People sometimes suffer from "Refactor Syndrome." This is where the pressure of a deadline is looming and we say, "Get it to work and clean this up later..." Then something comes up and later never arrives.
ReplyDeleteScraping the whole solution is sometimes the best fit but unfortunately we inherit the deadlines too.
There is a kind of code I would consider sucks, no matter how good its logic is: messy indented code!!!
ReplyDeleteThere are times at which it's actually pretty straightforward to say someone's code sucks.
ReplyDeleteFor example:
* There are times at which you see a bunch of downright bugs the second you take a look.
* There are times at which the developer has selected entirely the wrong algorithm for the job.
* There are times at which tiny changes to the design would make radical improvements in functionality.
* There are times at which the choices of naming, formatting and commenting render code completely opaque, increasing costs to maintain and debug, and making it nearly impossible to extend.
* First pass code is usually pretty bad
* Code from a developer under time or emotional stress is usually pretty bad
It isn't actually a healthy thing at all to suggest that criticism must somehow be the result of naivete, or a learning experience waiting in the wings. I mean, sure, maybe some time back when you were young, you looked at some code, and criticized it before you understood how it worked. Maybe you saw a better way, maybe not; you didn't mention. Now, you appear to believe that just because code espouses a design pattern, that somehow it's a good idea, which is quite plainly a gigantic red flag of someone following a cargo cult mindset.
Being able to identify that something derives from a design pattern not only doesn't say anything good about its quality, but often says something poor. Design patterns are a discussion and labelling mechanism, not a construction aid; someone who reaches for GoF when they start building a system shouldn't be building systems. Design patterns appear naturally in code, but not in a pure form; if it's visible, it's generally there artificially, because someone read the book and tried to use it like it was a lego toolkit, which pretty much never goes well. So if that design pattern was apparent, it's generally superficial, and therefore generally emblematic of low quality code. (If it was subtle, then this criticism does not apply.)
Look, there's another way to look at this: the third party programmer is very probably right, completely ignorant of the code. Software engineers suffer Sturgeon's Law as heavily (arguably moreso) as anything else, and just like everything else, 90% of us are crap. Most code is really, really bad, and if your friend is under heavy workload and heavy emotional stress, their work has probably shown a quality impact as a result.
Have you considered, instead of trying to explain away this criticism, asking about it? Maybe there's something to be learned there.
Show us a piece of the code that got criticized - 500 real lines or so.
Let us show you the problems, so that you can learn to stop avoiding criticism, and embrace it, instead. That's one of the major learning points in becoming a mature developer - realizing that most validated criticism is actually correct.
Right on. Subscribed.
ReplyDeletePeople confuse code and architecture. Good architecture begets good code, whereas I've seen numerous cases where bad architecture is also poorly coded.
ReplyDeleteWhat are some clear examples of bad "code"? Compiler warnings that are not addressed (I've seen production code with equality/assignment warnings!) Warnings about variables never initialized/used. No error handling. Universal error handling--the ubiquitous "catch all". And so forth.
Bad architecture is harder to identify, but there are two time honored ways I've found that quickly identifies bad architecture. First, when a problem is found, how long in the debugger do you have spend figuring out the problem? Second, when a requirement changes, what else breaks and how much rewrite is necessary to implement the change?
So, frankly, I think there are measurable qualities that make code and architecture good or bad.
Code may suck !
ReplyDeleteBut most of the time, the coding started before the requirements where done. Or the specification was a bit shifted, to get an extra costumer and include his specials.
Or the design simply does not work the way, it was constructed, since the machine accomplishing this will be produced in ten years or at a price, which was not calculated.
Then the dark side of software engineering begins. You don't have the time to recode it all, so extending starts. Now obsolete code will not be deleted, since development is already late at that time. If you had know the how to do it right from the start, the application would be nicely coded.
But that's not the real world. In the real world you give cost estimations based on a handwaving design. Which is extended by the project manager to bring in some extra money. Take this into consideration, if you analyse the code wreck, which is given to you for maintenance.
Probably one of the most useful articles ever.
ReplyDeleteThe real test of any code from a developers point of view is 'how easily can I make a change to this code if I want to'. Invariably long procedures contain so many different functions that it is impossible to change it without creating difficult to find bugs. If you can go in make and make a change without adversely affecting other parts of the program it is normally 'non sucky' code. This is why I tend to be a bit slower coding than a 'fast' developer, as I am normally writing it to allow for changes I, or someone else, may want to make in the future. The saying 'if it works, leave it alone' also has much merit, unless you have to make a change to it, then you can be in a difficult situation. I have had to make some changes to 'old' code in the past that actually necessitated a re-write. Another issue is that your manager usually can't tell good code from bad, they usually just go on whether it works or not.
ReplyDelete"I always tell myself - there's always someone more clever than you."
ReplyDelete@Dave Swersky
There's no one who's more clever than I am.
Nice post and definitely reflects a more experienced perspective.
ReplyDeleteI am about to start a trial example process of Code Reviews and try to engender an appreciation for writing better code.
I like the "Clean Code" book by Robert Martin. He has some really good ideas on making code better. Fewer lines, less comments, better naming and much more readable. I highly recommend the book.
I got to say that I unfortunately simply don't get this post. So many people seem to agree, but I have been programming for 12+ years so it is not like I haven't gotten there yet. I think you definitely can say whether code does suck or not. There are quite a lot of clear metrics:
ReplyDelete1. Is there a lot of copy-past in the code?
2. Are variable and function names poorly chosen?
3. Function size. If most functions are 200-500 lines long then that is not good code.
4. Size of classes. 200+ member methods is not a well designed class.
5. Amount of code in a file. 6000 lines in a file suggest you don't get modularization.
6. How easy is it to expand functionality. E.g. can I just create a sublclass and register it some place, or do I have to make changes in 10 different places scattered about?
Are someone saying they don't agree with these points? I am able to see stuff like this in other peoples code quite quickly. Hell I see it almost every day. Personally I have come to believe most coders suck. For my own sanity I did look at code written by well known developers and I have seen it is indeed good. E.g. look at the git or the linux kernel. Despite being pure C, it is very well structured, functions are short and have a clear purpose. It is a lot better than most of the C++ code I see every day
Wise words, I totally agree with you!
ReplyDeleteExperience and introspection are great teachers aren't they? I learned long ago that code that doesn't match my aesthetic doesn't necessarily "suck". I'll take time to understand it (if possible), maybe neaten it up or maybe just leave it alone.
ReplyDeleteI like the attitude, and it's always a good idea to try to understand another's code before passing judgement, but I must respectfully disagree on points.
ReplyDeleteAt the large scale, it may be hard to understand the greater concept of how it all fits together. But it's certainly possible to see piss-poor implementations and logic at the smaller, more self-contained scale.
Good code is self-documenting (ie, good function and variable naming patterns) and clearly commented for anything that might be remotely confusing. If you can't understand what the programmer was trying to do, they failed to make their code readable and maintainable.
Usually when another developer says "the code sucks" its just a euphemism for "I didn't write it".
ReplyDeleteMy general rule for determining if code sucks is (a) is it brittle and (b) is it readable ? If it is neither, the code probably doesn't suck.
The more I wade through other people's code, the more I tend to agree with this blog post.
ReplyDeleteEven if the code sucks, I know that there was often a reason for it sucking. Usually it boils down to not being important enough code to polish. There's always a time tradeoff when writing code. Any code you're working on now means there's other code that never gets written.
That said, the more I maintain other people's code, the more I learn what not to do from a maintenance perspective...
Excellent article... huge egos are rife amongst developers; I think we can all benefit from lending the benefit of a doubt when looking at other people's work.
ReplyDeleteIf you're doing something in a strange way to work around an issue but you don't add comments explaining the issue and why you chose your approach, then your code does suck. You're setting it up to get "optimized" or "fixed" later on, by yourself or someone else.
ReplyDeleteSo when I open up some code and it seems wonky I give them the benefit of the doubt. I start by trying to determine if it's wonky for a reason or if the author really was just an idiot.
very nicely written.. exactly the thoughts which crossed my mind when I started my career. khudos to the 'precise description' of yours
ReplyDeletecheers
PS: more the complicated code looks even for simpler of tasks, more extendable, reusable and robust that is.. my personal experience so far ..
very real and very enlightening. some time age ,i also contempted other's code because i am a rookie,now i konw i need learn more.
ReplyDeleteAwesome post! Diggin' the humble pie...
ReplyDeletewhat a wonderful concept!
ReplyDelete"everything is nice, if you think something is not, it's because you can't appreciate it."
make it clear: ugly code do exist, period
I would largely agree. There is always room for improvement, but if you don't completely understand the code and what's doing and why it's doing it, you don't have a basis to pass judgement.
ReplyDeleteIf it's not broken, don't fix it. If you have a really good reason for fixing something that's not broken... make sure you're using revision control. =)
I really like what I see here. I hope it comes to pass.
ReplyDeleteI really like it.. I use also it my some projects.Thanks so much
ReplyDeleteNike dunks are popular now,if you haven't put on them,now you have the good chance to do it,just link my name and buy them,you will have the different feeling of your feet,trust me.come on!
ReplyDeleteFIRST DAY[url=http://www.isravoyage.com].[/url]Bird of passage at minimize a ebriose stature of Ben Gurion Airport "Valid outstandingly morning , Ladies and Gentlemen! Shalom and too satisfying chiefly to Israel! Shalom means Hello and Peace. That is as what we gently own a fancy everybody and distinctively those each of which a not many do key of all to us. "My basic humongous cheese is Jacob, which comes fm. the Bible, of progress! We zappy from here in the Solid dregs of the Bible, the Sanctified Upon, such that the sound shooting off is biblical! My sturdy purchaser Jacob was the steady son of Isaac, the physical son of the Patriarch Abraham
ReplyDeleteThe context is good,I saw many people agree with you.me,too.I recently blogged about the prevalence of "as-seen-on-TV" brand conventions in the medical device industry, which strikes a discordant note in that environment. and now can you link my name to see my website,thanks.
ReplyDeleteThanks Fred...still a lot of work needs to be done. It takes a while to move the Titanic
ReplyDeleteToday is the day to remind yourself
ReplyDeletethat you posses the power
I can live for two months on a good compliment.
ReplyDeleteWhen you change your performance, you change your life
ReplyDeleteBooks and friends should be few but good.
ReplyDeleteThis a good things that have to be had by each developer
ReplyDeleteYou give me some inspiration and some time I have a problem like that
ReplyDeleteoh I liked your post
ReplyDeleteoh I liked your post
ReplyDeleteoh I liked your post
ReplyDeleteOh *, I hope you have a lucky day * every day
ReplyDeleteI often dream of that clueless closet app as well. (My first Java applet was a dress-up game.) I think it'd make a good mobile app - take pics of your clothes or draw them, catalog them, remember your favorite outfits. Bonus if it super-imposes them on you and tweets them out for ratings.
ReplyDeleteI often dream of that clueless closet app as well. (My first Java applet was a dress-up game.) I think it'd make a good mobile app - take pics of your clothes or draw them, catalog them, remember your favorite outfits. Bonus if it super-imposes them on you and tweets them out for ratings.
ReplyDeleteHappy new year to all my love!Hope everyone has a fantastic new year!
ReplyDeleteWhen i read your blog it makes me chuckle cause
ReplyDeleteI've been through your path and it always makes me
smile... heheh ..Cause developers always think that
We can work this project the way we want it into.
The easiest way to do it is through our own style as possible.
yeah \m/
Great article ^^
The person who thinks himself is happy can enjoy happiness!
ReplyDeleteA very good friend of mine is in the midst of an avalanche of work. He has a lot of open contracts, and has been abandoned by a fellow developer that was helping him with his workload. So, with three huge clients breathing down his neck he has been working non stop for weeks now. http://www.mbtusasale.com
ReplyDeletethat other people's code sucked. When I first started out, and I looked at code that definitely sucked hard, I scrapped it, and started from scratch in a way I knew was way better. As I matured I looked back and realized that what I had destroyed was a well accepted design pattern, and what I created was a mess of a mess pattern. http://www.uggsaleaustralia.com
ReplyDeleteAimee,
ReplyDeleteThat's a great question. Being so focused on WHERE THINGS COME BACK and getting it ready for bookshelves hasn't allowed for much talk of a second novel. Because it's such a long process (usually 18 months at least from contract to shelves), there isn't any rush in seeing a second book. My agent has, however, read much of the one I'm working on and has discussed it with me. As far as their approval of my approach to writing-it isn't really something that's an issue...at least not as far as I can tell. I think they've worked with enough writers to know that we all have our own systems of getting the job done.
I'm also happy to report that, as of yesterday, I'm back to work (slowly but surely) on novel # 2.
Thanks,
Thanks for the post!
ReplyDeletehttp://jobspert.com/interview-questions/
Amazing post.
ReplyDeleteHi,
ReplyDeleteAs a designer myself, i always have something similar with other designers lol , competitors do not like each others work :)
i love this post very well, thanks guys.
ReplyDeleteHealth and understanding are the two great blessing of life!
ReplyDeleteThe Herald-Sun follows up on neighborhood reports of some concerns with new automated-read water meters with a story in today's paper
ReplyDeleteFace everyday with a smile.
ReplyDeleteMoney is soming, not every. But without money, you can't do anything in this world!
ReplyDeleteThanks a lot for sharing. I hope see you more good articles.
ReplyDeleteIt looks amazing.i like it very much.
ReplyDeleteI never thought that you're good with code.
ReplyDeletefor me code make me sucks :)
Some time ago, I really needed to buy a good house for my corporation but I didn't have enough cash and could not purchase anything. Thank goodness my brother suggested to try to get the loans at trustworthy creditors. Thus, I did so and used to be happy with my short term loan.
ReplyDeleteAdd some images. Great images normally catch interest. Consist of 1 or two photographs which might be related for your campaign, like a mother-and-son image or
ReplyDeleteSo much spam...
ReplyDeleteclueless closet app as well. (My first
ReplyDeleteI hope well
ReplyDeleteCarstens, Mexico’s central bank governor, yesterday said chances are “quite high” that Lagarde, France’s finance minister, will win. He said that he put his name forward in an effort to help emerging markets get the post in the future. http://www.supra-shoes.ca/
ReplyDelete