Just like any project you work on, there are signs and behaviors within a development team that indicate a need for refactoring as well. Before a development team can get to the job of developing quality code, the definition of "quality code" has to be addressed, identified, and agreed upon. I believe this is the most difficult step in evolving a development team's skill set away from the 'slap it together and fix it later' mindset. Why do I think this? Because this is exactly what I'm attempting to do with my current team.In order to convince an entire team of developers to change the way they code, you have to establish a case for _why_ this big change has to occur. Point out where the inefficiencies in the current methods (or lack thereof) are. Make everyone realize that there is a better way. Security is a _huge_ factor because you are asking someone to step out of their comfort zone and learn something new. In fact, many take offense to this notion of improving the way they do things. This brings us to our first Team Smell:There are two things to consider here: 1) the industry of software development is full of bright, intelligent people, and 2) almost every person in the industry thinks they are one of these bright, intelligent beings. This is a potential team killer because the person that thinks he or she knows everything they need to know to develop good code – all too often doesn’t. I don’t want to work with someone that thinks they have nothing left to learn. This is the type of person that eschews Agile practices like TDD because he claims he can create solid, object oriented, sustainable code on his own, without some crazy process to help him along.This might be the most difficult symptom to battle because of the inherent human nature involved. The good part about working with someone afflicted with this condition is that they will often jump into management ;-) . Of course, you know the downside to this - they could become your manager ;-( If this smell is too widespread on a team that you are trying to change for the better, the best choice is probably to find another team and/or place to work. The point of all this improvement is to write higher quality software through better methods. If the vast majority of team members are just too full of themselves to change, then wish them the best as they continue to pump in 70-hour weeks and seek out a place where your peers will be more like-minded.This may seem silly and unbelievable to you, but during my current project I constantly hear fellow developers say, “Yeah, but I finally got this working. If I change this now, it might break, and I just don’t have time for that”. Translation: “I have no idea how my code even compiled, much less how I would go about modifying or moving pieces of it around for the sake of refactoring, especially since the deadline is next week.” If a developer is afraid to dig into the code he or she spent a lot of time producing, chances are the code 1) sucks – in that it resembles a large plate of spaghetti – at best, and 2) has little or no chance of becoming testable without many large, risky refactorings.Defunkifying this smell should be easier to address because it’s simply based on a lack of understanding. Where there’s a lack of understanding, there’s usually a hidden desire to understand because the uncertainty of the work he or she is doing is somewhat unsettling. Many developers in this position simply don’t know how to shed this uncertainty. This is where preaching the value of test driven design should find an eager audience. By working in small, testable chunks, a code base evolves bit by bit, thereby reducing the chance of it becoming too large and fragile. When code is just slammed into place in order to ‘get it working’, what should have been prototype code usually becomes production code b/c the developer is just happy that the junk he or she produced compiles. All too often this type of developer knows the code should be at the very least cleaned up and modularized, much less refactored to patterns and made testable, but he or she knows the trouble they will be in when they try this – so they just let it lie.One of the greatest bi-products of designing test-first is that when a feature is completed (i.e. all uses cases or stories are satisfied) there is a compliment of unit tests that can be run at any time to verify the code is doing the job it’s supposed to. Another great thing about code that is designed test first is the resulting structure is typically _much_ easier to 1) understand, 2) extend, and 3) if necessary, modify. I can’t start any new piece of application functionality now without beginning in a test method. I feel quite secure coding one test-case at a time, constantly thinking about the responsibilities of a class and how it should operate with its dependencies. Working in this way I know that the code was created thoughtfully and with care (as opposed to entire features crammed into 80-line methods that can do 20 things, depending on another 20 possible conditions). And thusly, when the code goes live, it will run as intended with very few surprises.In part two, I’ll identify one or two more Team Smells and how to expunge their foul stench from your working environment.