Yep. I worked at a place that fired almost its entire programming staff because they insisted on using Visual C++ to build a CRUD app, while a team of contractors built a prototype in Visual Basic.
Needless to say, the VB app worked fine and became the product.
If you don't mind, would you explain this more? I don't understand the implications; VB does sound "worse" than Visual C++ for such a job, from an outsider perspective?
> VB does sound "worse" than Visual C++ for such a job
Huh? No no, on the contrary: Straightforward CRUD apps, that's exactly what VB was built for and excels at. Only Delphi is better.
The thing about "Visual" C++ is that it isn't (or at least wasn't, last I looked) really very visual at all. And that sucks for building simple in-house CRUD apps, where the VB / Delphi drag-and-drop UI builder paradigm is a huge productivity multiplier.
No problem. At the time, Visual C++ lacked several important OCX controls that were included with VB, so they had to be hand-coded.
If you were building an application that does little more than populate forms with data from a database and then update the database, VB was totally adequate. The most important part of the job was the DB and query design.
Because a CRUD app doesn't require any serious computing performance from the application, making C++ unnecessary. If another implementation won the race to functional completion, then... needless to say... it was the one to go with.
Today you'd probably just use browser-based UI.
Also if you've spent time in corporate development (rather than a software company), I think this scenario is a common one. If you show management a prototype that works, they're going to ask why we don't just make that the product. And if you don't have a good reason... you don't have a good reason.
Needless to say, the VB app worked fine and became the product.