Are Freelance Developers a Recipe for Poor Software?

I recently read the Fast Company article, They Write the Right Stuff, and instantly began thinking of my situation as a freelance developer and what that ultimately means to my clients.

The article talks about NASA and the quality control that goes into the software that drives the shuttle. It's fascinating and impressive stuff.

“Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors.”

I could only dream of such a rate of errors. Of course, the stuff I build isn't as mission critical as taking a hunk of metal with a bunch of people on board and throwing it into space but the four key things that they attribute to success is just as relevant.

1. Planning

At NASA, about one-third of the process is spent on planning. They develop requirements almost to the level of pseudo-code. It's very precise in detailing what the application must do and under what circumstances.

In my development work, I've always believed in the planning process. I'd say I even have a knack for being able to visualize an application before it has even been built. Like a sculptor chipping away at a piece of rock, I have a sense of what is needed. I just have to bring it out in the code. But is my vision the same as what the client wants or needs? That's what the planning process is for.

I like to develop flowcharts showing major pages of an application, and develop the data model, so I know what information needs to be captured. Better yet, would be developing a more thorough analysis of each page and what functionality is expected. I've done this on projects past but don't do it as often as a freelance developer.

As a freelance developer, it may even seem less necessary to document every minutae of a project when you're the only one working on it. However, having documentation is important as it sets client expectations. It also helps avoid feature creep as you have something to refer to as a baseline and can stipulate that changes to the requirements cost extra.

2. Rivalry

Within the shuttle software group, they have two key teams: the coders, and the verifiers. They're pitted against each other in a way that ultimately produces better code.

"They're in competition for who's going to find the errors," says Keller. "Sometimes they fight like cats and dogs. The developers want to catch all their own errors. The verifiers get mad, 'Hey, give it up! You're taking away from our time to test the software!'"

I'm a self-taught developer. Everything I have learned over the years has come from just building things, reading articles on the internet, and reviewing the code of others. I have no formal learning. While this has worked well for me, for the most part, I always feel that I would've liked more people to bounce ideas off of. It's great to be able to brainstorm with other people to achieve a solution that seems the most straightforward. It would've also been nice to have a solid foundation to build on top of. What algorithms should be used, what patterns can be implemented?

As a freelance developer, there's no rivalry. Just the victory in having the client not notice where things might go wrong, or the disappointment by myself and the client when an error is found. The client is the only person who provides any independent set of eyes on what I produce.

The heart of the title is in this very specific point: with nobody to review and critique the quality of product I'm developing, is the product I'm putting out there any good? Is there a way I can restructure my code to make it faster, easier to maintain, and ultimately better for this client and the next?

This is one area where I'm particularly trying to address by hiring people to do code reviews, both for the JavaScript and CakePHP development that I do. For CakePHP, I'm looking to some of the core CakePHP developers via Debuggables and the Cake Foundation. Who better to look at the code I produce? For JavaScript, I put the call out via Twitter and received the names of a few people I can rely on when needed. (Many thanks to those who responded.)

As a freelancer, it's my responsibility to seek out others who can act as my rivaly and do so in a way that makes me strive to create better code.

3. History

There are two large databases at the shuttle software team: one that records the history of every change ever made to the application and another that logs every single error found in the application.

Any development, large or small, should have two key pieces of software at their disposal:

  • Version Control: There are a few different tools and it comes down to using what you feel comfortable with. Look into CVS, Subversion, or Git for more information.

  • Bug Tracking: There are plenty of bug tracking tools such as Trac, Bugzilla, and Fogbugz.

I have to admit to being lax on both of these points. I'm hit or miss when it comes to setting up a new Subversion repository for a new project and bug tracking is often left to collecting client emails into a to-do list. A more formal process would be good to establish on any project that I develop. Which leads into the fourth and final point...

4. Process

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

The key to success isn't the lack of mistakes; mistakes are bound to happen. How you deal with clients, how you code, whatever it is that you do in your professional career or even in your personal life is a learning experience. It's important to learn from the mistakes and make sure that a process is put in place to avoid the problem from happening again.

If it hasn't been evident throughout this post, I'm still changing my process and will continue to change my process to become a better developer. If there's one thing I've learned about freelance, it's that it is a journey deep into personal discovery.

Do you re-examine your process on a regular basis? Do you have the ability to see where things are working and where they're not? Take the time to review things and change the process.

Published May 02, 2008
Categorized as Business
Short URL: https://snook.ca/s/891

Conversation

21 Comments · RSS feed
Damien said on May 02, 2008

That's an interesting thought on the mentality of an independent software developer. I personally do a lot of inward thinking whenever I find a problem with something I've done, weather it be in something I've worked on or a breakdown of some sort. Unfortunately, that doesn't always turn into a change in my process. Much like a change in lifestyle, it's hard to change regular habits (though that isn't an excuse for not trying).

I'm curious, how do you think these concepts apply to an open source project like CakePHP or FireFox? I imagine while a small development project doesn't get as much time invested in planning and bug tracking, larger ones certainly do. Would you argue that these projects suffer less problems because of that?

Paul D. Waite said on May 03, 2008

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

Word. I think there’s a principle like that in Toyota’s lean manufacturing approach, “the five whys” or something. You repeatedly ask why a problem happens, to get to the real, fundamental root cause.

Greg Newman said on May 03, 2008

It's ironic that you are posting your thoughts on this subject. Although I did not read the article (yet) that you link to, I have implemented a new system for my freelance work.

I've always spent a lot of time on planning and documenting but over the past year have focused on more documentation during a project. I keep a log in a moleskine, (outside of existing code documentation) of potential errors and errors I make through the life of the project, trying to keep them down to a short list by completion. Then I revisit that list after completion and analyze what could have been done differently to avoid the mistakes. I have found over time that the list gets shorter with each project.

I'm like you in that I have no formal training; am self taught. You hit the nail on the head Jonathan:

Freelance: ...it's that it is a journey deep into personal discovery

And what a journey it has been.

George said on May 03, 2008

In many projects, when time gets to be a luxury, testing is the first thing that drops off the plan. Maybe someone should start a company that tests code for others... Hehe.

Eugene Sutula said on May 03, 2008

@George: Actually there are few services for testing already available. Take a look on trybeta (trybeta.com) for example. Once I had an idea to make similar service to test websites.

As for the NASA... When I was writing my master's work my classmate had a theme "qa of code by errors sowing" or something like that. I know such approach is used in rocket science. They "sow" errors in different places of system to analyze how it will work with errors. Pretty complicated but interesting stuff.

nate said on May 03, 2008

After reading the article, my conclusion is that, while we can learn from their process, replicating it, or even an approximation of it, would be almost if not entirely impossible within our industry.

The entire foundation is based on having a very exact, very detailed specification of precisely how the software is intended to function under every condition and change of state. From that, the code an almost write itself. Contrast that with the typical client on a web development project, who half the time has only a vague sense of what is it they want, if any at all.

Johan said on May 04, 2008

Are Freelance Developers a Recipe for Poor Software?

If you would work for the first time with that person, anything might happen.
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 (http://www.atlassian.com/software/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

Hey,
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.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.