Is Servoy the environment for me?

Classic Servoy
1

Hi all,

This is a followup to my earlier post, “Would you do it again?” Since then, I’ve continued my research, and spent a few days visiting with Servoy in California, and attending their Servoy 101 class. The folks there are really fantastic and very helpful. A very bright group of folks. I’m impressed with the capabilities of Servoy. People on the forum that I’ve met have been very helpful in sharing their thoughts. I’m a little less impressed with the documentation available as well as the dearth of 3rd party information available, remembering that I’m currently in the Access environment, where there are books available describing every possible thing you could think of to do. Servoy has offered a good deal of help in getting me up to speed, but that’s a concern for me nonetheless.

I’m at the point in my review that I need to take a sort of “devil’s advocate” approach to completing an agreement with them. Servoy does a lot, but it’s not inexpensive, especially for a small company like mine (which is just me right now) and so it’s worth the extra time to try and get things right.

I look at Servoy and what I see is this. It would appear to be great for larger companies. It would appear to be great for consultancies that may build a number of solutions in any given year. Whether it’s right for me as an ISV is the question. As an ISV, my plan is to build a number of products, and then go into a maintenance mode for some time where most development work will be for periodic enhancements, and the majority of time will be spent on marketing and support. That’s a pretty standard product model, and I wonder if that’s what Servoy is really aimed at.

Servoy has great tools for product development. They are clearly in love with the idea of SaaS as the solution for virtually everything. While that’s great and all, I’ve tried to impress on them that where you’ve got a product that is aimed at individual users running on individual PCs, it’s debatable whether they will universally accept the idea of a web-based solution. Many just like the idea of a local app running in a runtime environment as I currently have with my Access app. Don’t get me wrong; I’d love to have everyone on a web-based platform; the income model is more reliable, but I have to deal with the reality of the demographics of my customerbase and potential customers as well. I see a need for a runtime solution for some time to come, even as I provide a web-based solution as well. And yes, I’ve heard the refrain, “SaaS/Web solutions are the wave of the future”. I worked in banking for 35 years. You know what I heard almost as soon as I started working in banking technology? “Paper checks are going away. Electronic payments are the wave of the future”. Are electronic payments the wave of the future? Yes. Have paper checks gone away? Nope, and that’s after 35 years of trying.

An aside::: Do any of you use the Servoy runtime? Thoughts?

So, what do you guys think? Is Servoy the best tool for me? There are no wrong answers, I guess. :-)

Thanks and have a good day.

Ron

2

RonG:
So, what do you guys think? Is Servoy the best tool for me?

Based on what you have told us, and my own experience, I would say YES! :)

Dean Westover
Choices Software, Inc.

3

Hi Ron,

Nice meeting you in LA. You’ll know your customer base better than I but I do find it hard to believe that the vast majority of the customers you describe are not connected to the internet the vast majority of the time they are on their computers. And if they are not on the internet do they need to be connected to your solution? If they are not connected to the internet most of the time and always need to be able at a moment’s notice be connected to your application then you are probably right and they would need the runtime solution. And I don’t really know anything about that in function or in price!

Whatever your customers might say about their internet use, however, that is where the world is moving and a lot faster than electronic payments! How many of your clients will have an ‘always-on’ netbook or iPad in a year or two? Whatever you do, I’d make sure that your solution can also be ‘always-on’ in real time.

John

P.S. I haven’t written a check in 15 years :D

4

hello Ron,

walking the same path as you’re doing (although different product, also small ISV, rewriting solution from FileMaker to Servoy), here’s some fresh feedback:
• for our solution, we need to move to a cross-platform, zero-deployment, optional SaaS technology, so Servoy seems like a good choice.
• the documentation is very poor indeed, especially when you come from backgrounds like Access or FileMaker where excellent manuals are abundantly available
• the learning curve is steep, and the poor documentation does not help to make this path any smoother
• you are suddenly confronted with an avalange of options where again, the documentation does not help (SVN, eclipse, solution explorer, project explorer, etc etc) and it takes a while before you are gaining any speed in development.
• some aspects are really impressive once you get to grips with them (e.g. SVN, the solution model, template CSS, deployment strategies) but on the other hand, I’m beginning to appreciate to what length FileMaker (probably similar with Access) has gone to make this not just a user friendly but also a developer friendly tool. You can really focus on the workflow logic of your solution without being sidetracked by the complexity of the code. It will take a lot more experience to get to that level with Servoy.
• Although technically brilliant in several aspects, it is obvious that Servoy developers rarely build a database solution themselves and it shows. There are many steps that can be polished to reduce the number of keystrokes or automated (although the type-ahead has some great features). Some aspects could be made much more logic from a first-time user point of view. This may be a hard part for Servoy developers as it really needs a fresh look at things and they are too deeply involved already to recognize the issues. The sample solution that is enclosed should be brought up to date and show more best practices or demo features of the latest version of Servoy.

You can get used to anything and learn it’s quirks, and servoy can improve the product endlessly with more brilliant bells and whistles, but to attract more ISV’s or other developers, the Servoy product and documentation could do with some well-written and concise documentation. It is no good pointing to open source documentation for SVN, Eclipse, Java code etc. Of course it’s out there. This is about pointing out the main terms and options in concise chapters (a few pages on SVN, a few pages on Eclipse, Svy-security, Svy-navigation etc), not pointing out all thousands of options. They will come into play eventually when you start feeling the need, but in the beginning, they create confusion more then help.

You have to draw your own conclusion here and it’s up to your business- and long term perspectives what you want to choose, but realize that once you take the plunge, you go in on the deep end right away.
We did it, and there is no turning back. Eventually our product will come out stronger and more future-resistant.

5

HI all,

And thanks for your thoughts. Very helpful, indeed.

John, nice meeting you as well, and thanks for letting me look over your shoulder the day I neglected to bring my laptop along :-). So, you probably go back to the early days of electronic bill pay, when 70% of the “electronic payments” actually ended up with a check being generated. :-) It was a goofy solution back then, but you have to start someplace.

I’m not ready to comment on the state of available resources to learn Servoy, from basic to best practices. At one time in the distant past, I did teach computer technology classes, and did some technical writing, so I think I’m able to make an objective analysis of just how good the Servoy support doc is. I haven’t dug deeply enough into it yet to make an intelligent comment on it. My gut feel is that they assume that the new Servoy developer is not a complete novice, but has worked with some other platform first, but I could be wrong about that. Of course, no matter how much doc there is, I always wish there was more :-).

I got a note from one of the Servoy folks questioning my use of the term “maintenance mode”, so I thought I’d clear that up. To me that just pertains to the part of the product lifecycle after initial development work is complete. For example, Photoshop is in maintenance mode now. They may make significant enhancements with each new release, so there is some new development going on, but they are not re-writing the product. I’m not sure where you draw the line, really. But, I didn’t mean to infer that the system becomes static.

As I said, I’m really impressed with what I see in Servoy. But, using it will increase my overhead compared to my costs with Access right now, so I just need to spend the time to make sure it’s the right solution for me. Your thoughts continue to help me with that, and I appreciate your time in responding to me.

Ron

6

But, using it will increase my overhead compared to my costs with Access right now, so I just need to spend the time to make sure it’s the right solution for me.

Whatever you do there must be a reason why you are looking at an alternative for Access…

So, whatever you decide, chances are that you will have to invest additional money and time anyway. Or am I wrong?

Having said that I think you should forget about Access and compare it to how you would proceed with or re-consider why you started looking for an alternative.

Considering your remarks about Eclipse, there is many books about Eclipse just not (yet) about Servoy for Eclipse.
But (imho) once you understand Eclipse you will start to understand the way Servoy is implemented as well.

7

psijmons:
• Although technically brilliant in several aspects, it is obvious that Servoy developers rarely build a database solution themselves and it shows. There are many steps that can be polished to reduce the number of keystrokes or automated (although the type-ahead has some great features). Some aspects could be made much more logic from a first-time user point of view. This may be a hard part for Servoy developers as it really needs a fresh look at things and they are too deeply involved already to recognize the issues. The sample solution that is enclosed should be brought up to date and show more best practices or demo features of the latest version of Servoy.

which keystrokes can we remove?

Do you have some examples?

8

Hi Marcel,

Thanks for your thoughts. I think that they are right on the money, so to speak. Moving to any alternative platform will involve some investment, and some risk.

I don’t think I said anything about Eclipse; perhaps you are thinking of someone else. Looking back in the forum, I know that there have been people that were unhappy with the move to Eclipse, but I don’t really have an axe to grind on that one. Being as popular as it is, I’m sure that it will be fine.

It’s looking more and more like I’m going to be a Servoy kinda guy real soon :-)

Marcel, it looks like you are in Germany. Two of my kids will be coming there as part of an exchange program in mid-June. Make some nice weather for them, ok? :)

Have a good day.

Ron

9

Just a final update on this topic.

After lengthy discussions, research, and a visit with the Servoy folks in Thousand Oaks, we’ve concluded an agreement that will allow me to do my future development work on the Servoy platform. Thanks to everyone who took the time to respond to my requests along the way. I’m sure that I’ll have more questions, but I look forward to moving my current system to Servoy and taking advantage of the great things that this platform has to offer.

Thanks again and have a good day.

Ron