Title says it all. It's okay to set aside your humility for a moment here.
tpeters wrote:Maybe this is the wrong question. I want my solutions to be purpose based, and agile, as well as lean, dictates that an app should only perform the functions that are needed, no more. A monster app goes against this model.... thoughts.
Maybe this is the wrong question. I want my solutions to be purpose based, and agile, as well as lean, dictates that an app should only perform the functions that are needed, no more. A monster app goes against this model....
Nice thought, but when your purpose-based, agile, lean app that should only perform the functions that are needed, no more,
meets a dozen needy user-roles in a complex operation with interwoven processes,
your figure and a lot of that dieting go out the window.Kind of like being pregnant with triplets.
It is correct, only that you can tell the client what can be done and what can not be done.
When they convince you and / or you have to do it, even if it is not good for the system, you can always choose the best way so that it does not affect performance.
If all the integrated functionality meets the need
and if it performs better than not having it,
and if you are getting paid to add all that functionality,
then what argument do we have against it?
Perhaps that was a suggestion to create more modular apps that integrate rather than have one massive monster app—which I too would suggest—but integrating modular apps has its own added complexities.
A lot of situations just aren't good candidates for external authentication. Multi-file apps without "ersatz security" become the developer's bane.
That might qualify as the funniest thing I've ever seen. Ever.
I think it's funny that it's flagged as "helpful"
Depends. At some point, refactoring may become necessary in order to keep up performance. Then it is a budgetary choice between a technically ideal and a less ideal way to implement.
In a meeting a few years ago, after much encouragment from us about the approach to a particluar feature the MD said ‘there is no more to be said about this, you are going to do this for me’.
Meeting ended, we did, we got paid for it and took a few more steps towards a monster app.
One of us holds his head in his hands after designing a beautiful styled/themed layout and we return from a client meeting with one button bright pink and a field bright yellow.
UX is not the same for me and you CICT and we call our selves experienced developers. When it comes to customer being stock with what they had 10 years ago is what they have been looking at for a long long time and do not want to change one single thing, just make things better. Pink and yellow is still something we have to fight with
It's not that Johan, it may be down to somethings being critical and sometimes bad design can make something essential stand out.
A good example is the design of car speedometers. Many cars from certain fashionable manufacturers have very small, sporty, stylish speedometers (alongside sporty rev counters). Due to the small scale the amount of movement between say 50mph and 60mph (or kph) is very small, so in a speed limit it is too easy to break the limit. However, a very big (ugly?) single speedometer directly in front of the driver where the scale is much larger makes it much easier to see, for instance, in a 30mph zone whether you're doing 31, 32, 33mph, as would a digital readout rather than a dial.
I guess it depends on whether you are prepared to have an out and out argument with your client, particularly if the person in the meeting happens to be the managing director or owner of the company.
Please remember that we are an international forum with many different cultures. In the UK we meet many 'interesting' individuals.
Elmer Systems CRM Business Suite:
+66.000 field-definitions (most of them with 100-200 repetitions. Most fields created with special tool)
+1200 layouts (1 layout had to be splitted since the max allowed qty of fields on a single layout was exceeded!)
Tables: largest table has 10800 fields
To many TO to count
Records: at a customer one datawarehouse-table had +5.000.000 records. ODBC/Excel couldnt handle it so had to make a workaround with auto-updated data-marts instead.
More than 10 years since it was last possible to print PDF of relation-ship-graph in the major Customers-file - simply to much data for the pdf-creator-software to handle!
Supports multi-language, multi-currency
Works fine from single user on laptops and upwards to hosted solution with multiple portals.
Dont feel it as a monster at all - but perhaps one day if it grows even bigger it might happen! :-)
There may be some more behemoth solutions out there.
I wonder why product ideas for graph manager improvement get only a few votes.
Here are some of the list for the sake of completeness:
Andy says in whole or in part:
Not just in the UK! I’ve lived/worked in quite a few US locales and your statement applies. Now with remote access, I’ve worked internationally. Clients can be 'interesting' wherever they (or you) may be.
Sent from miPhone
LOL, love it Beverley. We have one customer in Finland and we cannot genuinely pronounce the name of their organisation properly and I daren't write here how we phonetically refer to them as it would probably be moderated. They are some of the loveliest people we've worked with and we feel very honoured to be able to work with so many people worldwide from our little Norfolk village surrounded by forest.
Back to the subject of monsters, we've woke up to a (this) Monday morning problem where a customer's file within a multi file solution ballooned from 0.9Gb to 7.5Gb sometime on Friday. With 3 nightly and 2 lunch backups we lost over 40Gb of free storage space and services starting to shut down on the server. Thankfully caught in time, but investigations are ongoing. Sometimes monsters don't take a long time to build.
I won't win an any DB category, but my largest is critical to the operation of the companies where it is used.
Full Role and Attribute based Access Control system, serves in organisations of 100 to 13.000 users, handles more than 1000 roles in some places. It makes it possible for the HR and IT staff to set up and configure a user with minimal effort (type in the data or import it) and get things up and running on the whole IT landscape within minutes. Flexibility reached through combining techniques if Role based access with Attributes to refine accesses within departments.
Includes a way of modelling the business processes, and combining that with the configured roles, determines where there could be Segregation of Duty issues.
The number of tables is relatively low (65, of which 20 cover the real business model), due to a sounds generic underlying model (less is better!!)
Number of scripts is limited also (approx 350) covering all the use cases including administration and auditing.
I was asked to do a two-week discovery on a FileMaker solution that was being replaced with a .NET app in early 2006 (the project was to take 3 months). Once they saw what they were dealing with, the dev shop said, "no way" and this app (with lots of updates along the way) is STILL running their entire business service offering with 50+ users today. The CEO declared it was going way 3 different times in the last 8 years. Yeah...
This is it... roughly. I haven't even touched it in a year. Below is the main file. There are a dozen related files that store historical data not included and the record count last I saw was 7.5 million in active files. One thing to note is that no one has been shepherding it for the last several years, so it's got a tone of legacy stuff that wouldn't exist with a rewrite. I didn't design/architect it, but I maintained and updated it when they needed something for years.
I am an in-house developer who's been with the company since the beginning. I started writing our solution in '97 so I am the sole coder except for a few fields and script steps added by the venerable Todd Geist for connecting to Quickbooks online. The application is now 22 years in the making and has grown in complexity to the point where I am often surprised to discover things I forget I'd done. It's a lot for one person to keep up. (sigh)
Script steps: 34,672
Found a backup from 2005. Pushed it through Metadata Magic into FMP 6.0, then into FMP 11. The DDR from v11 gave me these stats. Points to note:
1) It was built in FMP 4.1, so many of the relationships (and therefore TOs) are doubled up - same relationship in two files; one for each direction.
2) Likewise for any complex scripting: a process that you can do in a single script in FMP 7+ may have subscripts in several files. This pushes the script count up.
Quite a trip down memory lane to open it up again!
By comparison, I haven't thought of my solutions as quite so monstrous, because none of my files by itself looks quite so large. However, when InspectorPro evaluates them all at once (because almost all the apps have common resources files like collections of demographic tables and code translation tables), then the whole collection starts to look rather monstrous. Not sure if this qualifies as monstrous, since the apps people see are independent of each other, despite being related though polygamous relationships.
Well, is big necessarily good?
I'm proud of stuff where I've pushed the boundaries, in small solutions, employing cURL or Java to, for example, build in Machine Learning (or at least interact with sites that provide that extensibility). Biggest, probably 71 tables, 517 relationships, 181 layouts, 1138 value lists, 911 scripts, but I'm always working to reduce that!
It is very true, all the time we work to make our system lighter and faster.
I agree with you, we should applaud our achievements by extending FileMaker's capabilities more than size.
But we all have an old system that has had many adjustments and nowhere else will you recognize your great effort as this forum.
Congratulations on your system!
I have not read a single person suggesting that larger is better. Some projects are, by their nature, larger than others. Sometimes we just look at the monsters that we have created or maintained and hear in our heads a bar full of people in white uniforms during San Diego's Fleet Week.
Bigger is bigger (he writes, ironically following conventions that call for different capitalization). It's something to discuss.
Very true, but I took BuzzardJunction's original question as mere curiosity - if not entertainment? - from the start. And I was curious too. As a single developer sitting between researchers, it's good to have an idea of how normal or extraordinary it is that I am making ... and to know that FMP seems to be coping with the monsters presented so far. Which answers my question like 'What if I go further down this road that I've chosen with my design?' or 'What if suddenly, there are ten times more users,..?' I feel lot more comfortable now. So, thanks for the question BuzzardJunction!!
That's true, even with my solutions not being size monsters, reading others who have such things operating fine adds confidence.
Retrieving data ...