What allows you to write better code?
Claris tries it more like us.
Make a release frequently and include whatever is ready for each release.
Sometimes you work months/years on a feature and eventually you can include it.
MBS does 6 releases per year, Claris now tries 4.
I think a lot is about what process is used.
Does FMI use Agile?
Do FMI's developers read books like Code Complete?
Does FMI use modern software methods like UML modeling?
Is the current FMI code base a mess?
How well is FMI codebase documented?
How well is the bug list maintained?
Why are new features pushed when ultra-basic features like search/replace for scripts and CFs are still missing?
Focusing on time/schedules completely misses the point.
For me, from the outside, it "appears" that FMP is driven solely by the marketing department and most decisions seem to limit choices (deprecated features) and "guide" you to FMS. Forced subscriptions will be another step in that path: cash flow. Few users I know want subscriptions.
Since @MonkeybreadSoftware replied above, not only does MBS have 6 releases per year, but if you write Christian with a problem about his plug-in, he will fix the code and push an update sometimes overnight. That's code quality and customer support. Of course, needing to contact Christian rarely occurs since his code is already solid. 
I realize, J, we don't agree, but that's my two-cents from my experience with other vendors.
Thanks,
Yeah I get it. It was that for a long time. Out of respect for the people, and the vision, I've tried to adapt. I would expect the same respect if I was to change my company name. Obviously it takes time to adapt to a new name. No judgement.
Yeah, I didn't mean any disrespect toward FMI, but really ... "six of one", right?
Since @MonkeybreadSoftware replied above, not only does MBS have 6 releases per year, but if you write Christian with a problem about his plug-in, he will fix the code and push an update sometimes overnight.
This is a much different discussion. The MBS plugin does some great stuff. But that's comparing apples to oranges. The life cycle, end product, target audience, are all vastly different. I'll also add that there are many functions in MBS that are far from perfect. Not a knock toward Christian. I like Christian, and he serves a great segment and fills a need. It's easy to look at the Empire State Building and say it needs a different color paint, and new doors. Much harder to architect your own Empire State Building on your street.
In your mind you seem think that the engineers are stuck in an old development world, or at least that's how your posts sound. I would also say that while the marketing message is about time/schedules, their dev cycle is not. The new process actually removes much of time focus you mention.
If you sit and talk with some of the engineers, Rick, Robert, Srini, you start to get a better idea of the scope they are looking at. While I don't want to say that anything on your list is not a idea, because most of them are very good ideas, they simply aren't all critical to the platform for the target audience. In fact, when you ask Robert why "Feature X" isn't in the platform, he would ask more about WHY you need that feature, and would prefer to make most of them unnecessary, or at least make sure they are implemented in a way that they can be used by the most people for the longest frame of time.
The key thing is that Claris doesn't need to wait till next big release with a new feature, but can just post it when it's ready.
in the old model a new feature must have been ready about 6 months before release to give time for testing and documentation to be done. Now they can publish 4 times a year instead of one time.
How do you know what he thinks or what is in his mind?
I m still trying to understand why a shorter release cycle might improve QA because taking the interval to zero might then lead to perfect code? So where is the sweet spot? When past FMI shortened release cycles did we get improved SW?
I carefully used the word "seems". I only know what he exposes when he posts. I only know what I see from the Claris engineers, and they are very good developers.
"Shorter release cycle" <> "less time to build". In fact, many of the features you are getting in 19 have been being built, or the engine being prepared for the feature for years. It is not a linear build process. There are dozens of features being built simultaneously. As things are ready, they move them main branch and they go into release.
"More frequent releases" means they don't have the same restrictions on when they can release. If a feature is not ready in May, they can release that feature in August, when it's ready. No rushing, not shortcuts, better code.
It doesn't in and by itself, but it signals a totally different approach to handling the software development cycles with a much less artificial "once-a-year-in-May" deadline. Since there are multiple opportunities to release features, there is less pressure to push possibly immature features out at the deadline.
It also shortens the QA cycle, not just the development cycle, so QA is more actively involved sooner and longer.
The proof of the pudding is in the eating so we'll see how it shakes out, and I'm sure there will be growing pains, but what they are doing reflects practices adopted by others that have proven to be successful.
Agreed, you could also just get crappy, buggy code more frequently.
It really depends on the internal software development methods. Agile, UML modeling, having developers step through their code (suggested by MS books like "Debugging the Development Process", running source code checking programs like "Find Bugz" or "PMD" for Java, serious developer peer code reviews, testing approach, testing automated in the IDE during builds, integration testing, checking code for memory leaks, Using GIT, brown bags, etc.
Books like "Debugging The Development Process" assert that it's really up to the developer to find most bugs as only the developer knows the weak parts of his code -- hence the "step through the code" requirement.
In code reviews I've led or been a part of, every developer was expected to have run a source code analysis tool first. If, during the code review, the team found a Cyclomatic complexity code problem, it was going to be a long code review for that developer. If the team found even more serious problems like resource allocation/de-allocation issues, the developer would be dismissed back to his desk.
IMHO, more frequent releases, in and of themselves, is no panacea.
The difference here is information and relationships. Wim and I have closer relationships with the Claris engineering team. So we already know what they do. If Claris wanted to let the world know that, they would...and actually have already mentioned it in a few places, publicly. That would really require listening closely to what they talk about, versus what many people do... just skip past 80% of the information looking for a piece that affects them. The only way to know if information affects you is to hear it.
The only way I can judge it is by all the bugs that have not been fixed and the huge design flaw, still present, in the FMP 16 plist implementation.
And, I would argue that, no, unless you're a developer on the FMI team, you really don't know what they do in any cohesive sense.
Thanks,
We can agree to disagree on that point.
Yep, not unusual for us.
Benjamin, how to you think Josh is working for Claris!?
by always defending Claris against all critics
It's fine. It made me laugh.
Hem...
I like all of you guys and appreciate what each of you bring to the table.
I can even put up with some friendly bickering.
I do not like when people are labeled for their opinions or for trying to bring a balanced view.
Invariably, a lot of clarisplaining occurs in topics like this one. The whole point of discussion threads is to hear other perspectives.
Once you have stated your thoughts, explained them, right to left front to back and up and down, brought a variety of clarifications and pertinent argument regarding the core topic of a thread, consider carefully your communication motivation before adding more stuff.
Chances are what is left in the bag is gratuitous and will not add anything constructive to a conversation.