I get to talk to a lot of people about what we do at Test Double and I’m constantly amazed by the number of interesting and unique challenges that face businesses from different industries. It seems like there should be off the-shelf solutions for most of what people need after 40 or so years of commercial software sales, but existing solutions often don’t have the required features, they raise support concerns, or they require extensive customization to meet the needs of the business. Companies then turn to agencies like ours, for a custom software solution.

Unfortunately, many companies use the same mindset for purchasing services that they would when buying packaged software (or pencils or staplers or other commodity products). This mindset can create a number of headaches for both buyer and seller; leading to a defensive relationship between the the two and resulting in custom software that's still a poor match for their needs.

Most businesses that we talk to are either at a loss with how to select a partner for their custom software needs, or still deeply rooted in the procurement processes of other industries. Further, they go years between major custom software initiatives, so few will have learned through experience how to build a successful partnership with a software services company. Meanwhile, as an agency, we're a part of this process dozens of times a year, albeit from the other side of the table. Here are a few of the pitfalls we see buyers run into and some of the advice we frequently give prospective clients to avoid them:

Forcing a delivery date

Clients who are purchasing commodity products or services can typically get a fairly narrow range of estimates for time and cost. It makes sense when building a house, painting a room, or manufacturing a widget that you can accurately predict when you will be done. It has been done many times before and the steps to completion are very well known. Unfortunately, custom software development is not well known. If the problem a customer is trying to solve is already well understood, then the chances are that they can find something off-the-shelf or with open source that will do exactly what they want. They won’t need a firm like ours in that case. Assuming that what they need actually is unique, then it is difficult at best for us to forecast when exactly we’ll be done. The very uniqueness of the problem that drives clients to buying our services in the first place is the same thing that limits our ability to tell clients explicitly when we’ll be done. Instead, we try to guide our clients to focus on minimizing scope, reducing complexity, and eliminating risk throughout the process. Doing these things and openly sharing information about our progress and the remaining work allows us to narrow in on a delivery date and communicate that to our clients consistently from the start of the project.

Fixing scope

Most companies start custom software projects with the wrong question. They ask first, “What things might we want this software to accomplish?”. Many people may see no issue with this question, but the devil is in the ambiguity.

When we ask our business stakeholders and end users what all of the possible things are that this software can do, we get a response that is much more swiss army knife than a screw driver. And when we don’t refine the scope from all possibilities down to must have essentials, we typically produce software that is expensive, difficult to maintain, and very hard to use. (See Sharepoint if you want a good example.) Brainstorming about possible features with end users is a valuable activity, but assuming that all of the features discussed on day 1 are essential is a recipe for disaster.

At Test Double we collaborate with our customers to distill long lists of desired features down to a subset of critical features that constitute a minimum viable product. Many times this may simply take the form of categorizing the features down into critical, nice to have, and extraneous buckets. Once a portion of critical features are built, our team will release the software to production and begin relentlessly soliciting user feedback to determine the next steps for the software. Gathering end user feedback early and often can frequently drive a custom development effort towards a solution that better meets the needs of it’s end users. What businesses often think is most valuable can vary sometimes greatly from their end users impression, implement a process to leverage their feedback and use it to shape the end product.

Thinking only of today

Many clients tend to think that getting software into production is the finish line. Unfortunately, up to 80% of the cost of software development occurs beyond initial release. Many companies start to see defects, longer turnaround time on new features, and scalability concerns shortly after pushing a project into production and labeling it as “done".

Over time, companies begin to view these issues and their corresponding costs as irreparable so they undertake massive rewrites of applications that have been deemed “legacy” after only a few years. If software service consumers want to focus on reducing the cost of software delivery, wouldn’t they be better served by eliminating legacy rewrites and reducing the overall maintenance cost instead of focusing on the bill rate of the developers writing version one?

The challenge to customers is that it's difficult to evaluate how maintainable one software company's work will be versus another's. It's easy to compare potential partners by bill rate, however, so buyers tend to put undue emphasis on up-front cost comparisons. Test Double, meanwhile, is relentlessly committed to writing software carefully and deliberately enough to be easy to grow and maintain over the long term. That makes us a harder sell until buyers have come to appreciate (and often, unfortunately, the hard way) that fast and cheap solutions can quickly become money pits to maintain. Just because it is easy to compare build costs, does not mean that it’s in the best interests of the business.

We have seen businesses struggle under the maintenance efforts of relatively new software, and we have found that applying a focus on simple solutions surrounded by automated tests can drastically reduce the maintenance costs of our customers. This effort takes time in the near term but results in an end solution that is generally better able to withstand the future needs of end users.

Finally, we spend ample time to ensure our clients have a plan for operating and maintaining the software we deliver. We love working closely with our clients' engineers, and we're happy to facilitate smooth maintenance transitions by welcoming client developers into the fold, pair-programming with them and training them to carry the torch after we're gone. Finding a vendor with a focus on planning these transitions and with the skill to teach others how to maintain their code is key to ensuring a viable long term solution.

Purchasing based on cost

When purchasing pencils, then it may make sense to base that purchase on the lowest cost per pencil. Pencils are, after all, fairly similar in regards to quality, efficiency, ease of use, and general value for the dollar. Software developers, however, are not. When procuring custom software development services, you are in essence buying software developers which vary wildly in quality, efficiency, ease of use, and general value for the dollar.

Evaluating the level of developers is hard, even for us and we spend a lot of time doing it.

People have touted and disputed the "10x developer", but our experience shows that developers vary wildly in skill, communication, creativity, drive, and professionalism.

We have found that truly exceptional developers we’ve worked with know:

  • When to challenge product owners on the features being discussed and when to evaluate alternative solutions to problems that aren’t being discussed.
  • When to absorb the cost of adopting a new technology in order to reduce the overall cost of the projects and when to avoid implementing a new and shiny technology which will add little value to the project.
  • When to spend the extra time refactoring a solution that future developers can easily maintain the overall solution, and when to defer these refactoring until more is known about how the solution may change in the future.

Comparing custom software consultancies on cost is easy, identifying the developers who excel at balancing the trade-offs above is really hard. We encourage all of our clients to spend the time talking to our team so that they have a level of trust that we are the best firm for their problem. Further we’d love if they talked to current and past clients about what it is like working with us on a day to day basis so that they understand that our cost may be higher but so is our value.

Conclusion

Procuring custom software development is a challenging process and one that shouldn’t be undertaken blindly using an RFP or other disconnected, commodity based process. Hopefully companies realize that many of the mistakes discussed above can be avoided by investing some time with custom software agencies to establish trust and a greater understanding of how they work.

[DISCLAIMER: If you find yourself in need of custom software, we'd of course appreciate the opportunity to talk to you about it. Even if it's clear that Test Double isn't the best fit for you, our broad network enables us to confidently refer dozens of prospects each year to the developers that are right for them.]

If you enjoy this post, let us know by twitter or e-mail! If you'd like to discuss it, open an issue on our feedback repo!