So you have an idea for some software, some spare cash, but you can’t program. “I know!” you think. “I will just pay someone to write me an app! What could go wrong???”. Well, lots. And there are a few things that you should look for when paying someone to build your great idea or next business differentiator that may help ensure that you end up with at least some chance of a good outcome.

  1. Contractual Stuff. There are a few things that you should look to build into a contract. Now, I am NOT a contract lawyer, so (disclaimer disclaimer disclaimer) you have been warned. But there are some things that you can use to address maintenance cost, which according to Robert Glass in “Frequently Forgotten Fundamental Facts about Software Engineering” is on average 60% of software costs. Yes, that is right. It is more costly to maintain your bespoke software than to build it initially.
    1. State an 80% Unit Test Coverage as part of the contract. This should provide a much more maintainable system for the original or any other vendor that attempts to maintain the code. This coverage statistic should be available from pretty much any CI server (explained below). If the vendor does not know what you are talking about, rule them out as a vendor. This will probably (or at least should) have additional cost implications, but the return of investment is measured in months, not years.
    2. Ensure a warranty period, generally 30 days or so. This provides you a remediation window when the software is initially implemented for use, which can be when a lot of initial defects associated with misunderstood requirements or bad coding surface.

  2. Waterfall or Agile. Know how they are going to deliver the software. This will change your input into the process, and their are pros and cons to both. This is a big, religious war type thing, but generally people favour Agile for modern software development. Read about both and get comfortable with which works for you. The two approaches can be summarised as:
    1. Waterfall: “Big Bang” delivery, lots of design up front, long lead time until you see the product.
    2. Agile: Iterative, piecemeal delivery of small features, design as you go, short lead time to see small incremental slices of the product.

  3. Source Control. You have to have it. Think “track changes” on a Microsoft Word document, but for code and on steroids. Often referred to as your “SCM”, “repository” or just your “repo”. Without this, you essentially wont be able to easily modify or rebuild the application you paid for. There are a lot of different flavours out there, but the most standard these days is Git (to push the analogy, think “Microsoft Word” rather than “LibreOffice”). You can host this internally, but in many ways it is much cheaper and simpler to host in the “cloud” (some of these I am not going to help you on!). As a quick example of current hosts:
    1. Github has private repository plans starting at $7/month. Generally considered the best hosting.
    2. BitBucket has free private repositories, which is pretty hard to beat.

  4. Continuous Integration (CI). Think of it as spell checking for your Word document. You wouldn’t publish with bad spelling with red underlining all over the page, right? Continuous Integration hooks up to your Source Control Repository and will attempt to build your application whenever it detects a change. It will generally run any tests that are stored with the code to ensure that those changes haven’t broken any functionality, and the results if successful will generally be the application itself, ready for deployment. Having this hooked up to your source control repository also guarantees that you have what you paid for (the code) as you can confirm that the code you can access builds the application you paid for. Again, a CI server can be hosted internally, however it is generally cheaper and easier to host in the cloud. A few good examples:
    1. Drone.io is pretty fantastic for a lot of reasons, but will not (currently) build Windows based applications. Starts at $25/month.
    2. Appveyor is the next best thing for the Windows folk out there. Starts at $19/month but is pretty restrictive at that price tier.

  5. Deployment Scripts. You should really know how your application is deployed. If it is on an internal server, this is still something that you want to understand, and have a repeatable process for. If it is in the cloud, then doubly so. Ensure that this is the only way your application is deployed, and ensure your vendor uses it every time. This way you can be sure you have a repeatable process that does not rely on the vendor’s knowledge of the application, something that is unlikely to be passed on to a new contractor coming in to a maintenance role.

  6. Passwords and Keys. This is particularly important if you are deploying to the cloud. You should own all the things that make your application function, and if your application is hosted by a third party, that means the information related to that hosting. There may be some gymnastics around this, such as ensuring that you provide an online hosting account up front to any vendor to ensure you are in control from the start.

Of course, even if you get the right answers from a vendor, how do you verify? This is where the idea of independent software certifiers would make so much sense. Helping companies validate third party software delivery is definitely something I can see as a growth industry in the future.

There are probably many more checks that could be added to this list, but collating an exhaustive list would probably exhaust me. This should cover off the biggest issues I have seen recently, and if everyone did just the things on this list it would make it a lot easier to come in and help most companies with software maintenance issues. If you can think of any glaring omissions, please feel free to comment below and I will update as required!