Mistakes of Custom Software Development.
I’ve been doing custom software development for many years and seen many of the mistakes a client can make either before or after they’ve hired a software development company. I’ve also acted as consultant for a number of leading law firms trying to unravel projects that have gone wrong. My hope is that maybe you’ll read this and not commit one or other of the following mistakes.
Mistake #1: Hiring Based on Price Alone
There’s a reason this is the first mistake. It’s committed more than all the other mistakes combined. People have a tendency to think that all developers are the same, so cost should be the major determinant in who they hire. It’s a big mistake, and unfortunately I’ve seen some people make this mistake more than once.
In reality, hiring the wrong company starts a viscious cycle. When you hire the wrong company you enevitably make other mistakes such as paying too much in advance, not having complete functional specifications or setting unrealistic milestones. And once you’ve paid out enough money you are caught between a rock and a hard place. Do you keep going to save the money you have already spent or cut your losses and walk away and start again? Either way it’s a waste of time and resources.
So can you avoid this? First, past performance is a good indication of future performace. Rate the companies you are considering based on factors other than cost alone. Check references, review similar projects and ensure your functional requirements are well defined. These are obvious items but here are some you may not have thought of:
- Ask them how you are going to monitor the progress of the project. Make sure they don’t just add this as a functional requirment and add it to the cost of the project!
- Ask them if they use Subversion, GIT or any similar repository? All experienced developers know what this is.
- Ask them about Continuous Integration, and which tool they use to manage their builds.
- Verify the exact coding standards they use when documenting your code.
These are not iron clad questions, but I have interviewed many developers over the years and I am shocked how many get all four of these wrong.
Mistake #2: Don’t Pay Too Much In Advance
If you committed mistake #1, I can just about guarantee you’ve committed this one too. Understand that I am not just talking about the initial deposit or advance.
You don’t want to pay too much more than the work that has actually been done – just like building a house. If you do, the developer is stuck with a lot of work and no future revenue to offset this cost. What about the money you already paid them? It’s gone. It was used to finish another project before yours that also turned into a disaster.
Structure your payment schedule around deliverables, or milestones. Basically pay for the next part of the project on completion of the current part. Pay on deliverables or results. Keep in mind that it is critical that you understand how much of the project will be complete, and then make sure the payments you make roughly represent the percentage of the project complete to that point. This also means you need to understand what work is being done and monitor progress carefully. Why do you think costs for projects balloon out by massive amounts- people just keep paying having no idea at what stage the project is at.
Mistake #3: Not Getting a Non Disclosure Agreement
How do you feel about the software you’ve paid to develop being shipped out the back door as a product of the developer? Suddenly they are experts in something you have designed and it’s a product they now sell to your competitors. If you have a good idea, and your product becomes a huge success, the last thing you want is find yourself in a dispute with the developer. It is critical that you have the company you hire sign a Non Disclosure Agreement and also and agreement to assign all rights to the software to you. In fact, you should have this NDA in hand before you even start discussing your project with any company. We give one to every prospective client.
#4: Not Owning the Source Code
You are hiring a company to write a lot of code. This code represents the product you are buying. You need to make sure that the agreement you sign grants you sole ownership of this code. Otherwise you’ve just paid your competitor to steal your idea. You need to own the code not the developer who in the absence of an agreement to the contrary will own it. If you don’t own the code you have no rights to it including developing it further with another developer. You need to own it. Period. Get this in writing.
#5: Undocumented Source Code
This has to be one of the most common mistakes. Imagine this. You pay a company to write thousands of lines of code. When they are done the program works fine. You call the company back to get some changes done, only to find out they no longer exists. Fortunately you have the source code so you confidently search for someone else to continue development. And then you get the bad news. The source code has absolutely no comments or explanations describing what the code does or why it was written the way it was. This is a huge issue in our industry. In 9 out of 10 cases, the new developer is going to tell you it is easier to start over again and in most cases that would probably be good advice. Well documented code is as good as a design specification and even recoding from well documented code is a benefit.
We have a simple way to avoid this issue. We perform code reviews on a regular basis to verify that our coding standards (which include commenting source code) are being followed by all members of our team. Our internal audits are designed to make sure this situation does not happen.
#6: Not Asking for Documentation
You are paying good money for your software project. You owe it to yourself to get all the documentation the software company created during the life cycle of your project. Why is this important? Imagine for a minute that the company you hired goes out of business a year or two down the road. What do you think of the chance of ever getting documentation? We provide clients with functional specifications, business requirements, test cases, data dictionaries, and a host of other project artifacts. At least now you have a good chance of finding another company to help you support and enhance your product. It is often more important to know why something was done a particular way than to know how it was done.
#7: Not Doing External Audits
If you really want to cover yourself, you should hire another company to review the code your developer is building. This has several benefits. First, there’s nothing like an external audit to make sure your programmers have double checked and fixed their sloppy code. The company you hire to do the audit also wants to give you value, so they are more than likely going to find some issues. This doesn’t mean your programmers are bad. Everyone misses something every once in a while. But by letting the company you hire know from day one that an external audit will occur at some point, you are already putting everyone on notice. We’ve been on both ends of this, and the client always came out the winner for it.
So there you have it. Seven mistakes you can avoid if you want your software project to have a good chance of success. Good luck!
