3 Important Trends to Innovate in Agriculture in 2024
App Design & Development
If you’ve ever experienced theft, you know that it leaves you feeling violated – aside from the actual loss and all the emotions that come with the territory, there can be greater consequences such as when a developer hijacks code for a project. Unlike hacking incidents where some unauthorized individual gains access to a system or its data, this refers to scenarios where a development team or individual developer withholds code when parting ways and won’t give it back.
It’s exactly like the all-too-common situation where you’re working on a jigsaw puzzle with a friend until an argument breaks out over Marvel and DC merger hypotheticals, causing them to stuff their pockets with as many pieces as they can grab before walking out the door. When this happens to your code, it puts you in a tight position as there’s much more on the line than just personal gratification. In the following, we’re going to explain developer hijacking and its implications then walk through some best practices for preventing such debacles.
What is developer hijacking and how can it impact business?
Developer hijacking refers to a specific scenario where a development agency – or sometimes, an internal team – retains code for a project for any number of reasons. It’s not completely unheard of for a business to find a fake operation or lone developer as scammers are everywhere but it’s a bit different when legitimate work is being done. It’s far more common for a business to hire a development team, have it go sideways, and have nothing to show except a trail of completed payments that lead to nowhere.
The issues that can arise from these situations vary in terms of severity, depending on how much usable source code is accessible. Going back to the puzzle analogy, sometimes this scenario parallels the picture above – there aren’t too many pieces to the project overall and it’s fairly easy to see what’s missing. But other times, there’s nothing to go on so the next team will need to start from scratch.
At Blue Label Labs, we sometimes take over projects started by other teams where this has been a setback. Ideally, we’re able to pick up where they left off but there are several variables. Until we’re provided with the actual source code, we’re unable to see exactly what’s missing. Further, there’s the matter of how well the program was written and if there was any attempt to sabotage the code.
When there’s nothing to work with, we’re forced to start from scratch. Too, if enough of the code was ruined, you can run into a problem where it’s not economical to fix which also means a restart is necessary. Unless you’ve had a second agency or internal person reviewing code as it’s completed (which is unlikely), you could be sitting on bad code but believe that the project is near completion.
The gist of what we’re saying is that sometimes these breakups are mutual and easy while other times they’re like the culmination of a bad romance where clothes are shredded, guitar amps are kicked in, and they won’t give the dog back.
7 tips to preventing developer hijacking
Not every fallout is preventable so it’s a good idea to lay some groundwork to prevent consequences from getting out of hand. By doing the following, you’ll be in good shape should some discord shatter your relationship with your developers.
1. Ensure that all intellectual property (IP) will be yours
If you’re putting together something truly innovative, make sure to file for patents, copyrights, and anything else you might need as well as keep all documentation. One less-effective way you can address this is to have developers sign an NDA to help prevent them from disclosing the inner workings of any protected information you share with them or portions of any proprietary systems they develop for you. Keep in mind, this isn’t an end-all solution in the event of a fallout but it does give you a functional tool to take down any piece of software that contains your IP as well as a leg to stand on in court when seeking reimbursement for damages.
More importantly, the Statement of Work and Developer Agreement that all parties sign should state that you are the sole owner of the project’s IP. Steer clear of any agency that contracts themselves as the owner of IP which they “license” to you.
2. Ensure all source code lives in repositories you control
Developers will often limit your access to code simply to prevent anything from being altered or deleted so don’t worry too much if you’re set to “read-only” by default. Make sure can access your entire repository in GitHub or Bitbucket and that developers are making regular contributions. Both these platforms both offer versioning and track changes but you could further manually backup code as well. Though manual backups might be overkill, exploring the repositories would at least reveal that you’re getting some semblance of code and not some copypaste of Les Miserables.
3. Use your own developer account for the app stores
If this is your first app, you’ll need to make a developer account that isn’t tethered to anything else to publish your app. Doing so gives you control of your app and makes it harder for developers to lash out if something goes haywire. Understand that it might be in your best interest to allow them to first publish an app using their account then transfer it later using transfer tools for either (or both) Apple and Google. Too, make sure that you have admin access to certificates as well.
Make sure that developers give you access to the Android Keystore by providing the necessary credentials. Currently, Without access to the Keystore file, you won’t be able to submit updates to the app. While this system is expected to go the wayside with the introduction of a new key management system, many projects still use this method.
4. Keep a secure list of all your accounts
Just like your passwords for everything else, keep lists of accounts stored in a secure place. It’s also a good idea to make sure that you sign up for any third-party services under an email that belongs to you to prevent getting locked out of the service in the event of a developer hijacking kerfluffle. You should also store the credentials for things like your hosting provider, databases residing behind your app, your APIs, and anything else associated with the project – ideally, set up 2FA or MFA wherever possible, including your domain registrar. It’s best that all hosting and databases are setup under accounts that you own and control.
5. Setup AWS or Azure hosting the right way
Many times, developers use setups under their own accounts for infrastructure but keep in mind that it’s in your best interest for them to do it under an account you control. Further, there are additional security mechanisms in place like PEM keys you may need to access virtual machines, specifically AWS EC2 instances. As such, make sure that these files come into your possession after new VMs are created.
6. Find someone to do an audit before passing a project on to a new team
If things do happen to go sour, don’t leave yourself open for a second disaster. Before entering any kind of deal with a new team, it’s important to know what you already have to pass on. For example, you could run into a circumstance where you’re 90% of the way to an MVP but the next company claims you’re only halfway there. It’s uncommon but it can happen – this is why we attempt to breakdown everything we learn from a code review when taking on a new project to show our customers exactly where they’re at.
7. Don’t be a dick
Having reasonable expectations is perfectly acceptable but flipping out over little issues is a recipe for disaster. All kinds of issues arise during development from minor bugs to complex issues that don’t surface until developers are in the fray which may take extra time to resolve. Remember the scene from the 2005 film, The Waiting, with the rude customer? If you go so far as to be abusive, remember that actions can have consequences. It’s one thing when developers constantly miss their mark with no viable excuse but it’s important to understand that problems can and will arise. So please, be nice!
Blue Label Labs won’t thug your program
Normally, we wrap our content up with riveting call-to-actions but today we’re just going to say “be careful” one last time. As if making a big move by investing in an app doesn’t induce enough anxiety, developer hijacking is something that does happen. Most agencies would never risk their reputation by committing such an act but there’s always a chance. If you decide to work with us, feel free to hold us to anything we mentioned here and enjoy some peace of mind. We hold ourselves to the highest ethical standards to ensure that any team who takes over a project after us is set up for success as sometimes even we get fired.
