To start with, imho there's a psychological aspect to consider. Pure marketing, but true: a user facing the version 24.15v16 of a product is not a happy face, whereas the same user presented with the new and shining version Pro 1.4v2 feels better, because "Pro" changes the context, 1.4 not being 1.0 but much more adds the feeling of (recent) progress and v2 adds the idea of tested, corrected and stable. Beyond these funny considerations, keep in mind that your users interact with internet on a daily basis, get free apps on their mobiles, and these things condition their expectations. OTOH, behind the scenes, if coming from FM v6 you have for sure room for improving at architecture level, less relationships and more SQL, just to name one, which will make it easier for you, too, when having to change/fix things.
To sum it up quickly, there are moments in the life of your product when you have to decide if starting from scratch and building it all again (keeping an eye on compatibility, importing old data etc of course) is a good idea or not. It also depends on who and how many your clients are, how easily would they adapt to new paradigms (age? just to name one criteria), and last but not least, resources spent vs potential retribution incoming.
It is completely wrong to not think about it. Whether it's right or tight to do it is up to you. My 2 cents.
That's fine. You don't need to start over
Most of the solutions I work with were started in FileMaker 3, 4, or 5, and updated each time. It works
> I've been using FileMaker since pre version 6, and created a solution that I've been updating all along, incorporating features as they became available. Is there an argument for creating a new solution when there's a significant upgrade? Are there any drawbacks to doing what I've been doing?
The argument for creating the solution is basically this:
Has the solution reached the point that maintaining it becomes more of a headache than starting over would be? If so, then a rebuild becomes beneficial.
Other angles to consider:
1) Incorporation of new technologies.
2) Your increased skills over the years (because none of us would do things the way we did 15 or 20 years ago).
3) Does incorporating a new method mean more work than starting over would be?
But no, there's nothing inherently wrong with keeping an old solution that's been upgraded over time.
The answer is definitely No and Yes
Some arguments for rewriting in full or at least some parts of you solution
- FileMaker up until 2.1
Generation 2 (introduced with FileMaker 3)
- From 2->3: The answer is yes. FileMaker 3 got the new relational model which ment that the entire data model changes. FileMaker 2 solutions build in FileMaker 2 was still compatible when used within FileMaker 3.
FileMaker 3-4-4.1-5-5.5.6 shared the same data model. One table per file and relations only 1 level deep. The changes form version to version was the addition of new features, web and xml technology etc. etc. No changes to the date model.
Generation 3 (introduced with FileMaker 7)
- From 3-4-5-6->7: The answer is probably yes. With FileMaker 7 we got a completely changed relational model with deep relations. And now one file can have unlimited number of tables. Thereby the old structure with one table per file and withs scripts branching through subscripts from file to fille was utterly outdated. The file format for FileMaker 7-8-9-10-11 is .fp7
Generation 3.1 or 4, discussion
You can probably argue that so many changes was done to the layout model with the CSS based themes and styles in 12 and 13 and with the many completely rewritten parts of FileMaker and especially FileMaker Server and with WebDirect so that it is a new generation.
But the relational model is still the same.
You should consider building a theme supporting your solution and then implement this on all layouts. There are many reasons to do so, performance being one of them. But if you solution is a good and thought through FileMaker .fp7 solution there will probably not be reason to rewrite it in full.
You could argue that the changes to FileMaker 12-13 (.fmp12) compared to .fp7 are substantial and moving the platform into the future and that the new versions of FileMaker will bechanging the way FileMaker is deployed and used. And I agree. But it is still the same very strong and comprehensive data model and therefore you will probably not have to rewrite your solutions ... unless they need to be rewritten for other reasons.
Some reasons for not rewriting, at least for now
From FMP 6 to 7-13. If your FileMaker Pro 6 solution was working OK under FileMaker 6, and if you are not going go continue development for now, you can consider use it as is after converting it. At least until you need to continue development. You may have to solve som minor problems because of the different way windows are handled. And maybe som other minor problems, but many/most FileMaker 6 solutions will work fine as fp7 of fmp12 solutions.
Going from fp7 to fmp12: Will you have to go through all layouts and implement themes?
If you are not going to make a lot of layout changes and new layout just now, then you can probably postpone updating the layouts. Test the solution: Does it cause performance problems due to not utilizing the new layout model?
At the end
A large, many file FileMaker 6 (fp5) solution should probably be rewritten if it is going to me used for years to come and if the solution is strategic for your company. Going from fp7 to fmp12 will probably not need to be rewritten, but at the end you will have to go trough all the layouts and implement themes and styles all the way through.
What do you say to this?
Carsten Levin wrote:
What do you say to this?
I say UX - popovers. Just one thing among many that FM gave us recently - but made me rethink everything and all. Because UX counts for me more than the rest, it's what they obtain. They, the wallet people, the ones that pay and deserve to get.
Hi Siplus Popovers are great, but they are design elements that like tabs work within the context. And are able to display a more details within the same real estate. A truly great feature. But they does in no way change the structure and can be implemented within any solution without having to rebuild the solution, and I understood that this was the question here?
for me, solution = structure + interface. Rebuilding the interface won't touch the main skeleton (a clients to invoices relationship will remain the way it was in Nashoba FM) but can and will touch all the relationships created for the sake of displaying data. Some will be useless, some other might be born. Unfortunately the ratio of raw, pure data storage fields to fields meant to calculate and represent the data is normally quite low, so I think we have to specify better what we mean by rebuild.
Thanks for the great discussion folks. All of the above is what I had been thinking, and of course, when it ain't broke… . I have done both, kept an older solution, usually simpler, and updated as FMP updated, and re-created solutions from scratch as newer features have appeared. The bottom line is structure and functionality.
Thanks a lot!
All the best,
JB, The Creative One
A couple of terms apply to all the good advice here: technical debt and bit rot, or software rot.
To answer your original question it's also worth doing a review of the system from an organizational goals perspective. What are the current goals of the organization that the system supports? What features in the system support goals that are no longer relevant? Good software is like bonsai - pruning and shaping is as important as expanding capabilities. No one wants to find their solution branded as a "legacy system".