Pro and Low Code Platforms from the Developer Perspective
In August, 2018, an independent company conducted a hackathon at its offices to compare different application development strategies across pro and low platforms on the market today. They gave me inside access to the hackathon to provide feedback on the results and provided permission to report on the findings externally. This is my report of the hackathon.
In this report I first lay out the scope of the hackathon, and then list out the various points of learning that were gleaned from the hackathon. Finally, I summarize it all in an easy-to-use checklist that you can use when evaluating app platforms and strategies.
Let’s get started.
Scope of the hackathon
The hackathon involved 5 teams, each assigned an application development platform (or combination of platforms) on which they were to build a sample application. The goal of the hackathon was not to build the best app in the given time, or even to figure out which was the best solution for application development. Rather, the goal was to glean maximum learnings about each development platform under scrutiny, and get a better sense of where the ecosystem stands today.
Platforms assigned to teams
The hackathon tested the following application development platforms:
- Azure (using Xamarin)
- Mendix
- Kinvey
- Outsystems
- AWS (Using React Native)
As is clear from the list, there is a spectrum of approaches ranging from ‘pro’ code to ‘low’ code, each with trade offs in terms of developer control. The different approaches they take to app development made for varied perspectives from the teams. The reason for choosing these platforms is that they are the leading platforms when it comes to developing mobile apps for enterprises.
The challenge for the hackathon was to build a field services app with the following specifications
Minimum requirements for the app
The challenge given to teams was to build a B2E (business to employee) mobile app
● That works on iOS and Android
● That integrates with an existing auth provider
● That integrates with existing “enterprise” data
● The presents at least one form for collecting/saving new data
● That works offline
● That does some level of server-side manipulation of the data
While these were the minimum requirements, teams were encouraged to go beyond these expectations and include additional bonus features for which they’d get extra points.
The teams were given a scenario from Star Wars where a field service app was required to support the organization’s technicians as they repair and maintain a fleet of starships.
The hackathon was a great way to assess developer expectations versus reality when working with a variety of development platforms. It helped shed light on the kind of aspects developers should be looking for when choosing a high productivity app development platform
Developer priorities
Though I start with this section, I framed this list of priorities at the end, after hearing out each team’s experience with the platform(s) they were assigned.
These are the abstract goals of developers in the hackathon irrespective of the platform they worked on:
Get started quick
The first thing I noticed was that every team wanted to build something quickly, even if it’s something as simple as an MVP or proof-of-concept app. As required by the assignment, they began by building a mobile app, which also happens to be the case in many real-world scenarios as well. Platforms that require a lot of learning upfront were not preferred.
Visibility & access to code
They wanted visibility into the applications they were building. Despite some of the platforms being low code platforms, the developers still wanted to have access to the code, and have the ability to make manual code changes when needed. They also appreciated solutions that gave them quick feedback on their code changes in the form of live previews.
Self-serve & support
A key need that every team voiced was the need to find answers to obstacles they ran into along the way. They look for answers to very specific questions, and want to find these answers on their own. They prefer a self-serve model rather than hand-holding by customer support. Nevertheless, they often were stuck at a point, and saw the need for training and customer support when the learning curve got steep.
The hackathon also presented many surprising findings about the state of development platforms available today.
What to look for in a high productivity cloud platform
I’ve collated the impressions of the developers from the hackathon under four sub-headings:
- Support & learning resources
- Frontend UI
- Backend integration
- Developer experience
They give us a holistic picture of the state of development platforms today, and how developers view them.
Support & learning resources
Since the developers at the hackathon didn’t have prior experience with the platforms, they bumped into a lot of issues at every step of the way. The most vocal need for the developers was the need to find answers and solutions to help them complete specific tasks.
The information cliff
There are various types of support resources available for each platform. This includes product documentation, tutorials, forums, and even blog posts. An interesting observation that one of the teams made was that there was a noticeable information cliff when they moved from the docs to real-world development. In many cases, the real-world experience of building applications was more difficult than the vanilla use cases covered by the documentation. In these cases, they needed support and training that only an internal team could provide. This kind of hand holding at the beginning would save a lot of time, and help familiarize developers with the platform. Ideally, developers would prefer documentation that is close to reality rather than over simplified use cases.
Quality of resources
When it comes to learning resources, freshness is important. If screenshots are completely outdated developers can’t follow the exact steps. For example, one of the docs pages for Outsystems that describes how to integrate an app with Salesforce is 5 years old and the Salesforce interface has completely changed since.
Developers at the hackathon looked for specific use cases. For example, when it’s a combination of platforms like Azure+Xamarin, having separate documentation for each platform doesn’t help. The docs use cases should be about using both platforms together. Similarly, some plugins & components may have their own docs separate from the main development platform and this can be difficult to work with. For example, React Native has separate docs for each plugin. The developers preferred more comprehensive docs & a well-integrated system.
External watering holes
It’s no surprise that Stackoverflow was the go-to place when developers couldn’t find an answer in the docs. They preferred platforms that were buzzing with activity on Stackoverflow. For example, React Native has over 38,000 questions on StackOverflow, whereas Mendix has just 11. This makes a big difference when looking for answers to specific issues. Apart from StackOverflow, other places that proved to be useful were Slack, IRC, and Reddit.
Frontend UI
The frontend UI of an app greatly influences an end user’s perspective of an app. A development platform that enables developers to build elegant and functional frontend interfaces is table stakes in today’s competitive app ecosystem.
Developers understand there will be trade offs between productivity and developer control to deliver a UI that meets user expectations. For the purpose of this hackathon in building a primarily B2E app, a demanding UI was not a core requirement.
From 0–100 in…
As mentioned earlier, the developers at the hackathon were eager to standup a minimal version of the as soon as possible. This requires out-of-the-box mobile support for Android & iOS, including support for responsive layouts for devices like tablets. They expected to create a ‘Hello world’ app in 10 minutes and instantly run it on a mobile device. The Azure+Xamarin team were all praise for their platform in this regard. They were able to get a minimal app up and running in minutes.
UI designing
The developers were looking for easy ways to create frontend elements like tabs, dropdowns, and lists without the need for CSS manipulation. This quickens frontend development. However, they also wanted to have the option to dig in and make customizations quickly once the basic wireframe was in place. When designing the UI, live preview of changes was a helpful feature that some platforms like Outsystems excelled at.
Not just a pretty face
Beyond the look and feel, the developers also looked for easy ways to drive engagement in the frontend UI. This includes features like offline support. For example, the Kinvey team found it easy to implement offline support for data — a key requirement for the field services app they were building. On the other hand, the Azure+Xamarin team found it difficult to implement the same as they couldn’t implement Salesforce integration easily. It’s not enough to get started quick, development platforms should be able to sustain the initial momentum long after a promising start.
Another important aspect when it comes to frontend development is developer productivity. Developers at the hackathon gave importance to code reuse. They ideally want to write less boilerplate code, and be able to easily create new pages, and add new features quickly.
Backend integration
While the frontend gets developers started quick, the bulk of the development time is spent building and integrating the backend. This is especially true of enterprise organizations that have large data stores with billions of data points spread across different systems having completely different data formats and schemas.
Data first
Enterprise developers prefer a data-first approach to application development. UX typically comes after defining the data model. While some of the development platforms analyzed in the hackathon were designed with this in mind, other platforms felt counter-intuitive. For example, the Azure+Xamarin team found their stack to be frontend-centric where it was easy to design the frontend of their mobile app in minutes, but thereon, they found it difficult to integrate the frontend with backend data stores. If the backend is difficult to manage, the platform is seen as good enough only to build basic apps not enterprise apps.
To aid with data integration and a data-first approach, some features that developers valued highly were seamless OpenID integration for authentication, and robust data import features like importing via Excel, XML, or JSON.
Integrating with enterprise data
The developers at the hackathon were tasked with integrating their mobile app to a data store in Salesforce. They typically attempted this integration via REST API or plugins depending on the platform they were working with. Each team had different experiences. The Kinvey team found it easy to setup the Salesforce integration and were the most vocal among the teams about how seamless the process was. On the other hand the Outsystems, React Native, and Azure+Xamarin teams found it difficult to integrate with Salesforce for various reasons. These teams weren’t able to complete the integration despite hours of searching for a solution.
Developer experience
Developer experience is the sum of all the previous aspects listed above, as well certain touches that make a development platform ‘just work.’
From the get-go
Getting started fast is essential for a great developer experience. Installation of a desktop client, development environments, and dependencies should be quick. Anything more than 15 minutes is bad. The Azure+Xamarin combination was quickest to setup and create a basic app with.
Additionally, the platforms that provide a desktop client need to support all major operating systems — Windows, Linux, and Mac. One platform that lacked this inclusiveness was Outsystems — it is Windows-only for now.
Building speed along the way
Not just during the installation phase, the developers placed high value on platforms that helped them get things done quick. Speed of development is a combination of how fast developers can push a build, perform a data sync, or even debug errors. Debugging needs to lead to the root cause quickly. This means console error messages need to be clear & helpful.
Another way that the platforms helped developer productivity was by requiring less boilerplate code. Anything already built should be easy to duplicate when needed. Apart from this, a stable IDE and intuitive interface are unsaid expectations that every developer has. If the platform relies heavily on plugins, which is the case with most development platforms, the functionality should still feel native-like.
A development platform shouldn’t require the developer to learn new skills. For example, the Azure+Xamarin solution didn’t score high in this regard as it required knowing XAML for frontend development. Finally, the ability to collaborate with other developers & testers was seen as vital functionality for a development platform.
Concluding thoughts
Here’s a summary of what the teams felt about each type of platform:
- Pro code platforms: The IaaS options (Azure, AWS) with front end frameworks were surprisingly fast and easy to get started with. However, productivity quickly slowed for each app requirement during the allotted time.
- Low code platforms: The low code UI driven platforms such as Outsystems and Mendix were really nice for rapid prototyping for a number of app layouts, but fell short on the backend integration requirements. Kinvey provided more developer control with NativeScript, and its low code backend shined when it came to Salesforce integration and offline data management. However, it lacked drag and drop UI components.
It’s not my goal to recommend a single best platform out of the lot here. My goal is rather to give you a real-world picture of what it’s like to work with the various development platforms available today. Hopefully, after reading this, you are better equipped to make an educated choice on which strategy is right for your next app. To get more specific, here’s a checklist that covers all the points listed above so you can easily check them off when comparing your options. Feel free to expand on this checklist and make it your own.
Checklist for evaluating pro and low code platforms
