Choosing A Dev Tool

I came across an eWEEK article "Armed & Ready" in the August 2008 issue - written by journalist Frank Ohlhorst - and found it to be very interesting.

The article talks about development tools - and how to choose them. He has a look at Servoy and Alpha 5 - as well as a look at customers who are using those tools in the SaaS businesses. One of the most striking things was an outline in a sidebar.

In the article Frank outlines the "7 Criteria For Choosing The Right Tool" - and it sounds like it was custom-designed to describe exactly what Servoy is although the context is from a developer who chose to go with Alpha 5. NOTE: The sections below in italics are my comments and they did not appear in the original article:

1. Commonality: A single development model has to cover both desktop and web users, and support native RDBMS, SQL Server, MySQL and PDF reporting. They didn't mention Sybase, DB2, Oracle, PostgreSQL, etc. that Servoy supports - but hey, you get the idea.
   
   
2. Speed of Development: The tool must have a professional IDE that reduces or eliminates the need for handwritten code. Eclipse is the most-used IDE on the plant - and code samples allow you to get fully working code in a single click.
   
   
3. Performance: The tool has to be on par with desktop-only applications. Of course performance is important - but so is scalability. Any product is "fast" with a single user!
   
   
4. Ease of use: Language tools are intuitive and allow faster development than Visual Basic, PHP or others. Yes - especially these days. You want your tool to be more productive, and not less productive. That's why we've done a direct comparison between Servoy and .NET.
   
   
5. Versatility: There is complete end-user customization of forms, field rules (via XML) and styles (via CSS). In Servoy you can also extend and integrate the environment itself via Java.
   
   
6. Integrity: All processing is centralized There would be no client/server or thick client updates. We totally agree - that's why Servoy's Web Client processing is all done on the server side - maximum performance, maximum security, maximum concurrency.
   
   
7. Functionality: Extensive use of standard library functions cover just about anything, including instance XML DOM manipulation, instead of having to use third-party libraries or extensive custom development. Servoy has it - CHECK!

While I was reading the quotes from the developers using Alpha 5, I could have SWORN they were talking about Servoy! So, I had to check it out for myself.

I went up to the Alpha 5 site and checked out their video library. After watching about a dozen or so movies - I couldn't help but come away with a some thoughts:

1. Dialog boxes... sorry Wizards... sorry "Genies"... are nice - the first time you do something - but I would absolutely stick a pencil in my eye if I had to go through that many dialogs every time I wanted to do anything;
   
   
2. They have some "interesting ways" of doing common tasks (some good and some awful);
   
   
3. If the dialogs are going to just generate code on the back end - then just generate code. Don't try to create dialog boxes that have every single possible permutation of things that you can do in two lines of code with parameters;
   
   
4. You still have a proprietary DATABASE? WTF? This is 2008!
   
   
5. "Active Link Tables" - or copying the schema of a SQL table in your own proprietary database and then doing "silent" SQL calls (a la FileMaker 9) seems like MUCH more work, setup and maintenance than just acting directly against the table or view;
   
   
6. Ummm... got a Mac or Linux or Solaris version? Anybody?

Ah well, that's just my opinion. I'm sure that if you've used it for years that you're used to the complex interface and the literally hundreds of options, links, states, modes, control panels, and all the other stuff that they've put in there to try to make it more approachable.

I guess if you're going up against developers who are using other kinds of desktop databases - then that might be a good approach.

The bottom line is - use the right tool for the job - and use one that will help you be MORE productive, accomplish more in less lines of code, have a single development paradigm for both web and client/server apps - and one that is based on open standards and links to any (and every) standard SQL database on the planet.

Ummm.... that would be Servoy, in case you missed the reference...

The Coming Together of Web and Desktop Apps

Today Frank Ohlhorst did a review of Servoy for eWeek's Channel Insider. It was really a nice review - and it got me thinking (rare, I know)... in the future how far will the line blur between web and desktop applications?

I think for the short term - there's a lot of noise about where vendors *think* it should go. The market and the press has been announcing new paradigms and competing announcements for the-same-but-different tools to try to get developers to adopt their "new" platform.

There is so much confusion and noise out there about all the new technologies that I think we're getting away from the real question - what are real life developers doing to create real life applications (both web and desktop) that real users actually use?

I think there are as many answers out there as there are individual developers. Some are still using the "old school" 4GL products (Access, Alpha 5, FileMaker, FoxPro, Magic, Oracle Forms, PowerBuilder, Progress, etc.) and some are using 3GL languages and products (Basic, C, C++, C#, Cobol, Delphi, Java, .NET, RealBasic, VB, etc.) - because that's what they know and are comfortable with (or it's been dictated to them that they use those tools).

Some have turned to the "new" platform as a service (PaaS) offerings or virtual (100% cloud-based) offerings like Bungee, CogHead, Gears, Force.com, QuickBase, etc. opting for both the development and deployment models to be 100% online.

Yet others are jumping on the connected/disconnected (and "Rich Internet Application" - RIA) bandwagon with AIR, Gears, Flex/Flash, OpenLaszlo, and Silverlight.

Not to mention the mobile platforms that are coming out with their own flavors of operating systems (Android, iPhone, Symbian, etc.) that also may or may not have their own particular languages (Objective C, Xcode, etc.).

Ummmm.... yeah. And the list goes on and on and on and on. I personally think it will get even more "muddy" before it gets more clear. You can bet that there are zealots for each of the various approaches and tools and platforms. There are an equal number of detractors as well.

Everyone's got an opinion. But is anyone getting any work done?

I mean, it's all well and good to take a look at all the various technologies that are coming out - they're all trying to do the same thing: help developers develop stuff that end users will find engaging so that they be more productive - and actually get stuff done.

In my book - any tool that will allow you to reach that objective is the best tool to use.

It's not a one-size-fits-all world - and there will never be a one-size-fits-all language, tool, protocol or way of doing business.

Having said that - it's been my experience that end users, project stakeholders, CIO's and CEO's don't really give a rat's ass what the technology is - as long as it meets the business goals, and comes in on-time and on-budget.

And, in my opinion, THAT'S the problem. These tools are so complex, there is so much code to write, there are so many protocols to support, end user's expectations of how applications are "supposed" to behave are changing so rapidly - it's really difficult to find a tool that will help you be both productive ("get the job done") and easy-to-use ("get the job done on time") and flexible ("meet ever-changing business goals") - it's enough to drive developers nuts.

Couple that with the end-user requirements of a rich browser application, and/or a client/server application and/or a disconnected application that synchronizes, and now the water is even more murky.

Let's not even go down the road of the changing business climate of offering software as a service (SaaS) and the nacient platform as a service (PaaS) initiatives to put stuff in the "cloud" while at the same time coupled with ISV business model of selling on premises licenses...

It's for those reasons that I really like Frank's article on Servoy. Servoy is a tool that will give you the best of all worlds: standards-based, JavaScript/Java power, easy Eclipse-based RAD design - but it also is flexible enough to be extensible (Java), and allow you to sell it as an on premises solution, a SaaS solution (in the cloud with or without PaaS) - deploy as client/server and/or browser (100% HTML/CSS) and/or "headless" client (for use by web services, other Java applications or JSP) - while at the same time doing it ALL from ONE code base.

For my money - that's the best application to use. One that allows you to leverage what you know and handles all the code that's behind the scenes. Who wants to code things like connection pooling, data broadcasting, manage client state, write 1,000,00 SQL queries, etc.?

The part that developers need to develop is less about infrastructure and more about the "inside of the window." It's like an iceberg - 80% of the typical application's code is below the water line: the end user never sees it. They only see the 20% of the code on top.

If you can concentrate on the 20% of the functionality that the user interacts with - and have the other 80% handled for you automatically (but still have the flexibility to monkey with it if you want/have to) - you can finally be productive and actually DELIVER a secure client/server/web/offline application on time and on budget that end users will actually use.

Now that's bringing the desktop and web applications together in a way that makes sense.