Child pages
  • Rapid Application Development (RAD)
Skip to end of metadata
Go to start of metadata

I'm of two minds about putting up a page in the DevRoadmaps Wiki for RAD.

On the one hand, this part of the site is for general development topics including more traditional and usually hand coded approaches to business application development; RAD is more often the province of tools like Clarion and WinDev, both of which have their own spaces here. 

On the other hand (and both hands are coding), tooling for non-RAD development has over the years become decidedly faster. Commonly-needed functionality becomes commoditized; languages become more expressive; IDEs provide better support for code management.

Mark Goldberg recently pointed out one such code management tool: Code Canvas:

Code Canvas is a new user experience for Visual Studio 2010 that provides an infinite zoomable surface for software development. A canvas both houses editable forms of all of a project’s documents and allows multiple layers of visualization over those documents. By uniting the content of a project and information about it onto a single surface, Code Canvas is designed to leverage spatial memory to keep developers orient-ed and to make it easy to synthesize information.

Check out the YouTube video.

I expect that for many smaller teams tools like Clarion and WinDev will remain the preferred option for years to come. But for larger teams, or for smaller teams with a lot of skill in object-oriented programming, there are some compelling reasons to consider the hand coding approach. (In fact, hand coding these days often does include code generation via T4; it's just not application-scale code generation.)

Two productivity curves that meet

RAD tools provide a ready-made application framework into which you plug your custom code. You're productive very quickly; however, if your application (or set of applications) becomes very large maintainability may in fact become more difficult. In the case of WinDev and Clarion this is largely because of the temptation to put business logic into embed points where it is difficult to test and reuse. 

In a traditional coding environment you're not as immediately productive, but if you have the right team you can build a more testable, reusable code base. Down the road maintenance becomes significantly easier because you have a full suite of tests that continuously validates your code. You also have many smaller, more reusable components. 

Which is better? 

For smaller teams and quick delivery, RAD tools have the advantage. As the application grows in size and complexity, that advantage begins to diminish. In my opinion (I don't have hard data to back this up) the longer the time frame, the more code is involved, the more likely it is that at some point the productivity of the hand code approach will approach and possibly exceed that of the RAD approach. And the code quality will most likely be higher. 

There is one important caveat: you need a higher level of skill to pull off the traditional approach. You need people with good object-oriented programming skills, you need application designers not just coders, you need a high degree of automated testing and continuous build integration so you can track the state of your code. 

The hybrid approach

It's also possible to blend the two approaches: there's no reason you can't separate your business logic into testable, reusable classes, and then call those classes from embed points. In this middle path you still get many of the RAD advantages, although your upfront investment is greater. 

 

 

  • No labels

3 Comments

  1. Hi Dave,

    You made many good points. Let me comments on some.

    >... however, if your application (or set of applications) becomes very large maintainability may in fact become more difficult. In the case of WinDev and Clarion this is largely because of the temptation to put business logic into embed points where it is difficult to test and reuse. 

    Agree. This is why we use Clarion only as a tool to quickly create application windows - data entry and view. All business logic is held in the Oracle/MS SQL Database Layer in the form of DB objects - packages, procedures, functions, triggers, sequences, etc.

     

    >There is one important caveat: you need a higher level of skill to pull off the traditional approach. ... you need application designers not just coders, ....

    Over the years we learned that we need application designers even with Clarion, although we thought that we don't. Suddenly our applications got much prettier and user friendly. It's not that Clarion produces ugly and old-looking apps, it's that we most of us don't give appropriate attention to application design.

     

    >It's also possible to blend the two approaches: there's no reason you can't separate your business logic into testable, reusable classes, and then call those classes from embed points.

    We do this with database packages. Although packages are not true classes, you can still create subprocedures and have the concept of package/procedure variables. We put all our business logic inside packages and call those from embed points.

  2. >> As the application grows in size and complexity, that advantage begins to diminish. In my opinion (I don't have hard data to back this up) the longer the time frame, the more code is involved, the more likely it is that at some point the productivity of the hand code approach will approach and possibly exceed that of the RAD approach. And the code quality will most likely be higher.

     I disagree.

    a) code quality has nothing to do with project size, or whether you generate or hand-code. Code quality has to do with the programmers writing the code. Good programmers will write good code, bad programmers write bad code. In the case of a generated framework at least the amount of hand-code is minimized, and thus the opportunity for bad code is reduced.

    b) Large projects, by definition, are large. However if some percentage of the code (say 72.4%) is generated, or based on standard libraries & classes, then that code can be discarded from the notion of "maintenance". The key to successful long-term maintenance is reducing "specific" code, and increasing the use of "generic" code.

    c) The overall consistency of the code, screens, data interactions and so on is also key to long-term maintenance. If "bigger" means "more of the same" then maintenance is easy. When "bigger" means "much more complexity in reading the code" then maintenance gets harder. Language, and even environment here is unimportant. Clearly it's possible to create a mess, or be very organized, regardless of RAD/no-rad.

    RAD systems offer the advantage that they provide a pre-constructed framework, with Generic code, into which the developer can fit. The degree to which they leverage that advantage is obviously up to them. Certainly with Clarion there is no restriction on the many ways generic code can be added to that framework. This doesn't stop people doing bad things, but they're not doing it because of RAD, they're doing it because hey want to.

    Anecdotally I am personally aware of many projects, built in Clarion, that span 15 years of development, are now "large" (whatever that means) and yet are perfectly maintainable. I'm also aware of hand-coded projects in the same boat. Equally there is clearly no shortage of hand-coded, or generated systems which are incredibly brittle, and essentially unmaintainable.

    >> In the case of WinDev and Clarion this is largely because of the temptation to put business logic into embed points where it is difficult to test and reuse.

    In short, what you are saying is "these tools allow you to do things that may hurt later on." Which is like saying "don't program in Basic because it has a GOTO statement." The possibility for poor use is not a good measure for using, or not using, a system.

    If you want to compare the output of RAD systems with poor programmers with Hand-Coded systems and (what you called) the "right team" then you are bound to come to some wrong conclusions.

     

     

     

    1. Bruce, as always you make good points. 

      Yes, RAD systems do provide advantages. Having built fairly complex applications (and subsystems) with and without RAD, I'm keenly aware of the pros and cons, at least inasmuch as they've been pros and cons for my own experience. 

      In short, what you are saying is "these tools allow you to do things that may hurt later on."

      Much more than that. RAD systems (and here I mean Clarion and WinDev) both provide places to plug in embed code. You can plug in crappy code, or you can plug in good code. But in either case, by putting your business logic in embed points you're still severely limiting your ability to test and reuse code. You don't have to put it there, but given that almost everyone does, I think it's fair to say that the tooling fosters that approach.

      RAD systems offer the advantage that they provide a pre-constructed framework, with Generic code, into which the developer can fit. 

      When products like Clarion were in their ascendancy, there were very few reuse options available in the hand coding world. Code generation had a clear advantage. But there are so many ways to reuse code now that a code generation framework doesn't have the same benefit it once did. 

      How many hand coders write apps from scratch now? They use libraries and frameworks. CodeGen is one way to supply a framework, but hand coding frameworks also abound. 

      If the codegen framework doesn't have any material limitations, and if it's sufficiently adaptable, then possibly the best option is to use both - business logic in classes, grunt work in generated code,  call the classes from embeds. That's certainly my preferred way to work with Clarion. But I'm not convinced that in the long run that approach provides a clear advantage. 

      I think we all need to be careful about the assumptions we make. Don't assume that because Clarion or WinDev can generate a bunch of code for you that this is automatically the best option. 

      And don't assume the rest of the world has been sitting on its hand code, and that the comparisons we (Clarion developers) made in 1986 or 1994 or whenever are still valid today. Many of them are not.