Developer Sitting with Laptop

Could this developer add value to your business?

Figuring out how to hire a developer or a team of developers that can actually deliver on their promises is one of the most difficult challenges that a business can face.

If you’re struggling to figure out what things you need to look for and how to actually compare developers, apples to apples, do not despair. There are many factors that help level the playing field when interviewing a candidate software development vendor.

We’ll teach you 3 critical practices that software vendors must master to deliver high-quality software, how to consistently interview potential vendors, and how to quickly compare the responses you’ll receive.  Writing each answer down and comparing the clarity of the answers you receive will allow you to choose the vendor who is most prepared to set your software project up for success.

1.  Establishing the Software Architecture from the very beginning lays the foundation for long-term project success.

The first thing you need to figure out is if your developer considers the architecture of their projects from the very beginning. This is especially true if you intend for the software to grow with your business. The software architecture is the plan for how all of the project’s code is organized.  Figuring this out up front is critical to the project’s long-term success. A robust architecture serves as a guide for the developers as your project changes and grows.

Architecture Blueprint

Measure twice. Cut once.

Imagine trying to build a house without a blueprint.  Building out the first couple of rooms might go smoothly, but it would be very difficult to add an en-suite to the master bedroom if you did not leave any space for it when you started building.  These are the sorts of problems that development teams regularly face when building business software.  Businesses pivot and improve processes regularly. The software must be flexible enough to accommodate those changes easily.  The best way to achieve that level of flexibility is by establishing a robust software architecture before starting to build.

What to ask your potential vendors:

A side benefit of a robust architecture is that other software developers can pick up the code and begin to work with it quickly and easily.  You can use this fact to your advantage when you’re interviewing potential software vendors by asking

Could I easily hand the project over to another team if you’re unable to continue work on the project?

The vendor should clearly and concisely communicate the steps they take to make the project easy to work on for themselves and why another team could pick it up easily.  They should be talking about code organization, or may even mention architecture directly, and they should explain it to you in a way that makes sense.

The bottom line:

It is unlikely that the vendor considers architecture up front if they cannot clearly and concisely explain why their software could easily be handed off to another developer.  These vendors tend to lack good code organization practices and the long-term success of your project may be at risk should you decide to employ them.

2. Utilizing an Agile approach to the development process keeps you in the driver’s seat and allows for easy changes to the original plan.

In the words of former heavyweight world champion Mike Tyson, “everyone has a plan until they get punched in the mouth.”  Throughout the course of your software project, prepare to be metaphorically punched in the mouth.  Repeatedly.  The likelihood of your software sticking to the original plan approaches zero as the size of the project grows.  This is a universal truth across all projects.  There are so many variables that can affect the course of the software project:  the business plan may change, you may find a better way to perform some business practice, or perhaps you will find more ways that software can help your business after the project starts.

In the not-too-distant past, the entire project was detailed up front, then written over months (or even years), and, when it was finally finished, the entire product was delivered to the client.  It was at this point that the client realized that what they asked for was not actually what they needed.  The client must decide whether to throw that work away, come up with funding to make the necessary changes, or try to make the inadequate product work anyway. Since change is inevitable, modern software development teams utilize an agile methodology that allows them to pivot right along with you.


There is no one-size-fits-all. Alterations must be made for a good fit.

Agile methodologies break up the work into small, fully functional packages called deliverables.  Each time a new deliverable is provided the client can review it and suggest changes that he would like to see.  The vendor and the client will then decide if the change is appropriate and will re-prioritize the plan as necessary.  In the end, ensuring that the client is fully aware of what the finished product will be throughout the entire project dramatically reduces the cost of the project and delivers a product that’s actually useful.

What to ask your potential vendors:

There are two main issues that you need to address to establish that the vendor has a strong agile methodology.  You must first confirm that you will be in the driver’s seat by asking

What is the process for making changes to the project as it goes?

and you must also ensure that you can monitor progress by asking

How will I see the work that’s being done during development?

The vendor should clearly and concisely communicate their development methodology in a way that makes sense to you.  They might use some industry jargon that is in fashion these days.  Some good keywords to look out for are “Agile”, “Scrum”, and “Kanban”.  One word to avoid like the plague is “Waterfall”.

The bottom line:

It is unlikely that the vendor follows consistent development methodologies if they cannot clearly and concisely explain how they provide feedback and keep you in the driver’s seat. These vendors tend to have difficulty communicating consistently and pivoting efficiently alongside their clients.  The likelihood of you receiving a software package that satisfies your actual business needs may be at risk should you decide to employ them.

3. Adherence to Change and Release Management systems guarantees that your software is always operational and does nothing more or less than what it’s supposed to.

Once you have a solid piece of software that you think is ready to serve your business, you’ll be ready to go to production.  Going to production simply means that the software is live and producing value for your business with real users and data.  At that point, the integrity of your software and the data it produces is absolutely critical.  Change and Release Management is a systematic approach to guaranteeing that the process of making changes and releasing those changes for your users is always consistent and without side-effects.

Automated Machinery

Tools help us do the job quickly. Automated tools do the job right every time.

One of the most infamous case studies regarding a lack of change control is the story of Knight Capital Group.  On August 1, 2012, Knight Capital released an untested change to their system.  Knight’s system relied on the coordination of eight servers. The technician in charge of releasing the change copied it to seven of the servers, but forgot the eighth.  Within forty-five minutes the system executed over 4 million orders on 157 stocks totaling more than 397 million shares.  When the dust settled Knight Capital took a pre-tax loss of $440 million.  The company evaporated overnight and nearly 1,500 people lost their jobs.

While Knight Capital is, admittedly, an extreme example.  Change and Release Management is critical to every software project.

What to ask your potential vendors:

To determine if the vendor uses any strategy toward managing changes ask

Once the software goes live, how can I be sure that changes that I request won’t negatively affect production?

You should listen for the vendor to explain that they use tiered development environments.  They might mention “development environments”, “testing environments”, “UAT environments”, or “staging environments”.  These “environments” are duplicates of the system that do not have real users and data.  Those environments can be used to safely test changes before releasing them.  The vendor earns bonus points if they mention that they utilize some form of automated testing.

After the vendor makes changes you need to be sure that they will consistently release those changes to the production system.  You can gauge the vendor’s release practices by asking

How will changes to the software be released to production?

All software development vendors should be using some form of “automated deployment”.  Automated deployment systems guarantee that releases are performed correctly on all required servers and machines.  Automated deployment systems are also responsible for migrating changes throughout the tiered development environments to be sure that the changes that are released are only the changes that have been properly tested.

The bottom line:

It is unlikely that the vendor can guarantee your software will remain operational if they do not utilize tiered development environments and automated deployments.  These vendors tend to have inconsistent or poor adherence to change and release management systems and the likelihood that you will not experience significant outages or critical operational errors may be at risk should you employ them.

Conclusion:  Putting it all together.

Software Architecture, Agile Methodologies, and Change and Release Management are three critical areas that all work together to prepare your project for success from start to finish.

We’ve provided some things to look out for regarding each of those categories, and that’s a good start. However, the most important thing overall is that the vendor can answer your questions in a way that makes sense to you.  When you reach out to potential vendors and start to ask these questions take a moment to write down a quick score from 1 to 5 on how well you were able to understand their explanations.

Utilizing these questions, you can quickly and consistently compare the vendors you contact and identify the vendors who are best positioned to successfully produce a software product that actually provides real value to your business.

If you’re currently looking for a software development team or custom software for your business, please give us a call.  We’d love to answer each and every one these questions for you!