I’m going to post a series of what I call “Red Flags” in development shops. Things that in some development shops happen frequently & also encompass one or more of the following below:
1) Destruct an overall development shop’s efficiency
2) Produce a team environment with unnecessary stress
3) Happen due to lack of standards/process and expectations
4) Happen as the result of bad management, bad attitudes, lack of professionalism, lack of ethics, or just bad business practice altogether
These series of posts really start paint the picture of growing problems in many IT shops today, and ones that just do not ultimately seem to ever get resolved in some shops out there. It also poses a problem for a newbie hunting for some kind of decent work environment (both good code and people).
Knowing about these Red Flags can also help you filter out potential employers that you may think about working for. Maybe many of the red flags were mentioned during an interview you had, such as “unfortunately there are often times our code does not compile”. This is a red flag. Some developers out there just don’t know that this is a huge red flag because they simply have not been given the opportunity to work in a larger development environment and so they don’t have to worry about code compiling when it’s only 1-3 developers. So knowledge of and signs of these red flags as well as steps to fix are just good to be aware of when you’re looking for a new development opportunity.
Also, let me state that I’m not saying that a development shop must be perfect or can be. However lets also be realistic. It’s called professionalism, business process, and standards. They CAN be implemented and enforced or as long as there are checks and balances in place and good managers who care about these things as they should if they are in a management position.
Before I talk about the code compile issue let me also state that YES, developers do make mistakes. That’s the human aspect in which we don’t have much control over. I’m definitely sure in the course of 6-12 months or a year I probably have a couple of instances where I had checked in something that was a mistake. Maybe I forgot to check in a new file or assembly that I had added to the solution. At the same token, while we are all human and make mistakes that’s no general excuse for lack of team training and standards in a development environment. So on the human aspect, don’t yell at a developer if he truly makes a mistake, or doesn’t really understand the process. You give that developer a chance and educate that developer and politely let him know that hey, this is not acceptable going forward for the team. But if there is no standard in place, then you’re going to have a compile mess all over the place outside the human element.
I have personally seen both environments that did have this standard and ones without where the code you brought down always had broken issues in it. In those environments where we did have the expectation to follow the steps outlines at the end here, we loved it. We were able to get our code done then went home…the way it should be. So when I see environments without that expectation and compile chaos, that’s a pretty sad development environment and reflects on management.
Obvious Results with broken code in your Repository :
1) Your team loses time therefore business loses money
- Developers who need to get latest and use that code, are now wasting valuable time focusing on fixing instead of focusing on actual productive work
2) Multiple projects could be delayed now because that code affects other assemblies or other files that people rely upon
3) Developers could make it personal (they should try not to) but a lot of times tempers can flare up which produces unnecessary distractions to other team members while trying to code
4) Build guy also has a problem deploying some unrelated project that touches that code/assembly, so he is now delayed and not a happy camper
5) Possibility of your good developers who do take steps to check in working code, just getting tired of this kind of chaos, leaving them no option but to leave your shop eventually due to burn out or frustration over time
6) Continuous integration / build environment is never obtainable when code is continuously broken
Obvious Factors that contribute to this problem:
1) Poor team lead or manager because they choose to ignore the problem and “address it later”.
- I’m sorry but I give no room excuses here and I think this is the #1 problem. If your environment continually has this problem, this DOES reflect on the lead or manager in my opinion. It tells me they or the people below them have not set any standards around this or talked to the team about this continual issue and taken big steps to reduce the issue for the overall benefit of the team.
2) Clear lack of process & standards in place for a team based on #1
3) Lack of education
- Some developers truly don’t know what a correct procedure is to check-in and check-out code in a development environment. That’s why it’s important for the manager or lead to set the standard (steps) and expectation and communicate this across the team
3) Developer honestly forgets to go through one or many of the steps outlines below
4) Developer forgets to check in a few new files or assemblies that he did not introduce to the repository and so the code runs on his/her machine just fine because they have it locally (on disk), but everyone else is getting errors with that developers code after getting latest
5) Corrupt source files. Sometimes (however rarely) it’s not the developer’s fault at all.
For example: I’ve seen some corrupted classes in TFS and really nobody knows what the hell happened, not even the developer who checked it in as it’s working fine locally.
The correct check-in and check-out procedure:
First, always commit or get latest often. Preferably every 2 days to be somewhat realistic. I don’t feel personally that checking in code every day is possible as we all know there are times we do not want to check in our code yet. Do not wait 1-2 weeks to commit or pull down the latest code in the project you are working on.
Now, the process:
1) Get Latest from the Source Code Repository & Merge any conflicting changes
2) Make sure the code compiles after merging
3) Check that the code actually works ,not just compiles!
4) Now it’s safe to make your code changes & do whatever testing you wanted to do
5) When done with your changes, Get Latest again Merge any conflicts
6) Check that the code actually works ,not just compiles!
7) Finally check it in
It goes without saying, that after you use it, put it back the way it was and in a state that’s useable for the next person in line. It is the exact same analogy here, but just with code.
If you agree, disagree, or have yet another “Red Flag” you want to talk about that you have experienced often, I look forward to your comments.
