Picking the Right Development Shop

By Kristopher

The success of your project or website depends heavily on the quality of the company you hire to develop it. A common misconception is that with quality comes high price, but this isn’t always the case. The success depends entirely on whether the development company knows what their doing or not. There are just as many small, lower priced shops out there as large, over priced and over hyped shops.

We’ve put together a list of questions and concepts you can bring up with prospective companies to determine if they’re worth your money.

  1. Ask for an expanded list of projects and references
  2. What is the requirements gathering and design process for the project?
  3. What is the development process for the project?
  4. Who is responsible for testing?
  5. What happens if something is missed?
  6. Does this shop use bug tracking software, and do you have access?
  7. Does this shop use a version control system?

Ask for an expanded list of projects and references

Chances are, every shop you meet with is going to have a prepared list of projects they’ve worked on and references for clients they’ve worked for. This is helpful, but keep in mind that this is a predetermined list of projects and clients. It is likely that they won’t included projects that have gone bad or clients that are disgruntled with the work that was done. It is also pretty likely that they already informed these clients that they are being used for a reference and they’ve already ensured that it’s going to be a good one.

So when you get this list, ask for more and see what you get. Better yet, if they have a list of recent projects and/or clients on their website, follow up with those people yourself. Even if the project was rocky or the client is unhappy, the shop will still probably list the project on their website. These are the people you want to talk with, and, after you do, bring up your findings with the shop. If you’ve uncovered something negative, try to get their side of the story.

This will not only help you better gauge the value of the company, but also give you a good idea of what to try to avoid with your project.

What is the requirements gathering and design process for the project?

One very important item to address is the requirements gathering process. This is where the development shop figures out exactly what you need, exactly how you want it to work, and what all of your business rules are that need to be implemented into your site or application. It is important for you to ensure that this process is going to take place. Depending on the size and scale of your project, this might take several meetings and is an iterative process.

If this project is an application, especially a business application, it’s also important that at least one developer and business analyst are involved in these meetings, because project managers and salesman often don’t know anything about programming, and it’s likely they don’t know much about accounting, manufacturing, etc. If your project has a lot of processes and business rules, it’s important that someone with a sound foundation in these principles is involved in the requirements gathering.

After all requirements are gathered, the next phase is usually to draft a design. This is a bit abstract, but this often outlines how the project will function, and should outline all processes within the application. It should also outline any workflow that is needed as well as how the uesr will interact with the data. This may also sometimes show or describe how the site or application will look. The design should be a natural progression from the requirements and should explain to you how the development shop plans implement and address all of your requirements.

The requirements and design process are the most important part of the application, as without a clear road map, you’re not going to arrive at your sought destination.

What is the development process for the project?

After requirements are complete and design is approved, the development company normally moves into full development, which is taking everything designed and turning it into a real site or application. It’s important that you know exactly how this process will take place before you sign a contract.

Each project should have a predetermined set of milestones, and each milestone should have a due date. This allows you to track progress of the project at a functional level. It also provides the basis of a task list for the developer to stay on track.

It’s important to know what the release schedule is as well, and how they relate to the milestones. For instance, will you get to see iterative snapshots of the application as it is developed, or will the development shop disappear for 6 months and magically return with a completed application? At the basic level, most shops usually provide a beta or preview release after each milestone is completed. This is important for a number of different reasons.

First, it gives you peace of mind to know that work is being completed and gives you the ability to look at it and make sure it meets the specifications laid out in requirements and design. Also, it allows you to begin doing user testing on it and look for gaps in functionality and missing features. It’s normally cheaper and easier to identify these as development progresses, rather than at the completion of the project.

Who is responsible for testing?

This is a big one. It is highly important to know what kind of testing the development shop will do. Any programmer should do unit and functional testing to make sure that every piece of the application functions as written and no (or as few as possible) bugs or errors exist in the system. But who is responsible for use case testing?

Ultimately, it is up to you to verify that the project was implemented as requested, that all requirements were met, that all business rules are validated and the site or application works as you expected. But will the development shop do their own user testing first? Will they make an attempt to make sure all the conditions outlined above are met?

The difference here will determine how long you spend doing testing yourself. If the development shop did no testing and you end up finding a large number of bugs, it’s going to take quite awhile to get through this phase. Remember, each new release needs to be completely retested to make sure that changes are implemented properly and don’t affect other aspects of the application.

When the development shop does a large amount of user testing before delivering, it will severely cut down on the time you need to spend trying to break the application.

What happens if something is missed?

There’s nothing more frustrating on either side of the table than finding a big requirement that was missed, meaning that it was never even discussed. How does the development shop handle this? Do they charge for every feature added after the fact as scope change, or do they offer a little leeway depending on the size and number of changes?

If they are going to charge you to add in a missed feature, is it something that they should have caught? One of my favorite quotes from jobs past is when a project manager told a client that we would have to charge for the missing feature, and the client responded “So you didn’t know ahead of time that the brand new house you’re building me needed to have electrical outlets in it?

You should always assume that a development shop is an expert in their field, but know that they assume you are experts in yours. It is your responsibility to bring up all aspects of what your application needs to do and how it affects your business. At the same time, you would expect a development shop to know that an invoice has an associated customer, and that an order normally has a dollar value assigned to it.

Does this shop use bug tracking software, and do you have access?

Regardless of how awesome we think we are, we can’t remember everything, which means we can’t keep track of all bugs we come across in our head. And keeping track of them with emails and scribbled napkins isn’t perfect either. But software never lies.

Does your prospective development shop use bug tracking software to keep track of all issues you run into? Better yet, do you have access to this software to review the status of bugs and maybe even submit them to the system on your own? This can help streamline the communication process by allowing you to submit bugs yourself, review the status and provide comments on the bug, all without bothering to email the developer. That allows him or her to keep heads down on building your system.

Does this shop use a version control system?

While this one is likely way off your radar unless you have an IT department working with you to evaluate development shops, it’s just as important as other questions. A version control system, such as Subversion, Git, Bazaar or CVS, is a system that allows multiple developers to work on the same code base without overwriting each others changes, and allows developers to keep track of changes made to the source through an iterative process. So why is this important to you?

If your project is large and has multiple developers working on it, this software will allow them to be much more efficient by allowing them to work separately but easily allow them to merge their code together. It also provides a revision history of the source code, which provides a safety net for when things go wrong, such as the developer introducing bugs, or a feature that was removed but is wanted again. Version control allows the developer to go back in time to see which pieces of code were changed, and allows them to selectively pull old code back out.

Simply put, version control makes it easy for multiple developers to work on a project and can help save a project when things go wrong.

These seven topics will help to grow a constructive conversation with prospective development shops to help you determine whether or not they will be a right fit for your project, and whether or not they will be able to successfully and satisfactorily complete your project.


4 Responses to “Picking the Right Development Shop”

  1. Kieran says:

    What a great topic, especially on this site. I’ve seen so many customers fight a losing battle simply because they didn’t understand the process. I always feel like part of my job is to educate our customers. It makes me feel more comfortable, and I’m sure it makes them feel more comfortable as well.

  2. Josh says:

    I have to say, one of those points you made above is definitely worth noting for freelance developers as well… If someone approaches you with a freelance job they want you to participate in, it would most certainly behoove you to ask if they’re using a version control system.

    I recently worked on a project in tandem with a web development firm, and it was nightmare after nightmare because there were multiple developers SSH/FTP-ing code changes and additions at the same time!

    I can’t count the number of times I added a feature on the list and then had to go back and retrace my steps because immediately after I uploaded the new code, another developer uploaded THEIR new feature that they added, thus overwriting mine.

  3. Josh says:

    Actually, on that note… That too might be a noteworthy question worth asking your prospective development firm… Whether or not they ever have, do, or have intentions to use freelance developers on the project.

    A development firm may have an outstanding portfolio, but if they outsource certain portions of the development, you’re leaving the credibility of the freelancer at the sole discretion of the development firm if you leave this rock unturned.

  4. Kristopher says:

    Josh, those are some very good points, thanks for sharing. I’ve been stuck working on projects with other developers without version control before as well and can confirm that it’s a living nightmare.

    The company using freelance or contract developers on your project can lead to great success, or dismal failure. It really is a crap shoot. Definitely something worth inquiring about and figuring out how well the company trusts their contract developers and how reliable they are.

Leave a Reply