An approach to software delivery
I’d like to take a moment to document some recent realizations I have made regarding best practice when developing and testing applications. I’m finding that employing Redux and functional programming paradigms at work is really leveling up my software development skills.
These are exciting times!
I created an object-oriented solution that also took advantage of some functional programming practices. It is a black-box service that takes an industry, all of it’s products, and a store as initial arguments. Filtering and sorting actions taken by the user trigger internal methods that act on the data and update the store.
Development of these features took a few weeks. We took the next few months to iron out bugs, uncommunicated or forgotten business logic, and other edge cases that we wanted to address.
I argued against supporting two separate platforms that accomplish the same goal. I argued for making the desktop site responsive to replace and sunset the jQueryMobile application. My arguments won the day.
Bite Squad’s goal at that point was to have a good, solid, manageable software product to support their business. They hired talented, experienced developers to do that. They realized somewhere along the line afterward that the effort was not worth it.
A lot of my time at Bite Squad was spent streamlining the food ordering process on our desktop and mobile websites. The foodify project was one of the most significant development efforts undertaken for desktop.
Since the beginning of time, collateral has been input into the LOS by means of a form that integrates with NADA. Due to the limitations of the NADA bookout service, new and rare cars are generally unacceptable to our system. The solution was to allow manual collateral input. Because we started collateral with NADA, the system was already somewhat complex, though some care was taken to abstract out the bookout type. Still, our solution had to expand upon that abstraction, particularly in back-end persistence and front-end KnockoutJS field bindings.
Snapshots are a fundamental part of how the LOS functions. The problem was that we were treating snapshots like second-class citizens. Time for a refactor.
FinanceGenius hired Agile Velocity to come to the office for a two-day training session to teach the team how to deliver functionality faster and better using agile methodologies. Together, we learned that an agile approach can help software companies like ours by giving more credence to the worker’s voices who know their particular specialty better than those who manage them.
The user story goes something like this: As an admin, I want updates to FinanceGenius LOS admin settings to propagate to the customer-facing LG portal so loans funnel in seamlessly.
The fine folks at *terrible contractor we were using that I will not call out by name* decided that if a lead funneling in from LoanappGenius (LG) did not transmit to a client’s FG LOS correctly, a cron would try again five minutes later. With any application, things can go wrong. With LG, things do go wrong. I start by interpreting mysterious and totally ambiguous error status codes. If I haven’t hooked you by this point, keep reading anyway.
The Military Lending Act was amended in September 2015 to place limits on how high an APR lenders could set for active military personnel. The real difficulty came after realizing the logic surrounding loan products and fees was now lacking. Their inclusion or exclusion affects MAPR values, and thus MLA rules. A refactor was in order because these can be updated in so many ways across the system.
