Choosing a Software Development Partner: Evaluating Experience

Nov 25, 2020 2:30:00 PM

programmers at work on computersWho would you rather have re-piping your home:

  • Someone who just finished graduate school with a master’s degree in fluid dynamics?
  • Someone without a college degree who has been a professional plumber for 15 years?

Chances are good you’d choose the second one. Why? Because education gets you only so far. Experience is what counts.

It’s just as true in software development as it is with plumbing or any other occupation. It’s necessary for a software developer to have a solid foundation in the principles of software development and knowledge of various programming languages and technologies. But experience with real-world, successful projects is what potential clients should be looking for.

In today’s article, we’re talking about software development experience. Lots of software development partners and individual developers have plenty of “experience” in one thing or another. But developers aren’t interchangeable parts; there are many specialties in software development. Someone skilled in firmware development might be completely lost when it comes to user interface design.

If you know little or nothing about software development, it can be tricky to evaluate the experience of a potential software development partner and how it might be relevant to the project you have in mind. However, here are some things you can look for.

Project-Type Experience

Even if you don’t have a clear idea of the technical details, you likely know what type of software project you’re contemplating. The high-level categories include:

  • Back-end software (operating systems, services, and other “behind the scenes” software that keeps systems running)
  • Firmware (software that controls the operation of a piece of hardware)
  • User-facing software

You may or may not know what you’re seeking within one of these categories. For example, if you know (after doing proper due diligence) that you need a mobile app and only a mobile app, you can look for partners with experience in mobile apps. They don’t necessarily need experience with other types of user-facing software.

However, if you don’t know what type of software you need within a particular category, then you should look for partners with a variety of project experience within the top-level category.

For instance, you might not know whether your user-facing software project should be a standalone PC application, web application, or progressive web application. That’s okay, as long as your software development partner has experience with all of them and can analyze the pros and cons of each for your particular situation then make an informed recommendation.

Either way, how do you judge a potential partner’s experience? You ask for examples and references. How many projects of the type you want have they done? How well did those projects achieve their aims—that is, did the clients realize the benefits they were seeking? Were the projects completed within the established time and cost estimates?

Technology Experience

Here, “technology” means a specific technological approach to solving a problem. For example, artificial intelligence is a technology that might or might not be the best basis for a particular software solution.

Evaluation of technology experience is similar to project-type experience: If you know your project requires a certain technology, then you can look for partners with experience in that technology. If you don’t, you need a partner experienced in several relevant technologies that can determine the right one for your project.

Methodology Experience

Almost all software development shops these days use some form of Agile development methodology, so it’s not much of a differentiator anymore. A software development shop that touts its use of Agile is like a car dealership that boasts its cars have wheels.

What can be a differentiator is what the shop does with Agile and how long it’s been doing it. The best shops have developed their own flavor of Agile and have refined it over the years.

So, it’s appropriate to ask potential partners to describe their methodology, what’s unique about it, and how long they’ve been using it in its current form. If they just started using their current methodology a year ago or if they’ve made frequent, dramatic changes, it’s a sign they haven’t quite figured out what they’re doing as an organization.

Team Experience

Some software development shops will claim their developers have 100 or 500 or more years of experience among them. Although the raw number sounds impressive, it’s not an especially meaningful metric. (if, for example, few or none of them have experience relevant to your project, it doesn’t matter how much they have.)

A better question to ask is how much experience they (including developers, testers, project managers, business analysts, and so on) have working together as a team.

Teams with lengthy experience together know each other’s strengths, weaknesses, preferences, and habits. They have settled on a way of working together that optimizes these traits. This characteristic is advantageous because their projects tend to run smoother and finish sooner with higher quality.

By contrast, shops that have a high turnover must start this process all over again every few months. In many cases, they never achieve that essential team cohesiveness. This is detrimental to efficient, high-quality project execution.

Bottom Line

All else being equal, is a software development partner with 20 years of experience twice as good as one with ten?

Probably not. Although the fundamentals of computer science and software development are stable, technology changes occur at a rapid pace in this industry. Experience from 10 years ago might have little relevance today.

Thus, the number of years of experience a team or individual developer has is less important than what they’ve achieved and how relevant it is to your business problem. This is where client references become so important because they can answer questions such as:

  • Did the project encounter any obstacles? How did the partner overcome them?
  • How well did they address your goals?
  • How well did they meet the estimated project time and cost?
  • Was the partner able to understand your business problem, explain different approaches, and make a recommendation?

Positive responses to these questions are a much better indicator of experience than the number of years.

An experienced partner will deliver higher-quality software with fewer unpleasant surprises. By asking the right questions, you can settle on a partner with experience you can count on.

LET'S TALK

Brian Geary

Written by Brian Geary

Brian is a true believer in the Agile process. He often assists the development process by performing the product owner role. In addition to his technical background, he is an experienced account manager with a background in design and marketing.

    Get in touch

    LET’S BUILD SOMETHING AWESOME. TOGETHER.