Custom Software Services is one aspect of the software business that is plagued by sleazy companies, some of which will go to almost any length to make a quick buck. This article aims to provide a set of red flags that businesses can use when evaluating such companies for their services.  Hopefully after reading you will be easily able to distinguish the shady companies from the rest.  I don’t think all custom software companies out there are this way, in fact I know that there are respectable craftsmen out there, doing great work for their customers.

Red flag #1 Fixed Bid

One might be thinking that a fixed bidding process is a great way to control costs on a software project.  This is exactly the nature of the fixed bid trap set by sleazy custom software companies, they lure you in thinking you’ll be getting your project delivered for less without worries of going over budget.  This is a fallacy, the only way to really control costs is to receive continuous delivery of valuable software.

The problem with fixed bidding is two fold.  On one end the temptation of the consulting company to under-estimate and under-bid is too great, and the temptation to then cut corners becomes too high.  The quality of your code and project will suffer, perhaps greatly.  The other problem is that these firms are very good at their core business (contract negotiation) they know how to write specification documents to be just vague enough that they can easily deem things to be change requests that most people would consider obvious.  At this point they now have you held hostage; you can back out and usually pay some retainer plus the cost of your project, or you can skip the change request and get less than what you wanted, but likely you’ll submit and pay more for the project than you originally thought.

A fixed bid project can only result in a few outcomes, in the first they compensate their under bidding with change requests and secondly they cut corners and drastically reduce quality to make the budget, but usually the result is a combination of the two. The reality is that in software you can only estimate small tasks with accuracy, estimating at the project level is always a roll of the dice.  Everyone’s understanding of the software requirements will change as the project progresses.  This is why true craftsmen would work with you in a customer-driven approach, delivering working software constantly so you can walk away whenever you feel you’ve achieved the value you wanted to obtain.

Red flag #2 Phony or Outdated Approaches and Methodologies

Their website might have talk of having methodologies but do they give concrete examples of them in action throughout their work?  More importantly, is the process or methodology they follow an accepted industry standard or do they just enjoy reinventing the wheel?  Perhaps they will reinvent the wheel when they go to implement your project. But more than likely it’s just fictional or simply high-level steps of their sales process.  Agile and customer-driven methods will be highly visible throughout the interactions with the reputable shop, these will be prevalent in the more competent and legitimate companies.

Red Flag #3 Outsourcing to Developing World Countries

In this case the shop becomes almost nothing more than just a middleman and you can almost guarantee they are using online freelance services.  This is not bad because developing world countries have worse programmers than here in the United States, quite the contrary.  Exceptional programmers are individuals that represent every nationality and ethnic background.  The problem is that these exceptional developing world programmers are not going to be the ones working on your project.  The ones who will be working your project will be of the lowest percentile in skills and ability.  This is because those exceptional programmers even in the developing world are going to have greater economic opportunity than working on a middleman’s outsourced project, in fact most of the highly skilled will have opportunities to work abroad in rich developed nations throughout the world.

One can almost guarantee that any work contracted out to a third party (regardless of destination country) will result in what is considered commodity programming, meaning that the code will be very poorly written and brittle and thus hard to maintain and sometimes almost impossible to extend or change without significant costs.  Yes, the quality of the code itself is of utmost importance, don’t let them try to tell you otherwise.  Unfortunately the sleaziest of custom software shops will avoid mentioning they perform these activities, in fact they might even flat out lie about it.  This is where you have to really do your homework and hit them with the hard questions, find out all you can about the size of their team and internal practices, a company that just farms out projects can’t hide every aspect of it.

Red Flag #4 Trumped-up Testimonials

Lots of testimonials and prior customers in a portfolio doesn’t necessarily insure that the company is not sleazy.  Beware of the shop that tries to sell itself based the reputations of it’s past customers, ask yourself why they are focusing on this so much when they should selling you on their expertise and abilities.  It’s amazing how some companies will greatly embellish, often using their friends who might work at a major corporation to write them a quick and positive testimonial.  Since anyone can simply ask one of their friends to write them a testimonial or a review, you should not even consider these testimonials when selecting the right company.

Red Flag #5 Lack of Quality Standards

A reputable shop should have a set of quality standards defined and they should be able to share these with you without any hesitation.  You want to make sure that they have standards for coding style, software design, and even content.  Their standards should also be right inline with industry standards of the related languages and technologies they plan to use. They should use test-driven development or at the very least write unit and functional tests concurrently with your project.  The result of your project should not only be the code but also the code the makes up the unit and functional tests, after all this is an important part of your software and you will need these for maintenance and implementing changes in the future.  There should even be some minimum Code Coverage metrics agreed on up front.

Conclusion

If you are shopping for custom software services please take this guide to heart, don’t let the charlatans try to convince you that any of the these red flags are acceptable practices.  Feel free to contact me or post any questions you might have about your experiences, I’d be more than happy to help you in selecting the right craftsmen for the job.