Your Code Sucks

       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.

Comments

[Dave Swersky]

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.

This 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.

[Rylanb]

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."

Sometimes it really could just be the Dunning-Kruger Effect. :)

Nice post, regardless.

[Nicolas]

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...
I 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.

[m]

more about being tactical than anything else..

you 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

[Satya Narayan]

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.

Most other techniques have high degree of inefficiency.

Well put. Thanks for sharing

[Jack Maynard]

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.

[seutje]

see, this is why you add comments to your code...

[Mike Caprio]

I 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.

[Chris Ballance]

Your post reminds me a lot of how my eagerness to proclaim "your code sucks" has changed as I have matured as a developer.

It 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.

[Tom]

Learning to say "My Code Sucks" can be a good thing too...

http://coderoom.wordpress.com/2010/04/22/7-reasons-to-hate-your-code/

[Nilesj]

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.

I 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.

[Joemacstevens]

I've learned that the hard way quite a few times.
Though, 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.

[andrewtwest]

This reminds me of the old Joe Spolsky article, "Things You Should Never Do, Part I". ( http://www.joelonsoftware.com/articles/fog0000000069.html )

On 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.

[Daniel Auger]

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.

[Ben Fulton]

Another 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.

[Lisa]

I'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.

[Iain Barnett]

This 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.

And some code definitely does suck (not mine... ;)

[Ian Cooper]

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.

An 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?

[Guy]

Your post sucks!
(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.

[Bluesmoon]

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.

@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.

[Mad Jack]

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.

Racing 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.

[Xenplex]

Nice said!
I will remember this post when I graduate from school and become a developer.

[Paul Keeble]

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.

Its 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.

[Nick Berardi]

This is the quote I always think of when ever any developer says "that code sucks", with out knowing any context of the problem:

---
* 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/

[Ed Davis]

Welcome to experience!