WordPress For Rapid Application Development

Last week, I talked about using WordPress as an application platform – once again, even – but Ted Waller brought up an interesting comment that I’ve not heard (at least here on this blog) that I wanted to discuss a bit more.

Specifically, Ted said:

Whether or not it’s wise to use it as the final application framework, I do think it’s very good for rapid prototypes of web apps.

And what really caught my attention about this particular comment was that I’ve not often heard of WordPress as being a tool for rapid application development (or RAD).

The thing is, RAD – for whatever reason – has often been used whenever someone is talking about prototyping an application or doing some type of development, but nothing that’s seriously ready for prime time, for the enterprise, or for whatever term you’d opt to use.

But the more I thought about it, the more I wondered:

  • Is rapid application development misunderstood?
  • Is WordPress truly good for RAD or is it the best of both worlds?

Using WordPress For Rapid Application Development

First, note that this post is not in response to Ted’s comment more so than it’s inspired by Ted’s comment.

He happen to strike a chord with me that’s resulted in me wanting to open the discussion for the rest of us.

Rapid Application Development – It’s Misunderstood!

Truth be told, the first time that I ever came across the term “RAD” was when I was a kid and I was messing around with Visual Basic 3.0.

One of the selling points of this particular language (and its associated tools) was that it played directly to the RAD movement that was [apparently] happening in software development at the time.

Honestly, I was too young to really know what was going on in the industry.

All I knew was that Visual Basic made it trivially easy to “design” an interface, hook up some code to various widgets on the form, and then make something happen.

For a kid getting into programming, that was awesome.

But then when I discovered the programming forums on AOL, and a lot of older developers were talking about how VB was great for RAD, but anyone writing anything serious would be using C++ (or Visual C++ or Borland C++ or whatever compiler was hot at the time).

So this made rapid application development seem like it was something that people were doing who weren’t serious about building software.

But here I am nearly 19 years later and Visual Basic is still around. In fact, it’s a first-class language on the .NET framework (though it has changed significantly).

And now, we’re hearing that WordPress is a great tool for rapid application development.

But does this mean that that’s a bad thing?

According to Wikipedia, rapid application development:

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. The “planning” of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

When I read that, there are really very few negative things about rapid development that seem bad.

In fact, I’ll go as far as to say that the main negative – at least for me – is the lack of planning (or “minimal planning”) that goes into building a piece of software.

But I think this can work under very constrained circumstances.

Ultimately, I’m left drawing the conclusion that rapid application development isn’t actually a bad thing. In fact, it clearly has it’s place in software development.

I just wonder if I’ve been given a pessimistic by the term simply because of my earliest experiences with it.

Is WordPress and Rapid Application Development The Best of Both?

Assume for a moment that rapid application development is bad, but we’re using WordPress as our platform of choice for generating an application.

Is it really a bad thing to “prototype” an application on top of a platform that clearly scales to the needs of thousands upon thousands of sites many of which are hammered daily?

Obviously, this is somewhat of a rhetorical question, but the point is that even if rapid application development is something that we should be avoiding as professional developers, I think we could do far worse using WordPress as the platform for a prototype.

On the other hand, let’s assume that rapid application development isn’t a bad thing, and we’re still using WordPress as our platform for prototyping the application.

Aren’t we left with the same results?

Specifically, we have a platform that scales to the needs of thousands of sites loaded up every day.

At this point, I’m wondering if there even is any kind of tension between WordPress, rapid application development, and prototyping an application.

I’d go as far as to say that if you’re going to use WordPress as the platform for your application, why bother using it just to prototype? If it caters that well to rapid application development, then go for it.

Regardless of your language or platform, I still think that we should leave prototyping up to simple sketches, mockups, and/or shallow HTML pages with some fancy styles and client-side functionality.

18 Comments

wow, i was just thinking about this concept this past weekend, especially in terms of lean and mvp… i was thinking even about “mva,” minimal viable app.

i rad that shit all day.

My only experience with RAD is a very small dose. But the major thing that I can see in it is a mis-conception on really how complex application development can be. What I mean is that sometimes the people that need to see that quick prototype working, don’t fully understand application development. They don’t realize that in order to develop something that scales and is robust enough to become a full enterprise/production level piece of software, certain aspects of the application need to be in place that may never be “seen.” So they tend to think that if the developer churned out, what is in their mind, the full application in a few days, then adding in a feature here and there may only take a few hours.

With that being said, WordPress as a framework obviously is a HUGE topic of discussion. But I agree Tom, I believe that prototyping should be left to sketches and mockups. But if WordPress does fit the project requirements at hand, and it’s a viable option to use it for the platform of the final application, why not use it from the start? You do get that robust and scaleable framework from the start and those “unseen” aspects are in place.

But if you are going to scrap WordPress in the end, why waste the cycles in spinning up something that you ultimately aren’t going to use anyway. I’m all for having the business requirements drive the technology used.

    They don’t realize that in order to develop something that scales and is robust enough to become a full enterprise/production level piece of software, certain aspects of the application need to be in place that may never be “seen.”

    Amen – and, in my experience, it’s about half-and-half. That is, about half my clients are more technically savvy so they understand there’s a lot of stuff behind-the-scenes. Others, who aren’t so technically inclined, trust me but tend to be curious about the process or why something tends to take more time on what they thought should be a quick fix.

    But if WordPress does fit the project requirements at hand, and it’s a viable option to use it for the platform of the final application, why not use it from the start? You do get that robust and scaleable framework from the start and those “unseen” aspects are in place.

    Exactly. And this isn’t to say that there aren’t things that may need to be tweaked, but you do get a lot for free which is something that makes it so attractive for a number of content-management or web-app solutions to me.

    I’m all for having the business requirements drive the technology used.

    Yes – and sometimes, the requirements may specifically say that want to use WordPress; other times, they won’t specify. And in the case of the latter, that’s where we come back to prototyping and where I think shallow front-end prototypes become useful.

Hi Tom,
I’m using WordPress as a rapid prototyping tool for a client right now. Even though the final application cannot (will not) be developed on WP, it makes so much sense *for me* as a prototyping platform – I’m able to quickly test and roll out different working GUIs in a fraction of the time it would take otherwise.

When I decided to prototype this project with WP, I thought maybe I was being lazy, but the further I’ve gotten into, the more I think it was a good move in the interest of both me and my client. Thanks for affirming me with this write-up. Ha!

Carrie

    I’m using WordPress as a rapid prototyping tool for a client right now. Even though the final application cannot (will not) be developed on WP, it makes so much sense *for me* as a prototyping platform – I’m able to quickly test and roll out different working GUIs in a fraction of the time it would take otherwise.

    I’m a big fan of developers using tools that makes sense for them because I err on the side of the client not needing to know (or care) what the solution is implemented in so long as it provides for their core need.

    That said, I’m curious: why can’t (or won’t) the final solution be implemented in WordPress? Not a loaded question – genuinely interested :).

      The GUI will end up being a sort of “skin” that sits on top of an existing application. The end client is a gov’t entity, so my piece is a very limited one in a much larger pie. :)

        Gotcha – and good luck with working with a government site.

        This isn’t meant to be a political statement in the least. I just know the quality of those sites (but I also know the budget that comes with them), so congrats to you – and good luck ;).

I’m also genuinely interested in why not to implement it in WordPress. Is it speed? Or security? Or…?

Interesting when you quoted Wikipedia with this statement: “uses minimal planning in favor of rapid prototyping”. I thought about how WordPress’s templating system makes it very simple to have a boilerplate template to clone and build other pages from. That seems to be the idea behind WordPress templating in general, and something that I love and hate at the same time. The simplicity is outstanding but I also see it as an inherit weakness in using WordPress for sophisticated layouts that vary across multiple pages. It’s one of the primary reasons that drove me to do things completely differently in Armstrong Theme.

I agree RAD is a loose and probably misunderstood term. But you can open up a whole can of worms about PHP itself. PHP has been used and abused to no end. But at the end of the day it comes down to one thing: What can the users actually use and get the job done with? WordPress and PHP are super easy, super flexible, well-designed, and have a fantastic community. Server technology will allow expansion to mass volumes and the costs are cheap compared to the extra labor when dealing with more sophisticated languages and software systems.

I’m kind of rambling here… but your post was kind of written in the same vain of open-ended thinking. It sparked some of my own thinking so I threw out my 2 cents. :) I love your style Tom!

    I agree RAD is a loose and probably misunderstood term. But you can open up a whole can of worms about PHP itself. PHP has been used and abused to no end. But at the end of the day it comes down to one thing: What can the users actually use and get the job done with?

    We’re on the same page here in that I don’t get into the religious debates over if PHP sucks or not. As far as I’m concerned, it does a lot. Play up to the good parts, avoid the bad parts.

    The same can be said for JavaScript but people rarely talk about that as frequently as they do about PHP.

    Sure, I’ve used other languages, too (Ruby, Java, etc) and I do love Ruby for a variety of reasons, but at the end of the day – for me – it’s about building good stuff for others. And if I can build it using PHP and doing so using conventions that make the code readable, maintainable, and scalable, then why not?

WordPress is always use for rapid application development because WordPress contains an outstanding CMS that allows you to quickly publish all your content without having the need to know HTML code.You can quickly modify your website with the WordPress on the internet management board or by using one of the free resources.

    Oh, sure. You’re definitely right – but the main point of what I was trying to share was that people often using WordPress as a way to prototype applications but opt not to actually use it for production-level applications when, in fact, I believe that it’s perfectly able to serve as such.

I’ve used WordPress twice for this sort of thing, although I wasn’t even aware of the term RAD at the time! These were my own personal projects that were at a very early stage (i.e. pretty much just a vague idea), and I found it was a great way to very quickly knock something up to give me a feel for whether there really was a good idea somewhere in there or not. It also flagged up potential problem areas I’d need to give more thought to, as well as giving me a couple of really useful lightbulb moments.

As a sidenote, the plugin I found most useful as part of this process was Gravity Forms, as it meant I could very quickly create front-end forms for user-generated content and use its multitude of hooks & filters for custom actions.

WordPress stands on a very powerful data management platform and provide best tool than the another CMS. Rapid application development with WordPress makes our world a better, faster place.

This is really a new stuff for me to understand even though I’ve WordPress experience., WordPress the best & cheap content management platform that I have worked for many of our clients in years and RAD in WordPress is interesting- thanks Tom (I should into deep research of rapid application development with WordPress)

Having built a few web-apps on WordPress, I can safely say that its not just for RAD but it can easily be used as your GO TO framework for majority of applications. And with a more robust JSON API, this is going to become a norm in the web app industry.

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>