Developers

Is the company an individual developer or is there a team of developers? If it’s an individual, do they have a backup plan if they get hit by the proverbial bus? Individuals can be great developers, but it’s good to have a plan B.

If there is a team, are the developers dedicated to that company or is there third-party outsourcing?

• Dedicated developers, whether employees or dedicated subcontractors, have a track record with the company and presumably work well within the framework of that company’s development services. They are bound by the service model of the company you hire and should represent the values and ethics of that company well.
• Outsourcing refers to services that are rendered outside of the company hired to do the work. Outsourcing can be used to bring in someone with specialized technical eXpertise in an area the company lacks, or to provide staffing they don’t have. This is not necessarily bad and, when used well, can benefit the client, but understand that it can complicate a project depending on the lines of communication and availability. Some companies manage these arrangements well, while others feel a little hodge-podge.

Bringing in an outside developer for technical eXpertise can improve the final product by getting the right technology or eXtended services for a solution rather than the hired developer providing a subpar workaround. Some eXamples of technical outsourcing include branding/logo design, server configuration or even eXtension/plug-in development.

The most common image of outsourced development is offshore developers halfway around the world who work on the cheap, have limited availability during regular business hours and often suffer from a language and/or cultural barrier. That may be the first thing that comes to mind, but there are many sources for outsourcing to provide development staff. An outsourced developer could be an independent contractor, a discount developer (like through eLance or Upwork), offshore or a partner development company.

Outsourcing to provide development staff tends to be hit-or-miss, depending on how the developers are chosen and how incentivized they are to prioritize you as their client. The worst scenario is discovering after the fact that the development company does not actually have their own developers and operates simply as a middle-man. In this case, the client may be at a serious disadvantage especially if there isn’t direct access or communication with the developer(s). It is good to know the arrangement ahead of time so informed decisions can be made.

The important idea here is, Is the assigned developer(s) skilled in all of the required technologies for the project or is there a provision for what they may lack? It isn’t always possible to know all of the moving parts or required technologies of a larger development project, but what is known should be accounted for.

Communication

The lines of communication are fundamentally important to the success of any development project. Developers use different models, so it’s important to know what you’re getting into. As a client, you may have direct access to your developer, communicate through a project manager, or via a ticket system.

• Direct Access: With direct access you communicate directly with your developer(s) to collaborate on your project. There isn’t a middle-man who acts as a go-between, so delays in getting information back and forth should be minimized and understanding should be maximized.
• Project Manager: Many projects involve a project manager. Often, this person acts as an intermediary for all or most communication; however, this leaves open the opportunity for misunderstandings. When there is a project manager overseeing progress, you probably still want to have direct access to your developer so you can eXplain your vision directly and the developer can ask questions as necessary for clarification.
• Ticket System: Perhaps the least efficient method of communication is a ticket system. This is where the client enters all requests and questions through electronic messages in a formal structure. You have to be clear in your description of your request and hope the developer interprets it correctly because there generally won’t be much, if any, direct communication. It’s like playing the grade school game of telephone and hoping the message loops through intact. This is often used in larger development firms, companies who employ offshore developers and companies who don’t assign a specific developer to a project, but who assign tasks to developers on a first-come, first-served basis.

eXperience

How much eXperience does the developer have? Many people want the developer to have eXperience or background in their specific industry. In development terms that can be helpful, but is not a requirement. The developer will have to be educated in your specific business flow regardless of their familiarity with your industry, so this is usually a minor factor. Often, as you provide a broad summary of your goals and work flow, the developer may connect the concept to other projects that use similar processes even in completely different industries. From the developer perspective, the process is more important than the industry. The important question you want answered is how eXperienced are they in the processes and appropriate technologies for your project.

Certification

Is the developer certified and does that matter? Software development still has a little bit of a “Wild West” feel and many developers are self-taught. Certification lets you know they know their technology, but it doesn’t indicate their level of mastery or application of the technology. Certification may be a good first step in vetting a potential developer, but it is not the only consideration.

References

There are many people who market their ability as a developer, but it’s hard to tell if they are good at what they do. Beyond eXperience and certification, how do they perform as a developer? You are hiring someone and making a fair investment in them over time so consider it like hiring an employee and check their references. How were previous working relationships? Did they understand the business need? Did they deliver a quality product? Did they set appropriate time and budget eXpectations and revisit them as requirements evolved through the development cycle? Were they good communicators? All of these help you build a picture of the developer you are hiring.

Ownership

One thing people don’t often stop to consider is ownership of custom software. Who maintains ownership during the development process and who owns it (and has access to it) when it’s finished? In a work-for-hire arrangement, the client may or may not own the product during the development process and have full access to the guts of it when the project is finished. If it is a quoted contract, the developer usually owns the product until the last farthing is paid according to the contract. This means that if things go south during the development process and the relationship ends, the client has nothing to show for their investment.

Other times, the developer may maintain developer access even after the project is finished, which means you can access it as a user, but you cannot get into the guts if you want to make changes yourself or hire someone else to make modifications in the future. This is where a contract or service agreement is infinitely helpful in spelling out the details and removing any points of contention. The caution here is to know what you’re getting and when.

In addition to the agreement between the developer and client, there are other factors that may affect ownership depending on the technologies used to develop your app. These include, but are not limited to, the following:

• U.S. Copyright law
• State Work-For-Hire laws
• Intellectual property rights
• Licensed software End User License Agreement (EULA)
• Open source technologies licensing agreements (EULA, creative-commons [CC], general public license [GPL])

You will want to be fully informed about how these might affect your freedom to use and distribute your app in the future. Having this discussion on the front end will help alleviate any frustrations or disappointments on the back end related to the ownership of the solution you have paid for.

The discussion on ownership and when ownership transfers from the developer to the client leads to the all important question about pricing. Since this tends to be the central focus of who to hire and is often the primary consideration, it warrants a more in-depth discussion in order to provide some transparency about how different pricing models work and how to evaluate them. That will be covered in depth in Part 3.

If you missed Part 1, you can access it here: Embracing the Development Mind-Set

Read Part 3 of 7: Coming soon — Quotes, Estimates and Change Orders, Oh My!  —  Understanding Pricing & Billing Models

To read more about eXcelisys’ software design, development and consulting services, click here.