Refactoring: Why do we get into that situation in first place?

Refactoring is a process of modifying the code without changing the software behavior. Re factoring is required to make the design robust and flexible for future code modifications and more importantly increasing the code readability. In lifetime of software most of the times, the code is read than written or modified. More time required in reading/understanding the code than time taken to make the actual changes because modifying the code without understanding it property there lies the risk of introducing the new bugs.

I was just wondering why do we even get into the situation where we've to refactor the code? Well, this is tough question to answer. So my say is that the complexity of the software is directly proportional to the number of developers. While this is the fact, what if we have few developers(4 for example) who are always there to write and own the code and only those modify? Lets say that these four developers have been given the clear instruction that they have to follow all the design principles and guidelines that exist for object oriented languages. Over a period of time do we still get into the situation where we need to refactor the code? 

Before seeing what's the conclusion on above question, let me write some of the essential facts that happen in software life span especially in legacy software.

1. Different developers have different coding styles and different way of thinking this may happen due to developers being in different experience level. The same developers will not be there for ever to own the code. The extra time for correcting(refactoring) the old code is not planned/forgotten while making a fix, adding a new feature or during code reviews, the focus will be on the current issue being resolved than bothering about rest of the code 

2. No one initially designs the systems for better performance and future requirements. As a best practice, the systems are designed only to address the current requirements. And requirements change over the curse of time and you are bound to modify the code to accommodate the new requirements.

3. Sometimes performance comes at the cost of not following certain design guidelines. The straight example is that method calls are costlier but OO design guideline says that methods should be smaller. 

4. Lack of having sufficient unit test cases specially automated unit test cases. Unless the team is following TDD(Test Driven Development), the developers do not bother touching the code which does not solve the current issue.

So the discussion where in you hire expert developers with same experience level who will be writing the code from the scratch and also will be owning the code for future modifications. Does this team write and maintain the good quality code that does not have any code smells? We've not tried this but the opinion of many (with developing experience of more than 10 years) was No. There may come one of the above four aspects on the way and there could many code smells which are resolved by refactoring.

Though its impractical or tough task to have good quality code that follows all the OO design guidelines over a period of time, efforts to improve the code quality are advised. Refactoring can not happen overnight, and hence there we have introduced something called "Continuous refactoring"