When you decide to build a custom program, it can be a liberating feeling. You have complete control over everything – at least, as long as you have a good relationship with your programmers. If your relationship sours, however, it can start to feel like a hostage negotiation.
It’s not always your fault
We can all hope to have a great relationship with the programmers we work with, and most of the time this is the case. But there are situations where things can fall apart, sometimes because of matters out of your control. Maybe the relationship starts off well, but the development team become significantly busier and they can’t meet your deadlines. Maybe their rates go up to a point where you cannot afford them anymore. Or maybe the consultancy goes bankrupt or gets aquired.
So what can you do to avoid this trap?
Be generic
There are many ways to write a program, but they all start with picking a programming language and framework. The language is how programmers talk to the computer, and the framework is the set of pre-built tools that allow them to make complex programs without starting from scratch (think table saw vs. hand saw).
Any decent programmer will have a lot to say about programming languages and frameworks, and for the most part it’s a good idea to nod your head and agree with their preferences; telling a programmer what tools to use is a great way to start the relationship on the wrong foot. However, there are a couple of things to watch out for.
In most cases, it’s a good idea to work with a language that is mature and widely used. You’ve probably heard of many of these languages – Python, Ruby, Javascript, C#. These languages all have huge numbers of skilled programmers and mature frameworks that make it easy to build standardized code.
You may sometimes be recommended a more up-and-coming programming language, such as Go, Erlang, or Rust. These languages all have their benefits, but unless your program could really benefit from them it’s best to avoid going this path; you will find that it will be harder to find skilled programmers who specialize in these languages, and the frameworks you would have to use will be less mature and will change more frequently. You should also try to steer clear of programming languages that are getting long in the tooth (ASP, Perl, .NET 4), although it’s less likely you will bump into programmers eager to use these.
Even more important than the programming language is the framework your program will be built on. A good framework should be quite opinionated with how programs are built. This makes it easier for a new programmer who is taking over a project to familiarize themselves with how everything works. Frameworks like Django, Ruby on Rails, Laravel, .NET Core, and React are quite mature and have a pretty standard way of building things.
Up-and-coming frameworks are always exciting to programmers because they are designed to work better with new technology or solve a limitation with a mature framework. What is most exiting for a programmer isn’t always best for the client, however. Frameworks need to go through a lot of trial and error and development before they develop a standardized approach to development, and during this trial-and-error phase you are far more likely to require refactoring or a longer onboarding process for new programmers. Examples of (excellent, but young) up-and-coming frameworks are Vue, Riot, and Polymer.
Compartmentalize
The less complex your application, the easier it is for another developer to step in and maintain it. Simplifying your program may feel impossible, but it’s likely there are ways you can simplify your concept or break it into smaller programs.
It’s now possible to build multiple small programs that look and feel like one larger application. Applications can easily share a common UI thanks to new design frameworks like Bootstrap and Tailwind, allowing for a common ‘feel’ while jumping between programs. Your programs can talk to each other behind the scenes using APIs, allowing for multiple separate programs to act as one. And you can use a Single-Sign-On implementation to make sure that each of your programs can seamlessly authenticate each user, without requiring them to log in again every time they switch to another program.
Compartmentalization does come with some tradeoffs that should be considered, however. Developing a series of separate programs that work seamlessly together does take a little more time compared to building a single monolithic program. When building a system this way, it’s extra important to plan ahead to make sure you compartmentalize all of your requirements in a smart way so you do not end up with a huge cluster of individual programs. And running a series of programs can – if done badly – cost more to maintain than a single monolithic program. In most cases, however, these pitfalls can be avoided or minimized.
Build with “no-code” tools
Compartmentalization is even more powerful when you start to take advantage of the new batch of no-code tools such as Webform. These new tools allow non-technical people to build programs using drag-and-drop interfaces, and they can be combined together to build powerful systems.
There is one big drawback when building with no-code tools, however. When you determine what your program needs to do, chances are you are designing a system in which you have complete control. And when you have to implement using a bunch of tools that you have less control over, it’s very unlikely that what you have in your head will translate perfectly. But there is probably a way to do what you want to do in a slightly different – but just as effective – way if you are willing to give up some control and work with the capabilities of these tools.
Avoiding a hostage situation
With the right approach, it is quite possible to build complex applications with a consultancy without finding yourself bound to them for eternity. By building on top of mature programming languages and frameworks, compartmentalizing your needs into multiple programs, and embrancing no-code tools wherever possible, you can build complex programs that can be easily passed on to a new development team or even scaled up to multiple teams at once.
