We live in a world overflowing with possibilities. We are inundated with potential options for everything we want to do. This includes development platforms when building a new application. It doesn’t matter if you’re building a mobile, desktop, or web application, you are provided with numerous different frameworks and technologies on which to write your code.
Perhaps one of the most important decisions you can make when developing your app is the platform you are going to build on. Once you choose it and begin development, you’re stuck with it. Sure, you can refactor the solution after you implement it, but it’s simply that: a refactor. Changing the platform would require a rebuild. Therefore, we need to take all of our options into account to make sure we choose the right platform the first time.
Software development is a process. Deciding on the platform has its place in the process, but you must first decide what it is you’re going to build. Make sure you understand the problem you are facing and have an idea of how you want to solve it.
A helpful technique I learned from some folks at AWS to coax out important details and design decisions is a product design meeting called a Working Backwards session. A Working Backwards session will make sure stakeholders from different parts of your organization are aligned with the vision and elicits feedback necessary to build a well-rounded product idea.
Your vision doesn’t have to be complete before you move on to the next step, but it does have to be accepted by the stakeholders. Don’t spend time getting ahead if you haven’t received approval on your idea. Making your intentions clear is the most important part of your product vision.
Now that you have a clear vision of the problem you are trying to solve and how you want to solve it, determining the high-level architecture is your next step. What patterns best fit the problem? At what scale do you need the app to perform? Do you want an on-prem installable app or an app in the cloud? Do you want to take advantage of managed services or write your own?
These are just a few of the many questions that drive the proposed architecture of a new product. Don’t get caught up trying to get too specific. Your goal is to decide on architectural patterns. The programming languages you are going to use don’t matter at this point. Remember, these are your steps to choose the platform you are going to build on.
With so many options out there for platforms, how do you decide which to build on? It is important to consider the estimated time to market and the size of the team building your app. Are you working on a tight deadline? Do you need something that is rock solid on day 1? Here are some options I’ve run across when building new applications from the ground up.
Select a few of the options at your disposal and try to prove out your architecture with a Rapid Prototype. A Rapid Prototype is a high fidelity, functional proof of concept designed and developed in a single sprint. It is intended to provide a rich user experience and portray an idea to solicit feedback.
Building a Rapid Prototype in each potential platform will help you directly compare the platforms against each other. It will also give you a chance to learn about the architecture as you implement it multiple times. Each iteration should lead to a clearer understanding of how it works and the best practices around the patterns you chose.
To build a consistent Rapid Prototype, you need to decide on the proof of concept criteria that are most important to you and your stakeholders. Focus on your gamechanger. What can you build that will portray your idea the best? In the past, I have worked on teams who made light product specification documents and built the prototype as close to the spec as possible. This guaranteed the team was building the same product for each platform being assessed.
An important part to remember when proving out the platforms is to give each of them an equal chance. If you’re like many software engineers today, you might turn your nose up at a low code platform because it “isn’t coding.” Even if you don’t fully agree with the premise, give it a fair chance and you might be surprised with the results. Remember, your job is to solve problems, not just to write code.
Seeing the software generated by each platform side by side is one thing, but coming up with a definitive winner can be a challenge. So many factors come into play when deciding on the platform, from cost to developer experience to supportability, the software you see in front of you is just the tip of the iceberg. Come up with a grading scheme to be objective and get a decisive answer.
When comparing platforms, I break my assessment into 8 categories:
Assign a letter grade to each one of the categories and give the platform an overall rating based on the categories. Give each of the categories an appropriate weight based on your company’s needs.
You’ve seen what each of the platforms can do first hand. You have learned about the architecture you want to implement and have the first-hand experience with each platform on how to implement it. You have come up with an objective grading scheme to assign a letter grade to each one. It’s time to make the call.
Don’t argue with the results. If a platform you didn’t want to win has the best score, it’s the best option for the company. Nobody likes change and we don’t want to use something that we are unfamiliar with, but the good thing is that people are adaptable. They might fight you for a bit, but strong developers will come around and learn the benefits of the platform that allows them to be as performant as possible.
Be sure to run the decision by the senior leadership in your company. Show them the Rapid Prototypes you built in each platform and show them the report card for each. This is a company decision and you want everyone to be onboard.
You can use your Rapid Prototype as a starting point for your app! You don’t have to throw it away. You should have built a viable start to your application that you can extend into your production-ready application. Your work building the prototype has already put you ahead of schedule.
Take your time when choosing the platform for your new application. You’re going to be stuck with it for the life of your app. Get input from lots of different sources from around the organization. Any time you can bring in a new thought or opinion, you provide yourself an opportunity to make your application more well-rounded.
Remember to be objective when grading your Rapid Prototypes. You need to have a list of criteria to map out the most important principles to you. If you can be objective, you have proof to stand by when you make your decision on the platform. It’s hard to argue with numbers.
Learn as much as you can when running through your Rapid Prototypes. Learn about the platforms themselves, learn about how to implement your architecture, learn about how to be agile. Learning is the key to innovation. If you have an open mind and a willingness to learn, you will be amazed at the quality product you produce.
What platforms have you assessed in the past? Do you feel like you made the right decision? Let me know below in the comments.