[Programmist]

Occasionally I'll run across something that people do that really irritates me. The purpose of this thread is partially to vent about these stupidities and partly to get the info out there to any young developers listening so you won't do these things! Feel free to list things that irritate you. Maybe we can get a running list going.

1. Committing non-compiling code to the CVS repository.
This is one that irritates the crap out of me. Image this scenario: I'm writing a plug-in for our team's app. Every morning I do a CVS update to make sure my plug-in works with the latest version of the app. One morning I do an update and get loads of new changes, but what's this? My project won't build? WTF? Now I can't test my plug-in with the app because someone has committed non-compiling code to the repository. So, I have to spend my time either commenting out the crappy code (and uncommenting later), or tracking down who uploaded this rubbish and ask them to fix it. And you can't say, "Hey, your code is not compiling - please fix it." No no no. Not in the 21st century corporate work environment. No one is to blame. Shame on you for insinuating otherwise. You have to tell them that you're having a problem getting their code to compile and ask them to "help" you figure out what your problem is. People are so touchy about their code these days.

2. Writing one-shot-wonder classes
A few months ago I was tasked with adding certain functionality to an app. I was told, "Use the existing data access classes that were created in the last release." Sounds nice in theory. Whoever had written these classes had made them so esoteric as to not be at all useful. Not only that, he didn't publish them remotely, so unless the code I was writing was on the same server as his code (which it wasn't!) then there was no way for me to access it. I wonder what people are thinking sometimes. When you write something that exposes data, make it reusable, unless you are 100% sure that no one will ever see it. Otherwise you're possibly shooting a teammate in the foot.

[Martyr2]

Those are some great points! Here is one I usually run into...

3. Document what you have done and what you are trying to do

I don't know how many times I have taken code out of a repository and seen that it could use a good upgrade. Let me see where it attaches to, what is it trying to accomplish? What was this person doing that needed this function or class? Often times I will then write a few functions, comment them and what the functions attempt to do only to be told later that "Oh yeah, I am using this function over here that I found which does the same thing as you just wrote" Well, it would have been nice if you mentioned that you used that function or let someone know that the function even existed over in that module. If I had seen it in documentation then I could have used the same function/class.

I think they do it because they were either running a test that blossomed into a good solution and rather than taking the time to clean it up they leave it. Or they didn't want anyone to know they were using a function somewhere else rather than writing something more relevant to the problem.

This post has been edited by Martyr2: 08 August 2007 - 09:43 AM

[no2pencil]

4. Creating a sloppy work around, not documenting, & walking away like nothing happened.

I don't know how many times something 'brakes' for an unknown reason, & when you look through the code only to find the bubble-gum & duct-tape thats holding the entire thing together. Granted it is an uncommented block of code to boot. No one will fess up to the magic 'patch'. No one knows why it's there, & no one knows that anything is wrong. Automagic!

[Programmist]

no2pencil, on 8 Aug, 2007 - 09:47 AM, said:

No one will fess up to the magic 'patch'...

This is where a version control system helps. It's often a pain in the a$$ to track down who did what, but if you look at the history of a file (in CVS anyway) you can eventually find who committed that steaming pile of code.

[WolfCoder]

My code gets sloppy and messy as I get tired, so right now I'm looking back over my huge mass of code. I can see where I got tired as there are missing comments or comments that don't make any sense. I was like "WTF was I on?!?". and seeing as other people will be looking at my code at some point to make some modifications, I have to go back and clean up my shit.

[Programmist]

5. Not honoring your API!!!
OK, this is a big WTF. One of the teams in our dept is responsible for exposing SQL transactions as web services. They publish their API (the input XML and output XML) and we code to it. But the last two releases I have had to go back and change some element names because they did not honor their API. This pisses me off royally because it's a waste of my time. I complained to my manager last time, which obviously did no good, so this time I sent out an e-mail explaining the problem. The moral of the story is, if you publish an API, you need to honor it. If you decide to change it, change your docs and notify those using it, FFS.

[1lacca]

alcdotcom, on 8 Aug, 2007 - 06:02 PM, said:

1. Committing non-compiling code to the CVS repository.
This is one that irritates the crap out of me. Image this scenario: I'm writing a plug-in for our team's app. Every morning I do a CVS update to make sure my plug-in works with the latest version of the app. One morning I do an update and get loads of new changes, but what's this? My project won't build? WTF? Now I can't test my plug-in with the app because someone has committed non-compiling code to the repository. So, I have to spend my time either commenting out the crappy code (and uncommenting later), or tracking down who uploaded this rubbish and ask them to fix it. And you can't say, "Hey, your code is not compiling - please fix it." No no no. Not in the 21st century corporate work environment. No one is to blame. Shame on you for insinuating otherwise. You have to tell them that you're having a problem getting their code to compile and ask them to "help" you figure out what your problem is. People are so touchy about their code these days.

OMG, does it really happen? Thankfully we don't hire people who do this. Whatever you commit, it should always compile. It is sometimes possible (due to the lack of documentation, or test cases ) that a run-time exception is generated, but the commited code should always compile, if it doesn't why the hell is it committed? It's kinda the 0th rule of team development, because the others can't work otherwise.

So my team development pet peeve is when people are creating more and more "visible" debug outputs, so their new development is easier to see. I can understand it to some extent, but hell, if everybody do this after a while the debug output is like a modern art, but it is useless, because your eyes are hurt just by looking at it. So then what to do? Most logging APIs support filtering very well, so it is very easy to switch off logging of not needed levels and regions. Other than that, a good debug message should contain anyway it's origin and meaning, making it quite easy to find with even the most simple text editor tool, so the patterns like >>>>>>>>>>>>>>>>>>>>>> and =============== and ---------------- can be forgotten. (I am referring to production / commited code, for personal use it is ok, and might be even useful, but I still think that a meaningful debug message is much more useful)

This post has been edited by 1lacca: 11 August 2007 - 02:32 AM

[Programmist]

1lacca, on 11 Aug, 2007 - 02:30 AM, said:

OMG, does it really happen? Thankfully we don't hire people who do this. Whatever you commit, it should always compile. It is sometimes possible (due to the lack of documentation, or test cases ) that a run-time exception is generated, but the commited code should always compile, if it doesn't why the hell is it committed? It's kinda the 0th rule of team development, because the others can't work otherwise.

Yup, it happens - usually with new people. I don't make hiring decisions, but that should be first on the list to tell them.

Another common CVS mistake is that people will go for days without doing an update or commit and then end up having to merge a lot of code. And apparently a lot of people don't know how to merge code, so changes have gotten lost before. I've seen it. If I were manager, I'd make people go through training on how to properly use CVS in a team environment - no matter how experienced they say they are.

1lacca, on 11 Aug, 2007 - 02:30 AM, said:

So my team development pet peeve is when people are creating more and more "visible" debug outputs, so their new development is easier to see. I can understand it to some extent, but hell, if everybody do this after a while the debug output is like a modern art, but it is useless, because your eyes are hurt just by looking at it. So then what to do? Most logging APIs support filtering very well, so it is very easy to switch off logging of not needed levels and regions. Other than that, a good debug message should contain anyway it's origin and meaning, making it quite easy to find with even the most simple text editor tool, so the patterns like >>>>>>>>>>>>>>>>>>>>>> and =============== and ---------------- can be forgotten. (I am referring to production / commited code, for personal use it is ok, and might be even useful, but I still think that a meaningful debug message is much more useful)

That can get annoying. What I sometimes do is output a log file called someClass.tony.log which includes the method name and my messages. I very rarenly use that anymore, however, with ubiquity of real-time (even remote) debuggers.

[PsychoCoder]

luckily where I work we use Source Control software, this prevents people from checking in code that doesn't work (well not prevent it but it shows a history of all changes to that file, and who did the changes).

Plus, I believe theres a setting in Visual Studio 2005 where you can make it build before checking in a file, this will cause an error to be thrown if they have code that wont compile (I believe there is so don't quote me on that). And theres a setting where you can make Visual Studio check in all checked out files before the application closes, this prevents people from leaving with checked out files.

[Programmist]

PsychoCoder, on 11 Aug, 2007 - 11:04 AM, said:

luckily where I work we use Source Control software, this prevents people from checking in code that doesn't work (well not prevent it but it shows a history of all changes to that file, and who did the changes).

Plus, I believe theres a setting in Visual Studio 2005 where you can make it build before checking in a file, this will cause an error to be thrown if they have code that wont compile (I believe there is so don't quote me on that). And theres a setting where you can make Visual Studio check in all checked out files before the application closes, this prevents people from leaving with checked out files.

CVS is a type of source control software. Do you use on that is actually called "Source Control?" We had something installed for a while that attempted to build every commit and then would send an e-mail to the committer telling them if their commit built or failed. I'm not sure what happened with that, but haven't noticed it doing that lately.

[PsychoCoder]

Well use Visual Source Safe at work. While lots of non-Microsoft people talk about how crappy it is (Ill agree some of the older versions are real bad) it has a lot of nice features, and we have yet to have a single developer check in code that wouldn't compile.

[Programmist]

PsychoCoder, on 11 Aug, 2007 - 06:14 PM, said:

Well use Visual Source Safe at work. While lots of non-Microsoft people talk about how crappy it is (Ill agree some of the older versions are real bad) it has a lot of nice features, and we have yet to have a single developer check in code that wouldn't compile.

I can't say anything about SourceSafe since I've never used it, but I've heard .NET dev gripe about it. We're a Java shop, though, so we have no use for SourceSafe. Also, CVS is free. The problem is not with the version control system, but with the developers.

This post has been edited by alcdotcom: 11 August 2007 - 08:06 PM

[Amadeus]

SourceSafe works alright in an MS dev shop, although it does have a lot of problems (and to be fair, even dev teams using MS tools don't like it that much). aldotcom has hit the nail on the head - any control system is fine, as long as people know what they're doing.

[1lacca]

Actually we have an in-house rule: whoever commits something that breaks the build, he has to donate some money for funding the next "community building" in a pub. (Unfortunately you can check source files by building them yourself, but it is not possible with some SQL install scripts, so nobody is safe)

[Zarowich]

It is the social attitude of the developer rather than the version software itself. The software only helped to solve the problem, but the problem has not been solved unless the problem producer accepted the solution.