I think that new people joining a team may well be the best placed to judge the quality of a code base. Since they have very little to no context of the decisions made they only have the code to tell them the story of the project so far.

As a result of this they are the best placed to tell whether or not the code has been written in an obvious way because they will probably have trouble understanding what’s going on if that isn’t the case.

Although following certain design approaches can ease the reading of code for everyone on a team I think that after we spend a while dealing with a level of complexity it becomes normal for us and we don’t feel the pain as much.

Having someone new come in and point this out is invaluable as it helps us to drive towards a more maintainable and easier to work with solution.

Something else I noticed is that the level of enthusiasm that new people have is often much higher than people who may have been working on a project for an extended period of time and could be feeling a bit jaded.

They haven’t fought the battles or experienced the pain that current team members may have done so they arrive with few preconceptions and a desire to improve the way that things are being done.

When combined with their desire to simplify the code, the impact these people have can be quite significant.

An added benefit is that enthusiasm is contagious so some of it is bound to rub off on other members of the team thereby leading to improved morale.

I actually found it quite surprising to notice the impact that new people can have because I’d previously been more inclined to believe that people who had worked on a project for longer would provide much more value.

From what I’ve seen new members to a team can provide a lot of value very quickly so it’s certainly an approach worth keeping in mind.