Back in the day (as if that was really that long ago for me ;), “rapid application development” used to be a phrase that was used to describe the amount of time we could take an idea and get it into a functional prototype in order to evaluate its utility.

That reads terribly, terribly boring.

Think of it this way:

How fast can you take an idea, turn it into a functional prototype, and determine if it sucks or not?

Or maybe:

In general, RAD approaches to software development put less emphasis on planning tasks and more emphasis on development.

Maybe that fits with more of the cultural norm than, say, 15 years. ago. Anyway, there were tools like Visual Basic that made this easy.

Admittedly, I was a little young to grok what all of this was about, but I read a lot, and I tinkered with Visual Basic from 3.0 up to .NET so I was pretty familiar with the language and how the whole system worked.

But enough of that kind of talk. Here’s the question: How can we apply rapid application development within the context of WordPress?

Furthermore, is it possible to apply it in a way that allows us also to iterate on a product (free or not being irrelevant) without only evaluating its value to our users?

Can We Do Rapid Application Development?

The short answer is yes; I think that we can do rapid application development in WordPress. And given the nature of open source, tools like GitHub and other related open source services, we’re not only able to do rapid application development, we’re able to get quick feedback, make changes, and offer updated releases faster than ever.

And given the nature of open source, tools like GitHub and other related open source services, we’re not only able to do rapid application development, we’re able to get quick feedback, make changes, and offer updated releases faster than ever.

Yes, this requires a little bit of technical know how but it’s not all for not. After all, we don’t want to release half-baked products to our non-tech-savvy users and friends, do we?

But how might this look? I don’t have a one-size-fits-all description, but I can give some anecdotal experience based on something I’ve been working.

My Experience with a Personal Plugin

Last week (at least at the time of this writing), I pushed a small plugin to GitHub. The functionality in the plugin was meant solely for The First Version, but thanks to two people (namely Gary Jones and Eric Dye), I received a pull request and a couple of [private] notifications of things to be aware of should I opt to release this to a wider audience.

Rapid Application Development in WordPress

Anyway, as far as rapid application development is concerned, the short answer is that “yes,” WordPress works fine not only for rapid application development but also for shipping something that works and shipping it quickly.

By this, I mean you can rapidly develop a solution for a problem that’s relatively stable and have it ready to be used by users even though the final version of the product may look widely different on the side.

That doesn’t mean it gives an excuse for leaving things as they are. For example, the current release (again, at the time of this writing):

  • The plugin has lots of `TODO` items for documentation and future features.
  • It’s written using procedural code (which isn’t bad, but I prefer object-oriented code).
  • It’s feature incomplete.
  • It doesn’t use 100% of the best practices I’d like to use.
  • It throws red flags for the WordPress Coding Standards using the PHP CodeSniffer.

But you know what? It proves the concept, it’s running on a site that I’m in charge of running, and it’s serving its purpose.

Is it done? No way. It’s going to go through refactoring, beta testing, and likely released as something for a wider audience. But more on that later.

A Warning About RAD and Open Source

Lastly, and this is one thing about open source software available in a public repository:

If your plugin is not intended to be used in a production environment, then make sure it’s clearly visible in your README or in some other documentation you know your visitors will read.

The last thing you want to do is to have a semi-developed piece of software you’ve built for yourself that others end up using and then breaking their own site. You don’t want them coming back to you reporting problems for something that may not even be how it’s intended to be used.