why doesn't everyone use RAD tools? [closed]

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

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 2

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 3

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.