Twenty years ago, there was a mad rush where every company built a website. Today, every company wants to have a mobile app, and apps are a lot more complicated than websites. You can throw up a pretty nice website in a single day with WordPress, but developing an app takes much longer. Consequently, there are millions of civilians faced with the challenge of managing software-development projects – a daunting task, even for pros. See: “The Long, Dismal History of Software Project Failure.” And no one is immune. For example, Apple’s “Copeland” operating-system project is regarded as one of the largest failures in history (see this).
In this article I will explain some things about software-development tools that will hopefully make things a bit more clear for the non-professional. So, which tools should you use? Should you use what the platform vendor gives you? For example, that would be Apple’s Swift or Objective-C for iOS, and Google’s Java for Android. Or should you use a tool provided by a third party, of which there are many choices?
One of the problems with using the “official” tools is that they play second fiddle to the hardware. Once a hardware company invents a new computer, they must then write an operating system for it. So, the tools they develop to do that are naturally low-level, well suited for an engineer writing a display driver, for example. They aren’t optimized for you to write an accounting app for your small business.
Another problem is that hardware competitors don’t cooperate very well. Steve Jobs famously wanted to crush Android. However, just about everybody developing mobile apps wants them to work on both iOS and Android. And so, there is a huge void for third-party toolmakers to fill, and one of the big things that they bring to the table is “RAD” technology.
Rapid Application Development (RAD) is a style of building software that has reduced the failure-rate of projects. Associated with the methodology is a group of tools designed to speed development. In general, this speed is achieved by abstracting away the native development environment of the operating system, and replacing it with a streamlined model that requires less training, and increases programmer productivity.
Imagine the iPhone as a beautiful work of art sculpted by the geniuses at Apple. Then the RAD designer comes along and says: “I can fix that” takes out his chisel and starts banging away. As you might imagine, it’s an ambitious endeavor, and RAD designers are a special kind of genius.
RAD tools are often expensive, but they are able to command premium prices because they really do speed up development. RAD tools can’t do everything, but for a subset of use-cases, you would be crazy to use anything else. Many people also like to use RAD tools for personal productivity and hobbyist applications because the streamlined development tools let them achieve a “flow state” which is very enjoyable.
RAD tools are also pretty popular; you might have heard of some of them: Visual Basic, Delphi, HyperCard, FoxPro, REALbasic (now Xojo), Xamarin, etc.
Let’s take a look at the major features of RAD tools, and then we will be able to draw some conclusions about the kinds of projects for which they are appropriate.
The Programming Language
First of all, the RAD designer has to invent a new programming language. For example, Apple’s primary programming language in recent years has been Objective C, and here is what the traditional “Hello World” program looks like in that language:
#import
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSLog(@"Hello, World!");
}
return 0;
}
By contrast, here is the same program coded with a RAD tool (Xojo):
MsgBox "Hello World!"
A little more accessible, right? So, the RAD programming language does a lot of the grunt work for you. This language is often referred to as a Forth Generation Language (4GL). As you probably know, computers run on binary code, zeros and ones. That’s the first generation language, but it’s rather laborious for us humans. So, we have something easier called assembly language, the second generation, but that’s still too laborious for most tasks. Consequently, most programming is done in third-generation languages like Objective-C and Java. The code in these languages is run through a thing called a compiler which translates the language into machine code that the CPU can understand.
The Framework
In addition to the language, the RAD designer must abstract the computer’s framework. What’s a framework? It’s the built-in software that makes it easier for programmers to build apps. For example, if you want to draw a circle on the screen, you don’t have to manually switch on the pixels in question. You can just call a thing that does that: DrawCircle(x,y,r,c) will draw the circle after you tell it where to start (x & y), how big to make it (r), and what color (c). A framework will contain thousands of such subroutines, and typically the RAD designer will only implement the most important ones, leaving aside the more esoteric.
The RAD designer is targeting “applications” programmers as opposed to “systems” programmers. The systems programmers are the engineers at the computer company who code all the system software: compilers, drivers, file systems, frameworks, etc. The applications programmers are the ones who buy the computer and then write an app to manage their company’s payroll.
Applications programmers generally don’t have to use the esoteric functions of their computers. So, that’s why a RAD designer can leave out those functions. But there are indeed high-performance apps like games that need low-level code to push the hardware to its limits. So, most RAD tools are not suited for such apps. However, as hardware gets more and more powerful, more and more applications can be handled by RAD tools.
The RAD framework also facilitates cross-platform development. For example, Microsoft and Apple have been rivals for decades, and while their frameworks do pretty much the same things, they are vastly different and require years of study by programmers. But you can cut that learning-curve in half by using a RAD tool that provides you with a single framework and then “cross compiles” for each platform.
The Compiler
Since the RAD designer invents his own language, he also needs to invent his own compiler. You don’t need to know a lot about compilers, but in general you want a RAD tool that compiles to 64-bit “native code” and uses the state-of-the-art LLVM compiler. Once a RAD tool adopts LLVM technology, you know that it will be able to support new hardware in the future in a timely fashion. For example, Xojo recently added support for the new Raspberry Pi 2, a windfall for Xojo developers.
The GUI Builder
Applications programming almost always involves a Graphical User Interface (GUI), so RAD tools always have a drag-and-drop GUI builder. In the old days, you could adjust the buttons, text fields, and lists on your screen by just dragging them to the right place. But with the modern proliferation of screen sizes, you want a GUI builder that can automatically reposition things. You also want one that uses “native controls” so that your GUI looks like all the other apps on your computer. For example, Java uses its own controls and consequently looks horrible on all computers. Just take a look at the thinkorswim trading platform. It’s a perfectly good program, but it’s jarring to both Mac and Windows users because of its crazy GUI. So, when you are selecting your RAD tool, take a look at the apps it builds on each platform it supports and make sure that they have a native look-and-feel appropriate to the platform. If you are developing an app for internal use, you may not care about this very much.
The Database Engine
Most applications need to store data, so most RAD tools have some sort of database facility. Relational databases have been the standard for many years, and these systems are often referred to as SQL, which is the language that you use to talk to them: Structured Query Language. In recent years, a database called SQLite has become popular, so if your RAD tool has that, you will be fine. Of course, your RAD designer needs to do a good job abstracting it like any other part of the system. If you will be working with big data, or enterprise clients, then you want your RAD tool to have database “drivers” that can connect to the major database-management systems like Oracle, SQL Server, Sybase, MySQL, etc.
Extensibility
As you may have noticed, the RAD designer’s job is a big one. And because he has to get his product to market in a reasonable amount of time, he will very likely leave some gaping holes behind. So, you want a RAD tool that is extendable, with some kind of plugin facility that allows you to plug the holes. For example, a long time ago, I developed a product for a startup company in Silicon Valley using the Omnis RAD tool. Omnis was up to the task and the project came out beautifully, but it took a ridiculous amount of time to import the data from the IT department. The Omnis database was adequate, but super slow at importing. However, Omnis had an extension system that allowed me to write an import routine in the “C” programming language that sped up the process a hundred-fold. If a RAD tool is not extendable, then you shouldn’t use it for anything more than hobbyist projects because it is only a matter of time before you hit a brick wall.
Licensing
Speaking of Omnis…I had to stop using it in the mid 1990s when the Internet arrived to the masses. Omnis required that you purchase a serial number for each copy of your app that you made. Such a model is fine for in-house work, and B2B apps, but completely impossible for shareware. So, I switched to Visual Basic which had no “runtime” fees at all. I have also heard of a “free” cross-platform mobile RAD tool that makes apps for iOS and Android, which is only free until you upload your app to the App Store or the Play Store. Then you get a phone call from the RAD tool’s sales department demanding thousands of dollars. And they can enforce the demand because your app is integrated with their backend services, which means that they can switch off your app whenever they feel like it. So, if you are planning on selling your apps, make sure that you know all the licensing details of the RAD tool before you start building apps with it – especially if you will be selling your app to the public.
The IDE
RAD tools also include another large, complex piece of software called an “Integrated Development Environment.” You don’t have to worry about the IDE too much if you are hiring a contractor. If you are a programmer, you definitely want to evaluate the capabilities of the IDE because it has such a large impact on your productivity. And if there is no debugger, then it’s not a RAD tool.
Technology State
Imagine that you are a RAD designer, and you have been slaving away for years on your awesome RAD tool, abstracting away Apple’s “Cocoa Touch” framework. You release your product to great fanfare, and then a few months later at “dub-dub” Apple announces that Cocoa Touch has been “deprecated” in favor of a new framework called Coconut. The crowd goes wild over the new hotness, but your heart sinks because you know that you will have to walk over the hot coals all over again, updating your framework to support Coconut, which will take years. And while you are doing that, all of your customers will be complaining that their apps look old-fashioned on Apple’s new Coconut-based devices. Not fun.
In the software world, things are always being “deprecated” which means that while they will continue to work, they will be done away with at some point in the future. So, you need to get busy and reprogram your stuff. For example, Google has deprecated the first version of its Chart API, and released a new API. As the shut-off date approached, I recoded all of the charts on my DailyJobsUpdate.com website. And just as I was getting ready to do the same to the charts in my BlubberPatrol Android app, Google announced that while the original chart API is still deprecated, they don’t plan to turn it off any time soon. So, BlubberPatrol still uses the old API, which I happen to like better than the new one. But if Google ever changes its mind, and turns it off, and I don’t happen to catch the announcement, I will have to scramble to release a new version. That happens. Just ask Rob Walling; he discusses such an incident at the beginning of this podcast.
In July 2012, Apple deprecated its “Carbon” framework in favor of the new “Cocoa” framework. Granted, a big change like this doesn’t happen very often, but change is coming faster and faster making life harder for RAD designers to keep up. In any case, when selecting a RAD tool, you want to choose one that can generate apps for the current frameworks, and is made by a company that has the staying power to keep up-to-date. You definitely want a tool that can produce Cocoa apps on the Mac and .NET apps on Windows. Android updates are much more frequent, so talk to the user community online or at local meetups and see if the RAD tool has a reputation for staying current.
Critical Framework Support
Before choosing a RAD tool, you should identify the major features of your app. For example, if you will be selling it to the public, how will you collect payment? Will your app do push notifications? Etcetera. Make a list of these features, and make sure that your RAD tool supports them, or if not, whether there are third-party plugins available. Because if you have to dive down and implement such things yourself, your productivity is going to get torpedoed.
So, When Should You Use a RAD Tool?
First of all, pretty much any kind of hobbyist app can be easily handled by a RAD tool. If you want to write an app to catalog your bug collection, you will get it done twice as fast as you would with a 3GL. RAD tools can also handle most data-centric apps. So, if you have a million different bugs in your collection, don’t give it a second thought. If your RAD tool uses a SQL database, it will be fine.
Personal productivity apps, such as a customized to-do list are suitable for RAD tools, as well as office productivity apps: accounting, payroll, customer database, etc.
RAD tools are often used at the enterprise level, for example to build front-ends to huge databases.
RAD tools can be used for some kinds of games. For example, here is an implementation of Flappy Bird written in Xojo.
RAD tools can even be used to write RAD tools. For example, Xojo is coded in Xojo. This is called “self hosting” and is pretty solid evidence that the tool can handle large, complex projects. Xojo can also build web apps.
Many apps sold to consumers are written with RAD tools, and the original incarnation of BitTorrent was written in Python, which is not strictly speaking a RAD tool, but you might call it a 3.5GL. BitTorrent has since been rewritten in C++, but that was only after it took over half the internet.
So, RAD tools are capable of handling large projects. However, as we discussed, RAD tools are ambitions programs and require a lot of time to develop. So, if you want to be first to market on a new platform, RAD tools are pretty much out of the question. If you want to be there on Day One with your dashboard app when the first AppleCar rolls off the assembly line in 2019, I suggest that you start learning Swift right now, or make the acquaintance of a Swift programmer to contract with once Apple releases the SDK (software development kit).
On the other hand, you can be there on Day One with a RAD tool when new APIs are released for existing platforms. For example, when WordPress releases its much-anticipated REST API, RAD developers just might be the first to market with client apps in many categories.
If you are trying to win design awards, you probably don’t want to use a RAD tool since it may not support the fancy things that you are trying to do. If you are making a game that pushes the hardware, you probably want to use a 3GL. If you are doing something very innovative then you probably want to use the platform vendor’s tools.
If you are developing a mobile app, and you want it to run on both iOS and Android you are faced with a choice: You can hire two programmers, one to write the iOS version in Objective-C or Swift, and another one to write the Android version in Java. Or you can hire one guy to do both apps in a RAD tool like Xamarin. Obviously, Xamarin is going to win a lot of these jobs because it can do them for half the price in half the time.
Why I Like to Use RAD Tools
Many “real” programmers wouldn’t be caught dead writing an app with a RAD tool. They think that RAD tools are for a lower tier of coders who just can’t handle real programming. Sort of like an automatic transmission in a car for the “idiots” who don’t know how to shift their own gears. But even though I am a “real” programmer with a CS degree, I prefer to develop apps with RAD tools. Why? Because I like to get things done. I like to finish projects quickly, so that I can go onto the next challenge. If you have a lot of ideas, and you want to bring them to life, a RAD tool can help make it happen a lot faster. Thirty years ago, I began writing software with Omnis 3. Then, I switched to Visual Basic for many years, and for the past fifteen years, I have been using Xojo. I made a lot of money and had a lot of fun. RAD is good stuff.
Further Reading
