I have been working within a team of programmers directly within the same office for almost three months now. It's my first experience of such a nature considering my freelancing background. I am going to share with you, what things, in my opinion, one HAS TO avoid in such an environment.

Putting Parse Errors Into The Version-Control-System

The Problem

Yes of course, this should go without explanation. However, when you are in a rush for a deadline or the person above you is nitpicking or you simply have a bad day, it can happen - you check in parse errors. I have found myself checking in parse errors as well. It's just the desire to get it finally working (!) without thinking about possible consequences. With a test server set up this is usually not a problem. It doesn't improve your reputation among the team, though.

The Solution

Relax. Test everything before you check it in. Simply refresh your current test page to see if a parse error popped up. It only takes five seconds. Five very valuable seconds.

If you find yourself having a bad day, relax even more before you check something in. I have found myself willing to be the fastest in feature completion sometimes. However, well tested, slowly-developed code is a lot more worthy in the longterm.

Undeliberate Code-Replacement

The Problem

Sometimes you are getting conflicts within your version control system, but the person you need to ask which code fragment is the correct one is in a meeting or out to lunch. What do you do? You replace the code with your good will so you can continue working, right? Wrong!

This is again one of those things that only bring a quickfix for your situation, but result in pure malice in the longterm.

The Solution

Relax. Work on something else. Blog a bit ;) or work on another component. Of course in a tightly coupled system this may be a problem, but you always can do something else and wait for the person to check the conflict. The bad news is that conflicts should not happen in the first place as they are a result of miss-communication within the team. However, in a non-OOP environments it tends to happen a lot more often.

Checking In Untested Code

The Problem

Being in a rush for a deadline you forget to test your code thoroughly or even forget to write unit tests for it alltogether. Or, even worse, you are not addicted to writing tests.

The Solution

Make an appointment with yourself to write unit tests. This appointment is just as important as the upcoming meeting with your CEO. Write them. Simple!

They do not need to be under version control. They can be on your local machine and that's it. They just need to be there somewhere and get used.

Wrong Assertions Or Better "What Does It Need To Do Exactly?"

The Problem

You find your own code (components) not returning what is expected by the clients (your colleagues) regularly. This is due to wrong assertions and unclear communication in the phase where requirements for the new code are written down.

The Solution

Well there is no ultimate solution to this, as it boils down to communication problems. The only thing I can suggest is that you think about it from an engineer's perspective: What does come in and what should go out? In which format? What should happen when the wrong thing goes in?

It's these things that make Test-driven Development so successful. TDD forces you think about this stuff a lot more thoroughly.

No Handling Of Exceptional Behavior

The Problem

This goes hands in hands with the last one. You find yourself not handling exceptional behavior (the preconditions for your code are not met) on a regular basis.

The Solution

Make it a quality standard that everything you write takes care of most if not all circumstances possible in your application. If you fetch currency rates from your database and your application's output greatly depends on it, this is extremely critical stuff. Of course, the fetching from the database may go wrong, as the table may be crashed. You at least need to send a critical log email to yourself if this happens. If it happens, show a friendly page to your visitors explaining that something went wrong, without telling them the truth.

If you find yourself developing an application where you lose the overview about in which state the app is in, rewrite it. Simple. The risks of security issues, slow development times etc. far outweigh the time lost without new features in most cases.

Unclear Documentation Within The Code

The Problem

Your code can be understood by you easily. However, your teammates struggle understanding your code. Your code documentation is wrong, is based on wrong assertions or is simply unclear.

The Solution

Keep your code documentation up to date with your thoughts. If you write good code that speaks for itself, less documentation is needed, which is a good thing. Other than that:

• Make it a quality standard that you use PHP Doc Comments for every little class, method, function or whatever.
• Document the uneasy code fragments as well. Do not explain what the code does, but explain why it does what it does.
• Regularly ask your teammates if they understand your code. Do this especially when their code depends on yours.

Finding The One To Blame

The Problem

Your team spends way too much time searching through revision logs to find out whom of the team checked in crappy code that suffers from one or more of things from above.

The Solution

Do not spend your time doing this, it's way too expensive. If everybody works for everybody, the code improves over time to a great extent. We are only humans and mistakes happen. Things in our family and friends may cause us to be unrelaxed and uncomfortable. This may ultimately cause us to "have a bad day", a definite problem from a programmer's point of you. Also some colleagues may be young and have less experience in a team environment (like me :)). Working closely together, building good relationships and "allowing" people to do mistakes eliminates the problems.

Conclusion

I have outlined only some problems that regularly occur in team environments here. However, I think they are some of the most important ones and ones that happen in many teams.

The ultimate thing to prevent these problems is to relax and think about what you are doing. Program consciously so to speak. :) Then sit together with your team, make up your mind with regards to how you can improve the overall team culture and things will improve greatly.

Have a good one!
Tim