Development Case Study

Iterix Development Case Study

Disclaimer

This case study looks into the design and development of a system that our Founder, Steven Starlin, approached prior to starting Iterix. This project informed how he took on design and development throughout his career which led to our process here at Iterix. The client and custom-developed software names are altered for privacy purposes. The recipient of the software and the technology firm that developed it are no longer affiliated.

Client Context

The client, who will be known throughout this case study as “RestoCorp,” was a corporate entity that owned and managed several restaurants. These restaurants were located all around their area; some were close to the RestoCorp’s corporate office, while others were some distance away.

Restaurants often run “End of Day” reports (or similarly named), to render their financial data for the day. There are many metrics that are too long to include here, but Toast did a great breakdown of the concept (which they call Z-Reports) here. For the corporate office to properly track finances and file taxes, a staff member (named Brittany for this case study) was transferring data from a shared Google Sheet manually into their accounting software. This was time consuming and prone to errors.

RestoCorp outsourced a decent amount of their technology labor so that they could focus on what they do best: restaurant management. Steven worked for the company that was outsourced to, working on a variety of needs such as website development, network management, general user management, and more.

First Contact

RestoCorp had filed a ticket to have a network issue addressed. Steven was assigned the ticket and was working on the issue when Brittany mentioned that they were leaving to grab the End of Day reports.

Once the issue was resolved, Steven approached another staff member (named David for this case study) to ask more about the task that Brittany was working on. David explained the End of Day report, how they had gone about getting their data through a complicated Google Sheet, and and the frustrations of manually keying in every value for each restaurant into the QuickBooks journal entry screen.

Steven mentioned that he had been a software engineer for a few years and figured that there could probably be a way to automated the process a bit and that RestoCorp and Steven’s boss should chat about potential solutions.

The Whole Burrito

Long story short, RestoCorp and Steven’s boss agreed to meet up to solidify the actual needs of the system and the company as a whole. The spreadsheet(s) were shared with Steven and explained how they paired up with the account numbers in each QuickBooks company file.

An old copy of one restaurant’s company file was also given to Steven for development and testing purposes, allowing him to sandbox and alter the existing system without negatively impacting daily business. With these tools in hand, he got to work designing his concept and fleshing out how to make it work.

Steven didn’t have access to a server on which he could build an API, but he could host a database on an existing web server. Additionally, the UI of the software he was making needed to be as simple and familiar as possible. The clients were all using Windows as well. These requirements and restrictions made up “the document” also known as a Software Requirements Specification (SRS). GeeksForGeeks has a good breakdown of this document here.

Battle Plan

While RestoCorp didn’t request any of the design documentation, Steven had made a few documents and flow charts internally for his own reference. Some UI mockups were drawn and a variety of notes scrawled to keep important information in mind. In retrospect, these documents should have been formalized and delivered to the client to received approval for the approach; however, this step wasn’t taken. A lesson that Steven learned during this process of communication and back-and-forth. Iterix now does formalize these same documents and submits them to each client for approval, to ensure proper direction and cohesive efforts from the client and us.

The design resulted in the following approach: There would be two client applications. One would be used by the restaurant staff, one would be used by the corporate staff. On install, the tech would configure which restaurant the software would save information for. Then, the restaurant manager would enter their data, and click a submit button. This click would tell the software to push all of their entered data up to a server along with the date/time of the submission. The next morning, the corporate staff would open their software and the appropriate QuickBooks company file. Once QuickBooks was opened fully, the corporate staff would select the restaurant they wanted to import, the date they wanted to import for (defaulted to the previous day), and click a submit button. The data would then be pulled down from the server, formatted for QuickBooks journal entry consumption, then sent to QuickBooks. Then the corporate staff would enter the journal entry screen and confirm that the data matched and balanced.

Not The Matrix

Steven’s expertise at the time was in .NET, C# (C Sharp), XAML, and relational databases (primarily MySQL). Because of this, and the push to complete the project as soon as possible, he stuck with this tech stack.

First, he built a database schema, which is just a series of tables (in relational databases) that represent some information. This stored all of the data that was needed for journal entries, the restaurant it was for, and the date/time of the submission by the restaurant staff.

Next he built the restaurant application. This allowed an administrator to set the restaurant through a settings screen, then a standard staff member to launch and type in their report values. This screen needed to visually match the spreadsheet they were used to seeing, at least in placement of text boxes. This was a hard requirement of the client. Calculation logic was also implemented to automatically fill in any fields that could be rendered, to limit the amount of typing by the staff member.

The corporate software client was next, and very simple as far as visuals were concerned. Underneath the hood, however, the application pulled the data, formatted it to match the request model that QuickBooks exposed, then submitted it to QuickBooks and waited for a response (either success or an error).

The quality assurance (QA) phase was tackled between Steven and David. The firm Steven worked for was not large enough to have a dedicated QA department or team, so user-acceptance testing was used instead of an internal QA effort. This accomplished the same goals as an internal QA phase because the application was small. Anything larger would necessitate an internal QA phase to avoid interrupting client operations. Once all the data was found to be transferring as needed, it was time to plan a release day.

Cake Day

Steven put together an iterative release plan. First, corporate would receive the installs they needed. Then the first restaurant. Steven would onboard the restaurant managers after it was configured. Once the data was pushing up, and being received by the corporate office, Steven did the same for each other restaurant, verifying that there were no hiccups or hurdles.

Once all restaurants were installed and onboarded, Steven circled back and spoke with the corporate staff, making sure they weren’t running into any issues. Release day, or in this case, release week, was complete and successful.

Groundhog Day

In the following days, weeks, and months, the client requested some new features and updates, and also filed some minor bugs that were addressed. These were either fixed on-the-fly or were packaged together to make new full releases.

For each new feature, the “Not The Matrix” section was followed, re-addressing the initial SRS if the feature was listed there, or a small-scale use case analysis was performed to make sure Steven understood the exact client request.

Bugs are treated similarly, however instead of the SRS being the source of truth for the developer, a filed bug and reproduction steps are followed. Whenever a bug was filed for the RestoCorp applications, Steven read through the ticket and attempted to recreate the issue described in a local environment. If he couldn’t recreate the issue, he would work with the person who submitted the bug to get the context and process that resulted in the error or issue.

After new features and bugs are code-complete and confirmed to be working through the QA process, a small “Cake Day” is planned and executed at an agreed upon (by the development team and the client) time and date.

This can continue for as long as the client and Iterix are willing to continue their affiliation. In the case study’s instance, the support for the software lasted several years, though bugs and new feature requests tapered off heavily after the first few months.

Pages

Disclaimer:
Iterix is a United States-based company, and our primary spoken and written language is US English. All communications, including documentation, consultations, and support, will be conducted in US English.