5 Things You Should Always Get From A Developer

Dirty KeyboardYou know your business. You have knowledge specific to your industry. If you are like me, there are lots of times you see customers, or potential customers making the wrong choices when selecting someone to do what you do. You can’t really blame them, because they don’t know what you know. If a friend were going to buy your product or service, what advice would you give them to make sure they got the right person? (Assuming they had to buy from someone else).

Well friend, this is what I tell my friends if they want software created. These are the things an experienced developer knows make a big difference to your outcome, but are often glossed over or missed.

When you hire someone or some company, to develop software for you you have a lot on your mind. Can they do the work? Will they deliver on time? Will they deliver at all? Will they do what I want? How much will it cost?

Those are all valid things, and I’m going to talk about them in future blog posts, but first let me tell you 5 things always I want from anyone I hire to develop software for me.

Most of these things aren’t that critical when things are going well. But when disaster strikes – like the guy you’ve got writing your mission critical application get hit by a bus – these are the things that are going to make a big difference.

These things seem kind of technical and they are. You may not even understand what they mean, and that’s OK. Any developer will understand them – if they don’t you’ve got another problem. But if you have to replace your developer, for whatever reason, you can hand this information to the new guy, and he’ll be up and running in record time.

At Reactuate Software we call these things Provisions. If a requirement is what a client asks for, a provision is what we insist on giving them.

The Reactuate Software Provisions.provisions_cw

1. Access to the source code. When you hire someone to create a program for you, what you are paying for is source code. Yes deliverables will include a public release ready compiled binary/application, but unless you are never going to make any changes to that app, you need the source. You need access to that source at any time, and the best way to do that is via a source control repository.

2. Source code should be in a online, off site repository. A source code repository is a special program that keeps track of programming code and the changes made to it. A programmer can have a repository on their own machine. They can have one on a server in their office, and they can have one somewhere in the cloud. The cloud solution is what you want. This keeps the source safe not only if they get hit by a bus, but also if their office burns down. This repository should be secure and private. You the client should be able to access that repository easily and at any time. The Developer should be updating the source regularly.

3. Issue tracking. The developer should provide a bug/feature/enhancement tracking database. Bug tracking can be a challenge for any developer. Every bug report needs to be in writing, and should include steps to reproduce. Many small projects just use email for this, but that doesn’t make it easy to track the status of issues and make sure everything is handled before a release. There are many solutions that provide a web based system for doing this and most are connected to source repositories. You’ll have to decided how public you want this to be. You might want for users to be able to report bugs, or only your customer service people. Either way they should be tracked.

4. Always have a Ready to Release build of the application. Once you’ve reached version 1.0, there should always be a ready to go version of the app available. Normally this will be the master branch in the source control system. As bugs are fixed, in their own branch, they can be tested and pushed into the master. Then the master can be built and be ready to release with new bug fixes. This allows you the client to put out regular updates to your app at just about any time.

For web applications, they master branch may be the release. Any time a commit is made to the master, your web server can be updated and changes made live. This allows for the shortest time between the coding and getting it in front of users.

5. Clearly defined deliverables and processes. You should know from the beginning what your Developer is going to give you in the end. What do you need to call the project done? You also need to define how these things will be delivered. For instance, if you are receiving an iOS app, who is submitting it to iTunes Connect? Who’s responsible to provisioning?

Hopefully that will help you with your next project. If you are looking for a software developer that does all these things by default you can contact us here at Reactuate Software.

Leave a Reply

Your email address will not be published.