Why Does Your Code or Design Suck?
Jul 08, 2009 In Development By Thomas LewisWhy is it that when given someone else’s code or design, it is always horrible?
I have noticed over the years that whenever I hear developers or designers talking about a codebase or design they inherited or reviewing that it almost inevitably leads to a proclamation of:
OMG! This is the worst I have seen, this is an epic fail of great magnitude!
I think one of the reasons is that those whose lot in life is the technical field tend to be rather binary. 0 or 1. It’s the fundamental choice and is at the core of these machines we are slaves to. We tend to take this approach to code we look at and if it isn’t written according to a validator, test, or pattern, we are ready to flip the switch and deem it unworthy and render judgment immediately. I used to fall into the code perfection trap at times and found myself in and endless cycle of violent refactoring. At what point do you stop trying to get perfection and ship the darn thing?
Another reason I think we tend to look at O.P.C. (other people’s code) and deem it unworthy is that development is not a science but at times an art. We are given a multitude of choices on how to approach a problem. Do we build an Internet app or Client app? Do we use Ruby, C#, or Python? XHTML or HTML? What flavor of data access should we use? It reminds me of those crazy Geometry postulates and theorems where you have to prove that since a square has a right angle that you can deduce that an octagon has 8 sides. Some folks may think approach A is better than B but you could use C too. So we are inundated with a ton of choice. I say that we should respect that others will not always approach the problem the same way we would and it is OK.
Finally, I think at times we lack empathy or the assumption that others are working under constraints we are unaware of. With drive-by tweets and a “I just tell it like it is” attitude, we are very quick to judge. What if our initial reaction was to assume that the developer had constraints we were unaware of, would that change our perspective? What if we all decided that it is our job to help lift others around us?
Now before you think I am advocating some hippy world peace and give everyone an award for participating, I do believe we need to do what we can to prevent bad software and design. But the question is, how do we do that while being good human beings? Should those building developer and designer tools bear the responsibility? Should we promote convention over configuration? Would certification change anything? Share your process and tools for creating good code/design in the comments below and be sure to follow our Twitter account for the latest Opinions, Articles and Labs or my ramblings.
Follow the Conversation
15 Comments so far. You should leave one, too.
This a great article and brings up some valid points about being fair before deciding to judge a design that is perceived as ‘poor or bad’. I believe you are right that we should all think twice before commenting on something we have all done before… bad design.
On that note, I took a peek at this page’s source, and this site’s design is terrible! What were you thinking…. oops I almost forgot – it looks great. (just kidding by the way, I enjoyed your article)
i am guilty of “OMG this is the worst code ever” syndrome. i agree as programmers it’s sometimes tough to respect other coding paradigms. for context, i’ve only worked for small companies with basically no coding guidelines
i agree that as “readers” of code we need to be respectful. but all coders should also be respectful as “writers” of code – knowing that most likely others will be reading/maintaining their code at some point. i believe that slight paradigm shift could do a lot to improve code quality in smaller companies.
There have been times when circumstances have forced me to write bad code. Because of concerns of how it will reflect on my I often put comments around the terrible code that explain why it was written a certain way.
I think that one of the biggest obstacles to keeping code maintainable is to have good documentation. But many project plans don’t provide a budget for time to be “wasted” on writing documentation. This causes a “Save a penney spend a pound” scenario in which future efforts are hindered because of lack of documentation on code.
Great post. We actually had a great example of this a couple of months ago. An internal project was presented to the dev team, I said it would take a day or two to build, but the other senior dev said it would take a few weeks.
To justify his estimate, the other developer mapped out this huge n tier application that was scalable and by most standards a great concept. Then I presented my idea of just slapping a few databound controls in an app with a dbml file and letting LINQ do it’s thing.
On the surface his app was better in almost every respect. More scalabe, easier to maintain, more effecient, etc. However, our app was for internal use only and would never have more than a dozen or so users on at once.
In the end, we decided that my bad code was the best solution given the requirements.
One thing I’ve noticed is that if it’s not done the way I would do it, then it must suck (I being any developer). I myself have had to resist this when going into someone’s code – just because they did it different than I would, it doesn’t mean that it’s wrong, or even not as good as I would – just different.
(BTW, if you have a underscore in your name, this page doesn’t like it. I would have done a better job coding that!!!! grin)
The green on this site makes the text nearly impossible for me to read.
I am consistently baffled when I go work for a new client and they popo their old web person. In a few cases I know the old person. One was a print designer that was shoved into web stuff and did the best she could. With the level of knowledge she had at the time she did awesome and when I started and told her what questions she should be asking she got even better.
Despite this they still popo her web work. Ah well that’s life I guess.
I have to admit that under time restrictions, and other certain circumstances, I have written some really bad code and immediately said to myself afterward “whoever gets this next is going to think ‘what the hell was this person doing’”
however, I still get code from others and think the same thing myself.
Also, I used to work with a developer that I swear was loosing his mind. He used to leave comments like:
he would go on in story format throughout the entire program. It was actually really entertaining to read.
I have to admit that under time restrictions, and other certain circumstances, I have written some really bad code and immediately said to myself afterward “whoever gets this next is going to think ‘what the hell was this person doing’”
however, I still get code from others and think the same thing myself.
Also, I used to work with a developer that I swear was loosing his mind. He used to leave comments like:
“it’s now 4 a.m. and I have to finish this procedure, this is going to be really ugly because the webservice’s documentation is horrible and my damn boss won’t let me wait for a reply from support”
he would go on in story format throughout the entire program. It was actually really entertaining to read.
“Hindsight is always 20/20” – sometimes I scream looking at my own old code, and go “why on earth did I do that!?!”.
However I’ve had a couple of cases where what I did before was sheer genius – well it had to happen sometime. I came to that conclusion because it took me such a long time to get my head back into the code (in spite of good documentation, comments, structure, etc.) and realise just how involved and subtle the work was. in the same way, when reviewing others work, I’ve often been surprised to see what looks like bad code that’s actually a highly competent compromise – usually to deliver significant gains in performance.
These days the only time I mouth off at other’s past work is when I know that it’s a sample of their activity from a time period after they should have known better.
Programming is in an extended transition from art to science. Certain domains, certain fields are well along, and others are still full of cowboys.
While I agree that there is often a lot of moaning about code you didn’t write, I’ve found that 80% of stuff other people write is crap, and it’s reflected by the fact that it’s so damn hard to find good people to hire. If you look at how many software projects fail, it’s not surprising that so much of what you encounter is crap.
My criteria is really simple: If I can expand, change and otherwise maintain the code, then it’s good enough for me. If I need some questions answered about what it’s supposed to do, that’s cool too. But if what I encounter causes me to step through hundreds of lines of code to fix what should be a simple problem, then that’s crap.
I couldn’t stop thinking about Oxite the whole time I was reading this post and the comments.
My personal view of software is to mold it like a piece of clay. Sometimes what you start off with isn’t so great, but you can continue to improve it over time. If it’s a long term project, it doesn’t need to be perfect out of the gate as long as you continue to improve it along the way. Also like clay used to make a sculpture, it depends where you’re going to display it. It’s one thing to display a piece of junk in the center of your dining room table. It’s another thing to put it in an art gallery. The funny thing though is that some art looks like complete junk so your bad code might seem just fine to some. Beauty is in the eye of the beholder?
But I digress…
:)
Different != Fail
Coders are also a proud bunch, and unfortunately many woud rather call ‘Fail!’ than admit they didn’t understand the architecture and wont risk looking stupid by asking questions. Or worse, assumed it was bad because it was different than what they’d seen in the past.
I’d suggest anyone who’s tempted to cry ‘Fail!’, to share your concerns with the person who wrote the code and get some context. I’d wager you might actually learn something and be the better for it. And if you still think it’s crap, maybe you can teach the originator something.
This article inspired me to write a blog post here. Nice topic and good comments.
http://paultheprojman.blogspot.com/2009/07/other-peoples-code.html
IMO it’s a fact that coders have no sense for design or creativity. They are most times just pure logically thinkin persons that aim for functionality, that’s why they pay no attention to design.