For a little over a year, FinanceGenius hired a contractor to build LoanappGenius, a consumer-facing application that would allow lenders to set up forms and funnel loan applications directly from potential consumers to their FG LOS instance. There really isn’t any great way to say this, so I won’t beat around the bush:
That contractor was insane.
And they were calling from inside the house. Hah, no, just kidding. Not about the insane part. Why else would you take a perfectly good framework like Laravel and then have:
- 300+ line controller methods with multiple raw SQL queries, loops, and conditionals everywhere
- a 786-line BuildXML method (wait, huh? …yes)
- no comments or 4 times more comments than code with no middle ground
- default values for personal fields such as ‘123456789’ for an SSN instead of proper validation
- overly complicated SQL and nested loops to simply map admin form fields and user input arrays
A simple goal to fix the mapping of a few fields in the client-side application to properly transmit through a non-trivial API network essentially became a sprint-long debug session. We successfully fixed some terrible wrongs using a light touch. The contractor had worked outside of the code repository through some combination of changing files on their staging server directly, using DB hardcodes, and configuring the server in some weird and wonderful way. After someone at FG verified their work, the staging server was decommissioned leaving us no record of what it took to make the site work.
The code was unstable at best. The DB was basically a place where the contractor put their boogers. It did not travel well. I was able to isolate most of the potential issues we’d face deploying the site by setting up and debugging the staging site. I then created a DB sanitation script to test the consumer to FG flow using data as close to production as possible. Because of that and a couple of months worth of headaches, we were able to successfully deploy to production within a few hours.