why doesn't everyone use RAD tools?

Question

RAD tools like Clarion and WinDev claim to be 10x to 20x times faster in development and users of these tools claim the same. If that is thru, why are there so few people using these tools? if an application is made in 40 hours instead of 400 you would make a lot more money, right?

Answer 1

Rapid doesn't always mean accurate. An example I can think of, if someone were developing a pacemaker, I'd rather they spend 400 hours getting it correct instead of developing it in only 40 and risk a potential disasterous result.

Answer 2

Not entirely true. They can enhance the productivity for some tasks bit not all. And most IDE's already contain lots of tools to enhance productivity. For example code templates and code completion. So I don't think they can manage a 10 to 20 times for an entire project, compared to other modern tools.

Answer 3

RAD tools doesn't give you the customizability of writing things on your own. The customer usually says something like "This would be nice if it worked exactly like this", which would be a really fast change if you had coded it, but will require you to study the tool to see if this change is possible (and frustrate the customer, if it isn't).

Also, you have more control on what is done, and is less likely to have weird behavior 'caused by wrong assumptions. It's easier to write tests too.

Finally, it's a whole new thing to learn, with a risk that the time spent is not worthwhile (maybe it would be, but I'm not willing to take a risk of learning something too specific which I might not use).

Answer 4

Because

1. They are great if you want something they have predicted but awful if not
2. They sometimes hide too much technical info that is vital for good performance
3. You cannot easily create fluid, dynamic interfaces or anything "outside the box"
4. You cannot extend them easily
5. You cannot buy/obtain third party components that may suit you
6. They allow mediocre programmers to produce abominations
7. Quality, Price, Time. Pick Two.

Answer 5

There is no Silver Bullet.

In my experience, RAD tools and IDEs remove some of the drudgery of coding, but do little to speed a project up. The major gains in productivity come far earlier in the software development cycle, specifically in defining the nature, size and scope of the problem, creating estimates, and managing risks.

No RAD tool can fix mistakes made early on in the SDLC. In fact, the opposite may occur: developers using those tools can rapidly churn out code against a bad spec. This gives the illusion they are being productive, when in reality the wrong product is being built.

Answer 6

When you decide to use a RAD tool you accept certain sacrifices:

• Intimate knowledge of the code/system is one thing that is very difficult to have when you have generated much of your code or allowed a RAD tool to help.

• Flexibility can be lost; some tools will overrule any man-made changes and regenerate the code as they know how. Personally I believe that these tools should be able to identify when changes have been made by a person and at the very least refuse to run--human changes should always take precedent.

• Often times these tools can help with greenfield development but leave a monstrous amount of code behind to maintain. The claims of 10x to 20x productivity gains are probably measured by lines of code rather than actual finished functionality.

Answer 7

If one already has a team used to certain IDEs, what is the cost of changing that? I mean if I go from Visual Studio 2008 to Clarion or WinDev, is my employer prepared to handle the cost that my ramping up on it will be? There is also the question to my mind of how much do those tools cost and what kinds of guarantees if any can be given that they will do as well as claimed.

Answer 8

You can't trust a RAD tool to write clean, maintainable code. Just see for yourself, use the Visual Studio Designer, drag a datagrid and a database connection and then check the messy code it will generate, if you need to customize something that was not foreseen by the developers of the wizard you will find yourself at a lot of trouble. Now how will you maintain the code? Everything is so messy and tightly coupled.

Answer 9

There is no silver bullet, and claims of 20x etc are worth a grain of salt.

However a big part of it is the perceptions mentioned in the other answers in this thread. They vary from the simple ("can't be true") to the generic ("hard to customize") to the general ("generates messy code"). In order to really compare you need to compare a specific 3GL environment with a specific 4GL environment. Both will have strengths, and weaknesses. Both will likely allow you to create good or bad programs.

The biggest boundary is the skill factor. To get the best from any tool takes time and effort. Not surprisingly users of 4GL's are often the biggest proponents of it, so clearly something about them works for a lot of people. But they usually cost more (to buy), have their own idiosyncrasies and their own strengths and weaknesses. Getting programmers to convert from one environment to another is hard.

In large organizations there's also a lot of existing code to cater for. If you have teams of developers it's hard to make a case for changing a whole team of programmers from one tool to another. Even if you did that, with no existing experienced user in the team, the learning process will be slow and hard. Again this is true regardless of language or environment.

Economics also plays a big part. Companies like the security of being in the main-stream. Even if it costs more. They like the idea that squadrons of programmers are available to write code in the "current" language. Programmers are a commodity that are expected to come and go, and can be replaced when needed. The world is full of C, Java, C# programmers etc. Choosing a "small" language though results in endless political problems, decisions have to be justified and so on. It's the old "no one got fired for buying IBM" syndrome. At the end of the day if money is no object, then there are other considerations that (politically) matter more.

It's no surprise then that most users of products like Clarion and Windev are either independent programmers, or members of very small companies. In these situations daily economics matters more than using the latest tool or padding a CV. Imagine a world where you only get paid when the program ships. Suddenly raw productivity does matter and the most important thing is getting the job done so you can eat.

Since there are a lot more people working as an employee than working for themselves, it's not surprising that most programmers don't need to worry directly about getting paid. If you get your salary no matter what you use, then you might as well go with the flow. There are plenty more jobs out there if this one goes under. So the mainstream tools remain mainstream, and everything else is ignored.

The fact that many of the preconceptions mentioned in other answers here are false doesn't really matter. Perception is everything and in a binary world of right and wrong whatever language you are using now is the "right" one, and the rest are "wrong".

Answer 10

I do belive that the RAD Tools doesnt give u a flexible hand on the code. However if any specific RAD tool is saving 60-70 percent of the development time, worth investing time in it. Now-a-days Skilled developers are at the peak demand. This leads to increase in the attrition ratios. Dependable developers are resigning just for 5/10 % of raise in payscales. This impacts the Development Companies a lot. The one, who has done the most of the development, suddenly leaves. This hits the project completion schedule severely. RAD Tools makes the organization less dependent on the Skilled Developers. Most importantly, most of the Customers are least bothered about WHAT technology you are using for development. They are happy if their Functional Requirements are met.

All said and done, RAD tools will have an increasing demand in the present scenario, where attrition is high. Most of the projects get dragged out of the schedule just because of this dependence. The readers might differ.