Code

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.

© 2008 rossboardman.com.