Ship First, Build Second
Why you should make software delivery your first priority
When you begin working on a new project, it’s incredibly tempting to ‘start at the beginning’. You have some vision for how the user should interact with the software, so you start building whatever the user would first see, and continue from there.
Alternatively, you might start working on core features, before building the supporting framework around it.
In many cases, these choices are perfectly reasonable. There aren’t many rock-solid rules about the order in which you should build your software’s features, but it’s often the case that deployment is only considered at the tail-end of a development cycle (or, in the worst case, at the end of the project!). This short post explains why you might want to reconsider that, and tackle deployment first, rather than last.
Embrace The Pain
For any moderately complex piece of software in today’s technological landscape, it’s almost a certainty that you’ll be relying on third-party SDKs, libraries or services, hosting something on a cloud server, publishing builds to app stores, or targeting some platform you may not fully control.
As an illustrative example, let’s say you’re making a game. If you ever want anybody to play your game, then you’ll probably be publishing it via a distribution service, such as Steam, Google’s Play Store, or maybe Apple’s App Store.
Steam serves Windows, Mac, and Linux, the Play Store serves Android, whilst the App Store serves Mac and iOS devices. Alongside the obvious runtime platform differences, as a developer, you also need to consider the specific packaging and publishing requirements of each of those distribution services. With mobile platforms in particular, you may expect fairly stringent automated checks on builds you upload:
Your application is scanned to ensure it meets packaging constraints.
Automated checks are run to ensure your app doesn’t contain malware.
Your package is analysed to ensure it doesn’t depend on obsolete APIs or libraries with known vulnerabilities.
The worst time to discover that you’re failing any of these checks is at the end of a project, when replacing outdated APIs and upgrading vulnerable libraries might force significant changes in your codebase.
A slightly-less-bad time to discover that you’ve got problems is immediately before you show somebody important - usually the person holding the cash - the fruits of your labour. Even if you’re not yet releasing the finished product, an eve-of-delivery panic caused by deployment issues will never inspire confidence, and in some cases, resolving these issues can cause a significant delay.
Even without the kinds of checks that distribution platforms may run, your software may still fall foul of any number of issues as soon as it hits a server, or a user’s machine, and it’s all but impossible to avoid these risks entirely. Getting visibility into these potential problems is critical to a successful launch, and the earlier you’re able to identify these issues, the earlier they can be addressed.
Embracing the pain early on allows you to get ahead of any looming deployment issues, and leave yourself plenty of time to investigate and rectify any risks before they become serious problems.
Build The Guardrails
The best way to mitigate the risks related to deploying or distributing your software is to set up your delivery pipeline as early as possible.
As soon as your app can be built successfully - even if it doesn’t do anything yet - you’ll never regret taking the time to ensure that it can be deployed or distributed without any problems.
By prioritisiing deployability, you will start receiving feedback from automated systems as early as possible, giving you an early warning when APIs / SDKs are deprecated, or when a vulnerability is discovered in some dependency you’re using.
You’ll also improve testability - ensuring that it’s trivial to access your software from test environments, allowing your QA team to start verifying builds as early in the development process as possible.
From a commercial perspective - having builds available from Day 1 is also a great way to inspire confidence in your capabilities and foresight, and the pressure around milestones and delivery deadlines is greatly reduced.
Whether you’re a solo developer, an indie game studio, or a development team in any sector, the end goal is always to deploy - so prioritising that requirement and ensuring it’s ready to go early in development helps ensure that you’re always working within the guardrails.
With modern tools, it’s never been easier to automate the building, testing, and deployment of your software - so integrating a reliable, repeatable deployment process into your automated systems is usually a matter of writing a few scripts, or setting up some configuration files and running a tool, such as fastlane for iOS and Android apps. Tools such as GitLab Pipelines, Jenkins, and others provide versatile and straightforward mechanisms to run automated processes against your codebase, making it trivial to get things up and running as quickly as possible.
Turning automated checks and deployment processes to your advantage early on is a smart way to avoid serious problems when you least want them. The sooner you’re able to prove to your team and your stakeholders that you can deploy your software safely, reliably, and regularly, the sooner you can get on with the real development work, with confidence, and get paid on time every time!