Red Flags for Project Managers
Warning: file_get_contents(http://feeds.delicious.com/v2/json/urlinfo/data?url=http%3A%2F%2Fstephennimmo.com%2Fblog%2F2007%2F12%2F20%2Fsome-red-flags-for-project-managers%2F) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.0 999 Unable to process request at this time -- error 999 in /home1/stephenn/public_html/blog/wp-content/plugins/digg-digg/dd.class.php on line 866
"We don't need code reviews"
Everyone benefits from code reviews. The junior developers benefit from code reviews by being exposed to new code and new ideas. The senior developers benefit from code reviews because it allows them to mentor junior developers and at the same time refine their processes for development. Managers should LOVE code reviews because it allows the team to become more efficient, leveraging others work and streamlining repeatable development issues via application of patterns. Managers should also love code reviews because it exposes the weak links. No longer will the individual developer be able to just turn in their code, have it work and not have the work scrutinized. In my opinion, a majority of the headaches dealing with "legacy code" could be averted with simple checks and periodic code reviews by management. If any developer does not want to do a code review, you can imagine why.
"It won't help performance, so why bother refactoring?"
Performance is very important. Performance is required. Performance is not the ultimate litmus test and should be handled as a single, very important aspect of software development. Think about it this way, if performance was the ultimate benchmark, then we would all be writing in assembly language on a mainframe. Like it or not, good coding is just as important to a project and refactoring is a major part of what makes a project successful - in the long term. When approaching a subject to refactor, there should be several things in the mind of the developer. First, will this change affect performance? Secondly, will this change be so great as to require massive regression testing? Thirdly, will this change greatly increase the chances of saving the next developer time and effort in coding a module? So if you can refactor something that doesn't necessarily improve system performance, doesn't require massive regression testing (which shouldn't be a big deal if you have your automated testing and build process set up) and will save the next developer(s) that require/touch this module time, why not? Performance is great but should not be the only concern.
"I really don't care what other developers are doing."
Have you ever walked into a new project and started looking at the codebase only to realize developers have been getting database connectivity three different ways? What about 3 different sets of constants files? Or perhaps you changes a factory to return an new implementation of an existing interface only to have regression testing fail because a colleague decided they would just new some DAOs or Services? I mean, who needs a factory when all the factory does is say new Object()? Every developer should care what the other team members are doing because there is a good chance you will end up maintaining that other developers code when they win the lottery or get eaten by sharks.
"I don't have time to refactor anything."
Chicken and the egg. You don't have time to refactor because you are too busy forking through a huge pile of spaghetti. But if you would refactor badly written code, you wouldn't have to wade through the piles of garbage, thus saving you time and giving you the opportunity to refactor more badly written code. The question is: Would you take an 8 hour hit NOW if it would save you 40 hours over the next month? If you can't afford the time to do it right, how are you going to find the time to fix it later?