Through my journey as a programmer, I've seen quite a lot of ugly programming code. I have sampled ugly code from academia, where newbie/junior programmers try to solve problems in a very hacky and ugly way. In industry, I have seen websites that I can hack and break in about 2 minutes.
In either case, a while back, I saw a project fail so epically and brilliantly, that it has infact lowered my expectations of programmers. Viewer discretion is advised to my non-geek audience, I'm going to be switching my dialect to nerdspeak, so if you don't understand it, I advise you come back another day. For your viewing pleasure, I have uploaded some pictures that you can check out in my Flickr feed.
So this guy had been working on this critical project for about two months. However, the longer the project went, the buggier the program became. This is usually a bad sign because bug reports should actually start to go down as a project approaches completion.
Some of his team members complained that the code was overly complex, but he balked at the assertion, and just thought that his team members didn't have the same programming experience as he did.
When the alarm bells started going off that the project was no where near finished, and it was getting buggier by the day, management decided to step in to figure out what was going on. A fairly senior programmer stepped in to review the code to see what was wrong.
It turns out one of the reasons why the code was so buggy and hard to understand was because the programmer in question didn't bother commenting any of his code. For those who are unfamiliar with programming, comments are used to document and annotate code to tell other programmers what's going on.
This would be an example of commenting code:
// Print hello world for one hundred times
for ($i = 0; $i < 100; $i++) {
print "Hello World\n";
}
Undocumented and unreadable code is a huge burden to other programmers because they have to waste time trying to figure out what your code is doing. The wikipedia says, "Readability is important because programmers spend the majority of their time reading, trying to understand and modifying existing source code, rather than writing new source code."
Here's an example of code that's pretty hard to understand at first glance, and a comment would be nice.
echo substr($_SERVER['PHP_SELF'],1,-(
(strlen(substr(strrchr($_SERVER['PHP_SELF'], "/"), 1))+1)+
(strlen(substr(strrchr(dirname($_SERVER['PHP_SELF']), "/"), 1))+1)
));
In either case, the senior programmer gave the programmer the official coding conventions that everyone had to abide by. The document clearly discusses how comments should be formatted, and what information should be included. This was important because we generate documentation based on these comments (think JavaDoc). A few weeks passed, and the senior programmer started another review of the code.
The code did in fact have comments this time around, but they didn't follow the conventions. The senior programmer asked the programmer why the comments didn't match the style that's outlined in the coding conventions.
The programmer explained that he didn't have time to learn the coding conventions, so he invented his own commenting style. He further explained that as the project finished, he would write a program that would convert his comment style to the coding convention's comment style.
When I heard this answer, I starred in awe as there was so much crazy in that logic.
First, the coding convention guide isn't complicated to follow at all. I got through it in under an hour. Second, without actually reading the coding convention guide, there's no guarantee that the guy's comments maps one-to-one with the required commenting style. Third, to perform a transformation, you basically have to write a parser which is not an easy task. Not only that, I bet writing the parser would take far more time than just spending the time to learn the coding conventions in the first place. I was amazed that the guy had the nerve to defy the senior programmer like that, especially if he knew a second code review was going to happen.
In engineering, there's a principle that says it's usually the most cost efficient to build things right the first time. It baffled me that the guy was intentionally building something wrong, and was going to invest more time later to correct the problem.
This incident has lowered my expectations of programmers, and I was shocked, because I thought I had already seen some really bad programmers, but this took the cake.
-1 Faith In Humanity
