Monday, April 10, 2006

How "Big" Is A System?

Recently I was asked by a consultant to estimate how "big / complex" a proposed system would be, compared to some of our others. This prompted an intriguing debate - how can you actually define how "big / complex" a system is?

Number of CF files? That depends on the methodology used - a Fusebox app is going to have more files than a page-based one.

Size of CF code on disk? Again, not really a reliable measure - more code might just mean less efficient programming ;)

Anyway, we ended up doing a couple of quick reg-ex extended searches through our codebases on two of our flagship systems - the NIMHE / CSIP Knowledge Community, and the Big Project, which I would link to, but I'm not even allowed to NAME it yet, never mind tell you where it is - to get some counts.

The KC has been incrementally developed for about three years, and the Big Project was started in February this year. Both have a Fusebox front-end with a CFC-based object model at the back-end, and I found it interesting to compare the two :

ProjectDSP filesCustom TagsFuseactionsCFCsDB Tables
Big Project1052617420050

Now, in our own heads, the two systems "feel" more-or-less the same level of complexity, but a couple of things leap out of those figures straight away -

* The KC has a colossal 679 fuseactions, which it services with 98 CFCs.
* The Big Project only has 174 fuseactions, but twice as many CFCs (200) and 26 custom tags

This is a reflection not only of an evolving methodology - on the Big Project we've moved our object model from an item/itemmanager model to a bean/controller/DAO/gateway model - but also of evolving technology.

Thanks to a liberal spattering of Creamy AJAX Goodness™, we've been able to handle things like tagging of items almost entirely within a custom tag, plus a couple of very simple fuseactions to handle the AJAX requests. You can add and delete tags without having to refresh the whole page, and as a consequence, the app feels much more responsive. This is one of the areas where AJAX can really help - provided, of course, that you're not going mad and doing whizz-bang stuff just for the sake of it.

Also, we took the decision this time round that we were going to encapsulate as much of the business logic as possible - permissions checking, etc - within the controller methods, and the bean-with-private-data model enabled us to do a lot of the core validation within the bean itself. This has the double bonus of ensuring that there's no way that invalid data can get into the database** and it removes a lot of the tedious checking code from the front-end fbx_switch files.

I'll blog more about the approach we used and the framework we worked out in a separate post - it took a bit of time and discipline to make the switch over, but we're very very glad we did.

**well, OK, no easy way... you can never make anything completely un-hackable, all you can hope to do is make it not-worth-the-effort :)


barry.b said...

you missed something in the calculation: numbers of database tables. You;ll find bigger systems have more db tables.

In fact I use a simpler method:
database tables * distinct presentation views (pages).

even if something has only a few tables - if it has heaps of different presentations of that data it's a big system.

how that get coded up really depends on the system. so that's why I don't take into account fuse actions or CFC's (or weight them less).

I sometimes add a weighting for performance/scalability because a "small" system that has a million page hits a day has a few more "tricks" than a system with 20 hits a day...

just 2c worth.

Alistair Davidson said...

Thanks Barry - I like the idea of db tables * presentation views, but again that can turn out hard to measure in a complex FB app where you try to modularise everything into re-usable templates... that's how we ended up at the Fuseaction count.

Will Spurgeon said...

I look forward to your comments about your final architecture, noting that you stayed with Fusebox for now and didn't switch to Model-Glue or Mach-II for the controller.

Also wondering where I can find more info on the "bean/controller/DAO/gateway" approach and if you feel like it would be overkill for smaller projects (ie, 75 tables or less).