﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Joseph D. Gutierrez commented on Understanding Bad Code</title><description>LOL. The code base I inherited because the company changed coasts, was the same exact one that as a field service I would request bug fixes or adding functionality. So it came down to me being the Rosetta Stone for this code. LOL.
</description><link>http://ayende.com/2572/understanding-bad-code#comment4</link><guid>http://ayende.com/2572/understanding-bad-code#comment4</guid><pubDate>Wed, 20 Jun 2007 02:21:44 GMT</pubDate></item><item><title>Travis Laborde commented on Understanding Bad Code</title><description>It's good to hear that it's not just me.  I think I'm a bit slower than most though - at getting comfortable with an alien codebase.
  
  
I once hired a woman named Uma who was absolutely GREAT at this.  She could sit down in front of code she'd never seen before and within a couple of hours she was comfortable with making changes, and not breaking things.
  
  
I'd say she made me look bad - except that of course since I hired her I looked good in that sense :)
  
</description><link>http://ayende.com/2572/understanding-bad-code#comment3</link><guid>http://ayende.com/2572/understanding-bad-code#comment3</guid><pubDate>Tue, 19 Jun 2007 11:43:58 GMT</pubDate></item><item><title>Frans Bouma commented on Understanding Bad Code</title><description>I wasn't talking about bad code in particular, just any code. The problem is that if you have a piece of code and you want to UNDERSTAND every detail of it (you have to, you can't ignore little details, it will bite you sooner or later if yo do), you effectively have to run it and see what every statement does: which state it changes and what the result is of that state change. 
  
  
When a human reads program code and tries to understand it, the human will make assumptions at every line what that line does, what the effects are of that line, so the NEXT line's effect can be understood as well. 
  
  
Your point, that understanding a piece of code after you're familiar with the code base isn't correct: if it would, you wouldn't create any bug in any software you're writing, as you're always familiar with the code you just wrote, right? :)
  
  
Never over-estimate what a human understands from code, as it's fairly limited what a human understands from program code, simply because just looking at code isn't revealing anything to the reader unless you 'interpret' it line by line in your head and that's precisely where it goes wrong. 
  
  
That's not a bad thing, it's just a fact of life and because of that, a human has to take that into account when software is written. This can get tedious at some point, but it's essential. 
  
  
Another mistake, which is a bit hidden between the lines of the article, is that code isn't falling out of the sky: it's the result of a process. Assuming that the result of the process is enough to understand every step taken in that process is IMHO a mistake: there's no proof that by looking at code you can see the process, the steps taken, the reasoning followed etc, on the contrary. (we all run into the fact that code isn't reflecting the whole process when we have to go back to some code we wrote some time ago to refactor it. No-one can read that code and instantly remember EVERY detail of the process that resulted in that code, a human needs help with that. Which is natural and a fact of life. 
  
  
Now, it would be great if we all stop being so stubborn and simply admit that humans aren't as good in reading code as we think we are and thus that we should focus on tools which help us along the way to overcome that limitation. Only than we really will make progress in the quality of software engineering.
</description><link>http://ayende.com/2572/understanding-bad-code#comment2</link><guid>http://ayende.com/2572/understanding-bad-code#comment2</guid><pubDate>Tue, 19 Jun 2007 08:05:45 GMT</pubDate></item><item><title>Mr_Goo commented on Understanding Bad Code</title><description>Yeah I was making this point the other day on this blog or another. I called it TTS for The Total Mess.
  
  
All this and that super uber stuff is cool to talk about, but for real world apps it all turns into goo at some point.  At that point being an employee SUCKS because they'll never promote you because you're the only one know knows the system.
  
  
On the other hand, being a consultant is GREAT  because they (your boss) already knows how hosed he is and they just pay you for two weeks to hunt down a single bug.
  
  
Personally, I love the goo baby!
  
  
</description><link>http://ayende.com/2572/understanding-bad-code#comment1</link><guid>http://ayende.com/2572/understanding-bad-code#comment1</guid><pubDate>Mon, 18 Jun 2007 21:50:37 GMT</pubDate></item></channel></rss>