Once upon a time, Rapid Application Development “meant” IDE. This was Turbo Pascal. One could way faster work with an integrated environment rather than with disparate programs trying to fit them together in order to form a toolchain.
After this was the Visual bubble. The Form Designer with an Object Inspector near to it in order to speed up the GUI development process. This was Delphi and Visual Basic…
But I think that Delphi remained mostly there whereas the methodologies to boost the developer’s productivity advanced.. And this is really bad because Embarcadero is in the (almost) unique position to control everything in the toolchain: the compiler, the linker, the IDE, the standard library and of course the language specification.
I don’t know any other company (except of Microsoft, of course) who can say such a thing in such conditions. Well, perhaps there are other open source projects or closed source companies but they doesn’t have the necessary coordination and focus and/or the necessary community. Well, Embarcadero has them all, it is upon them to leverage this.
But what means RAD anyway?
Let’s see first the Steve McConell’s definition:
To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it’s RAD—a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it’s rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it’s whatever practice was highlighted in the most recent issue of Business Week.
Each one of these tools and methods is fine as far as it goes, and each can contribute to increased development speed. But to provide full benefit, each must be orchestrated as part of a full-fledged strategy. No one of them applies to all cases. And no one of them can measure up to certain other practices that are not commonly thought of as rapid-development practices but that nonetheless have profound development-speed implications.
Rather than identifying a specific tool or method, for purposes of this book “rapid development” is merely a descriptive phrase that contrasts with “slow and typical development.” It isn’t Rapid Development™—a magic phrase or buzzword. … It means developing software faster than you do now.
A “rapid-development project,” then, is any project that needs to emphasize development speed. In today’s climate, that description fits a lot of projects.
Steve McConell, Rapid Development
Well, as you see is all about humans.
So, in few words a RAD tool should support the developer in his human thinking, allowing him to concentrate on his human (business) which has to solve. The tool must obey to programmer not the programmer must obey to tool’s possibilities. A good RAD tool should favor the best practices and discourage the dangerous ones. And for this we need a lot of feedback. And I think that this is the most single important point in our industry today: write good code, cheap, fast. And we must pick all the three.
Of course there are many improvements which can be addressed in this area (stay tuned for more posts) but I think that, knowing the direction where Delphi is heading (ie. cross-platform), usability improvements and new features to the UML engine as well as to the Class Explorer would be a must. Closely related to this, a MVC pattern generator tied to an Object Persistence Framework based on the actual data which we have (IOW, on database schema, developer intentions etc. – see Ruby on Rails for a skeleton) with support in the IDE will make the things a lot easier.
Trying to decouple as much as possible the Presentation Layer from the Application Logic require more code to be written and we need tooling for that. Otherwise we’ll end up 99% of time using Delphi just like any other code editor which sends commands to a command line compiler.