You just need to be lucky to hire the right person for the job, and communication during the project should be detailed and followed upon severely.

Alex Holt said on May 04, 2008

I could only dream of such a rate of errors.

A few other commenters have already touched on this, but surely this rate of errors is: a) in direct correlation with the extremely precise nature of the planning that goes into the work they are doing? and b) probably only measured after they have finished the project.

Websites are a much more fluid, changeable domain than rockets? no?

Jonathan Snook said on May 04, 2008

@nate: replicating such a project isn't the goal, but I believe the principles are still the same and while we scratch up web sites as vague, fluid and changeable, often the biggest problem is that they're ill defined. As web experts, it should be our position to help companies and clients understand to clarify those goals and document how best to achieve it.

My biggest takeaway, and what I tried to emphasize in the article, was that good code comes from having people vet that code. Many open source projects are successful for this very reason. Would any project be as good without a second or third set of eyes on something?

Does the fact that we're building web sites give us any more reason not to follow any of the key points mentioned? No, we don't need to go to the degree that they do, but we do need to do it.

Jarrod Goddard said on May 04, 2008

I agree with Nate, their process is definitely overkill for any project freelancers will be taking on, however, the idea of the in-depth QA and testing is definitely something to take away from the article. However, even with that in mind, most of my work doesn't need a separate QA department (really, my QA department is myself, my spouse, and my client). We do need to do testing, but on our scale, the testing doesn't need to be so hardcore.

leveille said on May 05, 2008

I would guess very few of us have rigorous testing in place for the applications we create for clients. The sad truth is very few projects we work on can devote 40-60% or more of the budget to testing. Clients don't want to hear that. They can palate informal testing practices, of which they are normally a critical part of, however formal testing usually isn't going to happen. Formal testing works great in open source projects with a lot of hands and a lot of code reuse, or for projects where the application is handling very sensitive information (NASA's mission critical applications for example), however most of us are not writing these types of applications.

There are practices that I feel should be part of every project. Source control and a solid deployment model. Beyond that, if the developer cares about what they are doing, is invested in the work, and is able to manage client expectations, than the project likely doesn't need the rigorous model you've outlined above.

Brad Harris said on May 06, 2008

I really like the concept of hiring some outside experts to do code reviews. Code reviews is something I take part of on a daily basis at my day job, but I lack that in my freelance work. While it is an extra cost that does impede many freelancers, I think as developers there should be some motivation on our part to improve our code and knowledge, which happens through code reviews. Thanks for the time put into writing these thoughts up.

Mat said on May 07, 2008

Personally, i do think that if you hire a freelancer then there is the definite possibility that they are not going to share your passion towards the software, having just jumped aboard.

If that is the case, then obviously they are going to go for a quick solution over a longer one, implementing other features, etc.

May just be my opinion, nice to check anyone elses on this. Good article though to bring up a discussion.

joe w said on May 07, 2008

Nice article, I too am self taught and I know from my freelance experience that time vs. the alimighty dollar have forced me to take a shortcut here and there(and I hate doing that too) - If only we could figure out the equation to get 36hrs out of the day LOL

Ryan said on May 08, 2008

Heya, we also skip the test phase most of the time...time constraints etc. A once off test here and there is sometimes all we get in. And yes, we do spend alot of time afterwards fixing erros ;-)

Rainer said on May 15, 2008

I am a freelancer for fourteen years now. My conclusion for this topic is that there are few people writing good code and lots of people writing poor code.

It's not a matter of freelance or not and it's not a matter of organizational frames like a MDA approach or extreme programming.
It's just that writing software needs A LOT of experience. Not two years or 5 years. I think about 25 years (that's the time I am doing it now - and I am still learning).

I think DeMarco (who's a guru in the dev business) concluded about the same in his books. It's simple: There are good developers and there are bad developers. Usual teams of twenty people have 2 good guys doing the work and about 18 others doing something else :-)

Andy Kant said on May 16, 2008

I might be a bit biased since I come from a software engineering background, but process is an extremely important part of making quality products.

Warning: This is a bit long, but it covers software process and the reasons for maintaining a quality process.

I wouldn't necessarily say that self-taught freelance developers = poor software, but they are generally not exposed to many of the practices that will improve the quality of their software, thereby resulting in lesser quality software (whether the quality of the software or the process itself). By improving your process, you will save time and money in the long run as well as make things easier on yourself.

Don't just fix the mistakes -- fix whatever permitted the mistake in the first place.

This is a good reason of why it is needed to plan out your software before jumping into development. Generally, writing requirements (whether formal or informal) is part of the planning stages since it will be a big help to guiding the design of the software as well as what Jonathan mentioned: Setting expectations and preventing feature creep. Honestly, I probably spend about as much time designing the software architecture as I do implementing it (its that important). It's also useful to design architectures that are open to change since you never know what will come down the line as well as designing components for reuse (loose coupling).

Another important part of the process which Jonathan mentioned is version control and bug tracking. These sort of go hand in hand as it makes things easier to debug if you can roll back and just do a diff to find the injected code that caused a bug. Bug tracking is useful because it helps prevent bugs from repeating as well as getting re-injected. Never commit broken code to version control unless it's on a test branch.

Code reviews aren't entirely necessary, but it always helps to have a second person participating since they'll think of things you won't or possibly have better solutions. It is very useful in catching errors as well. I think that Jonathan has a good solution to this with going to an external person to review your code but nothing beats having an extra person that is actually involved with the project. Back in college I experimented a bit with having two developers working on the same code at the same time (one watching the other through VNC/Remote Desktop/whatever). The resulting code tends to be better quality since you get two points of view and almost all errors are caught before they get deployed - on the other hand you're not accomplishing as much as if they worked separately, but it's a pretty decent trade-off.

Other important parts are documentation and unit testing. Testing is boring but it will save you alot of grief if you write unit tests so that you can easily regression test your software and prevent bugs from getting back in as well as breaking your software. The point at which many freelance developers fail is documentation. Document your code - document what your code does, why it does it, and what is expected of it. As a freelance developer, you might expect that you'll never forget your intentions, but you will and you will never know what's going on in your software (worsened if you have to pass your software off to someone else). It's also important to document your designs/specs, but I tend to get lazy with this too just because it's boring and it takes quite a long time to do. It is a necessary part of making quality maintainable products though.

As far as improving process, you should always be on the lookout of ways to improve your process - I'd like to think that mine is pretty ironed out by now but there's always something new that you could take advantage of.

Keith Brophy said on May 22, 2008

Intersting article - especially the point of 'Rivalry'.

I would like to stress the importance of point 3 - 'History'.

I think integrating a version control system into the work flow is of extreme importance. The ability to access the source code at all points in its life cycle is very powerful. Further, with the ability to tag and branch - the developer can ensure exactly what is/has been deployed to the client.

Another issue tracking system of note is JIRA ( that provides a very intuitive interface to the world of issue tracking. JIRA also provides hooks into version control systems - allowing an issue to be linked directly to a code commit. The issue tracker can then become a great knowledge resource - the more details added regarding the issue and its solution (with a direct link to the code), the more valuable this resource becomes.

Now - I am off to think of ways to improve my process!

Adult ??hler said on May 28, 2008

I think freelance developers are more likely to do a good job if the client is going to pay them well. I've worked for companies with large overheads and they end up just botching everything because margins are so tight.

Dakster said on July 10, 2008

I don't think pay rates are directly connected to more efficient working and thus good code. Sometimes 'going native' in an enjoyable working environment flicks a switch that makes you want to check, clean and build code you are really happy with whatever the pay rate.

Yes, sadly it sometimes makes me feel good when I write good code for clients :)

Team competition is a great method for good code - there have been a few projects I have managed where we swapped code and made suggestions on each others development work - that was using multiple freelancers to good effect.

In recent years I have noticed projects are pretty much just thrown up and tested once they are live. Clients cash, clients orders - this isnt always lack of capital, it is usually a lead time issue and we dont even have a chance to build anything remotely resembling error free, clean code. Most companies I have worked in that have had excellent development documenting and scheduling; debugging and testing regimes have eventually folded due to cost sensitive clients.

NOVICE said on October 09, 2008

Nice post and ofcourse another learning for me.
I would like to join this whole cool world of freelance software developers.
Is there any place (a website or something) where I can register myself,boast about what I can do in software development , get some work to code ,complete it with flying colours to the customer's satisfaction and get some bucks?(after fixing the bugs ofcourse).
Thank you in advance for letting me in.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.