> Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. Any good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in.
Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:
1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.
2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.
3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.
4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.
Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.
I've actually been thinking about offering a code review service, since it would fit well with the way I like to work. Personally, I wouldn't want to do one-hour reviews, but would be very happy selling four hour blocks of my time.
A third-party code review could easily point out certain problems that aren't only qualitative (e.g., the code is vulnerable to SQL injection attacks). It could also be useful to evaluate programmers. The project owner hires a few different developers to write a single user story, the reviewer tells them which code is the highest quality, and the project owner hires the best coder to do the complete project. For slightly more corporate clients, it could also be used to identify to a non-technical manager where their programmers need additional training.
As far as the reviewer being asked, "How do I fix it?", that could lead to the reviewer offering training material, libraries, or development tools.
Sounds like a good idea to me. The biggest problem is establishing credibility, and deserving the credibility. The code reviewer really needs to be up to the task.
While you make a lot of good points, I'd note that you're more likely to know a good enough, if perhaps not expert-level developer who has some time to do code reviews, than one who has enough time to actually do the work.
Or at least I've done this before. With, I'll admit, at least one instance where I raised red flags which were ignored for a long time until I was finally hired to deal with a by then terminal* as it turned out mess.
* Before the company could be saved the early '90s recession killed its profitable line of business.
Generally-speaking, an "expert" is not likely to be interested in periodic code review engagements:
1. Most "consultants" aren't working on an hourly basis, at least one free of reasonable minimums. In other words, good luck finding an expert-level developer eager to take on periodic hour-long "Is this code okay?" projects.
2. A real code review consists of more than just a cursory "this is good code, this is bad code" analysis.
3. A code review doesn't really help a client who doesn't have the ability to rectify issues that are discovered. I can guarantee you that a consultant asked to perform a code review in the scenario described here will nine times out of ten find himself being asked "How do I fix it?" Unless the client is prepared to pay for the skills of a quality developer, getting involved in a "How do I fix it?" discussion is going to be a tar baby for the consultant in question.
4. The author is generally distrustful ("Don’t trust reviews or portfolios", "the motivation of most freelancers directly competes with writing concise code") yet curiously he doesn't consider the possibility that the "expert" you bring on to review your code, if he's looking for development work, has an incentive to raise questions about the quality of the code.
Not all of the advice here is bad, but I think the author generally glosses over the fact that finding good freelance developers and doing so when you have limited technical skills and experience managing the development lifecycle is difficult and may not be a viable approach.