Take What You Can Get - From Form Fills

Many times I've started to fill something out online and decided, ugh, not now, or, there is way too many questions here forget it.  Now, let's just say you decide to close your pof account because really there isn't anyone attractive anyway and up pops a survey so you can tell them what you really think.  Half way through this scroller of a survey you decide, over it, just wanted to let them know it sucked and being the good citizen that you are you scroll to the bottom and click submit. What next? An error? Seriously? The error is asking you to fill out the missing questions.  HA! Okay, that will never happen.  What's the lesson here? Take what you can get, from form fills.

As a web designer, put the submit button at the bottom of the page as normal giving the persistant user their reward.  Asynchronously collect the data after each question is answered by the user. Send it to the server and cache it in the session, stuff it in a database, just get the data somewhere so it can be analyzed.  If 20% of the users fill out a third of the questions, 40% fill out half, and the other 40% complete it, then you get 26 point lift simply by changing how you process the data.  Put the most important question first and you're probably looking at a 99% answer rate for that question for anyone that decides to even touch the survey.  This is a no-brainer, and everyone should take what they can get from form fills.

The Art of Database Selection - Part 1

Selecting a database for the job is more of an art than a science.  That is, aside from the obvious misuse of a database for a particular job the selection may not have everything to do with the technology or perceived cost savings in licenses etc.   Take for example a companies decision to switch databases because of impending or increased license costs.  The transition to a new database is typically well planned and the tradeoffs of development changes required to support it are meticulously studied and documented.  What happens when something goes wrong?  Say the performance isn't at the level that was expected.  What if it's not even close?  Teams and company dollars can get swept into managing unforeseen transitional costs which can include support contracts, hardware changes, engineering investigation, testing, and additional changes all of which delay primary goals of the company. Overall, the cost may far outweigh that of staying on the original database solution and absorbing the increased cost of doing business-as-usual.  So when should a team make that leap?  This is part of the art of database selection.  The switch must yield (at minimum) significant benefits or provide a solution that is not available otherwise.

• Solve a computational problem unable to be solved in a reasonable amount of time by the former database.  Caution here, mere performance increases can be challenging to achieve and should be approached with great reserve.
• Provide a radical reduction in costs where the prerequisite should be existing team expertise and experience with 2 or more engineers on the new database including hardware knowledge and DBA skills: ideal hardware configuration for the job, replication, backup strategies, tuning, indexes, etc.
• A change in use-case of the data such as archiving large datasets into an alternative cheaper solution.  In this case non-production critical data is the best candidate.

Databases are an art and sometimes it is best to stick with what you know and other times it's worth the risk.  Just be sure if you are going to take the leap it's going to be worth the possible challenges.  Sounds like life.