I’ve recently run into several clients who’ve been burnt by contract developers.
There are some obvious financial reasons to contract remote developers in different countries, but the practice can lead to problems.
The problems my clients have had break down into two areas:
- communication issues
- code quality
Today I am going to focus on Code Quality. I will write about documenting your requirements effectively another time.
One of my clients needed some very simple changes made to an application. I opened the code up and knew instantly that there had been some very average programmers involved. Files and folders everywhere, with names like “Accounts”, “AccountsOLD”, “AccountsBAK”. To a good programmer this kind of sight is an instant warning - good code is organised, clear and sensible.
I still had hope - code may be disorganised from having several developers work on it, but not necessarily be bad.
However, once I started delving into the code itself, the situation became much worse.
The code structure was just as disorganised and incredibly convoluted. Now, you may be thinking, “if the site is running, who cares if some programmer doesn’t think the code’s nice?“, but the crucial thing here is that bad code costs money. Just in case you missed my point:
Bad code costs money
Instead of having a few simple changes to make, I now had a few difficult and complex changes to make.
The bad code meant that I had to revise my estimate. So I revised my quote. Up. 1 hour of work became 5.
This is great for me, as a contract developer charging by the hour, but really bad if you’re trying to run a business on a budget.
Unfortunately, as I explored further things went from worse to really really worse.
The code was not just bad, but dangerous.
The code was wide-open to a couple of well-known security problems called SQL Injection and Command Injection. These are the code equivalent of leaving the front door open. To a good programmer, they are too obvious to even really worry about - good practice avoids these issues in much the same way you lock your front door when you go out. You don’t really think of it as a security measure, it’s just what you do.
Good code is automatically protected from these obvious security holes.
These problems meant that anyone could gain access to the system and take complete control of the site.
The client’s code was riddled with these issues. In fact, all of the code was vulnerable - like someone had built a house with no doors at all, just holes in the walls. The unfortunate fact is that fixing the code will be a long and involved process because the code was so badly organised and written in the first place.
What can you do?
Using cheaper developers is a business reality. Not everyone can afford to hire the best software developers in town.
However, an independent code audit and review can help ensure your project is on track by providing an independent and expert view of development progress. And if your code is complete, an audit can ensure that your product is rock-solid and production ready. And a code audit gets you the knowledge of an expert without all the cost.
A code audit would consider one or all of the following issues:
- Application Security
- Scalability & Performance
- Code Conventions
- Code Quality
- Test Coverage
- Data Privacy
- User Interaction
- Information Architecture
A code audit can catch average code before it goes bad and it could save you a ton of money in the long run.
[...] keep projects on track, and might be a nice source of extra income. I’ve written an article about Why a code review could save prospective clients money. __________________ toby hede ————— Toby Hedes Blog on Ruby, Rails, User Experience [...]