Alan and I spent the first part of the meeting reviewing and going over business plans and budgets. We talked strategy and made a few small decisions. After that, Alan gave me a verbal report of some of his projects and where things are at. He has been doing lots of code centric R & D and exploration and experimentation. What that means is testing how long things take, finding time sinks, and figuring out the best tech for each situation. Here are some of my note:

- Recording hours based off of estimates as compared with real hours spent on sub pieces of a bigger project. Comparing differences.

- Where is the time going and what pulls us (he and others) off of the projects?

- Project scope and project creep - changing over time based on level of development (basically being able to see further down the road and/or opening up new options) - big time sink.

- Doing higher load testing... Instead of testing with 10 to100 records, testing with 100,000 to a million records. Seeing and documenting bottlenecks and process time amounts to run/complete.

- Finding bottlenecks and trying to fix those pieces.

- Pros and Cons to using AJAX (asynchronous JavaScript and XML calls)- Pretty, handy for small things, but hard to debug and non efficient for large reports or queries. We have a current project that will rely heavily on AJAX calls. Testing things out and seeing the pros and cons of the technology.

- Both AJAX and JSON (JavaScript object notation or objects) have pros and cons. Just because they exist and do great, they shouldn't be used for every situration and scenario. Treat them like salt and pepper, great for flavoring but ruin things if used in too big of quantities. Both technologies tend to lend themselves to small, quick transactions or things that are not being pulled and reported on (search capability). Both technologies have their place but both are not a use all silver bullet solution.

- Test driven development is nice but it slows things down quite a bit. It does have its place, but we may not be pushing it as much. Here is an example: Alan was working on a project. The unit test were 3,000+ lines of code to test the actual page of only 1,000 lines of code. Also, each test was so individual that it really didn't test all of the pieces working together in harmony - at least on what he was able to do.

- There are a number of places, especially on the front end, where super complex code may end up creating more bugs and problems than simple copy and paste options. The complexity outweighs the benefits, especially when working with frontend code and normal HTML tags. Keep tags with tags and use more script stuff in the background where things just get called vs showing the output on the frontend.

- Alan is working on some pages that monitor all servers and check for certain corp-specific tables and database updates. He plans on beefing that up and spending more time making sure we have a stable platform and database table/row/column structure.

- We talked about using includes on the CFC's and how that works.