Over the years I have seen a common pattern when one team or person inherits code from another place – the code is deemed crap. Given it does not always happen, it happens a lot. Managers and team leaders beware! This analysis should come with much scrutiny – especially if the code is very old. If the code has been in a product for many years then it may be “crap” to the new guy/gal but it probably works very well and re-writing it will most likely cause regressions given the newbie could not possibly know all use cases. If the code is relatively young and the product does not work well anyway then that may be a different story.
This is a very fine line given todays tight schedules and demanding clients. I think coding disciplines like code reviews, unit testing and good design reviews can prevent the “crap factor”. In the military we had very tight controls over design and analysis. It can be considered extreme by many but in general every line of code is somewhat “accounted” for by the design, testing and reviews. We should get to the point where “crap” code is a myth and there really does need to be a good reason why a rewrite is warranted.
We are once again in the design phase for the next release of Lotus Expeditor and functionality acceptance, design reviews, documentation reviews, testing reviews and code reviews are already taking place. All of these are a strenuous process on the developers, leads and architects because there are a lot of smart people out there and getting everyone to agree is very challenging. Once again, one of my favorite tools, Rational Application Developer 7, comes in handy when modeling and communicating designs. I have always been an advocate of sequence diagrams, UML and flow-diagrams. I am a very visual person (which explains my poor reading and writing skills) when it comes to learning. Unfortunately I do not even come close to using all of its (RAD 7’s) abilities. Use tools like RAD to get your concepts and design well understood – and even generate some code. By using UML diagrams it presents a clear and concise picture of how the code should be constructed. Outside of that, actually writing “bad” or “erroneous” code at the method level should be caught in a peer code review. Sometimes your peer is your best friend in these cases.