Software is a unique type of product, and for those who have never tried to create a custom application before, the process isn’t always clear. But when you’re starting an engagement with a development partner, it’s important to understand how an excellent application is born.
So what does it really take to build custom software? How can you prepare yourself and prevent some of the most common mistakes?
Continuous refinement
Arguably, the most important thing to understand about the software development process is that it’s iterative: you and your development team will wash, rinse, and repeat over and over again, re-adjusting and tweaking the application’s development track, toward your end result, which is usually termed the alpha candidate.
From there, you’ll work out the kinks, do a heavy round and QA and refine a final release, called a beta candidate. The beta candidate is usually the version of the application you’ll launch to your users, but it by no means is the definitive version of the application. At this stage, you’ll be able to take advantage of the new capabilities your app affords – but the software likely won’t be final: you’ll probably update it on an ongoing basis to address user feedback, add new features and fix undiscovered, edge-case bugs. One of the great advantages of custom software is that it helps you identify opportunities for new capabilities and then evolve to take advantage of them. A piece of software is never a static or “done” thing; software is a dynamic and ever-evolving entity.
Generally, the steps of each iterative cycle of software development boil down to:
- Gathering and refining requirements
- Implementation
- Testing
- Release
- Feedback
- Rolling feedback into the next iteration
It’s common for clients to start a project with really big ideas. But with software, big ideas really can, and should, start small. I often recommend that clients start out by creating the smallest version of a project that’s going to be valuable. You can always add more functionality and features later. The development process is highly involved for clients; you’re going to be making lots of decisions, many more than you expect.
Starting small
By starting with the smallest kernel of your vision, you can see how the process works, get a feel for what is realistic, gather vital end-user feedback and then pursue larger goals accordingly. (And, ultimately, it’s cheaper to undertake a project this way and not just because the scope of the project is smaller. Nothing is more expensive than a feature no one uses or doesn’t like.) It’s easy to want everything, but building software is highly collaborative, and your project will take a lot of work. For the best results, it’s important for all relevant parties to understand this at the outset. I like to tell my new clients that software development is a marathon, not a sprint; pace yourself, take care of yourself and let your managers know the level of effort required to successfully usher a new application into being. It’s unreasonable to expect, especially on medium-to-large sized projects, that you can just work your collaboration into your daily responsibilities.
For many clients, building an app starts to feel like a part-time job. That’s normal — and at some point, you’re probably going to be tired of the process. That’s normal, too. Software development is a creative process, and like any creative process it will be frustrating at times. You want to have a development partner for whom this process, and its hazards, are second-nature. A good partner will anticipate problems and address them effectively. A good development partner has your back.
Collaborative creation
Indeed, it’s useful to take a step back and consider what you’re doing when you build a custom application. You’re collaborating toward something that has never existed before.
This kind of highly involved, highly collaborative creation means that both partners have responsibilities that can determine success. Chief among these responsibilities is transparency in communication. If you’re not happy with how a project is proceeding, let your vendor know. For them, this is a datapoint. If you find yourself up against internal pressures, let your developer know – many times they can work with you to ensure all stakeholders are happy. If you don’t understand the business ramifications of a technical implementation or need more information, let your development partner know – it’s important that you feel empowered to make good business decisions about your application.
When both client and vendor are informed, it’s easier to navigate a project effectively. When you want to build something transformative, peership is crucial. Communicate well, start small, and you’ll be able to iterate toward even the most creative visions.
