Suttle-Straus, Inc.

Suttle-Straus Role

I've had two roles at Suttle-Straus. I started as a Solutions Specialist, which was tier II support covered very broad support for the company's applications and systems, QA testing, minor database administration and minor web development. I was then promoted to Application Developer which included major application development, technical documentation, team leadership, training a new developer and advising on developer and technology policy.

Highlighted Projects

Sales Tool

This was my first solo development project. The CI team identified a lack of tooling for the sales department not knowing all possibilities and limits of certain custom orders (for example materials and options for weatherized outdoor signs and banners). Based on the requirements from the CI team I development a simple WinForms business application with a database backend. The application allowed admin users to generate form definitions and field requirements. This was done with the node tree and nodes could be shared across different configurations (for example the colors options for a material used across two products). Sales users could then search and fill out forms to then generate specs for their customer's quotes. Filled out forms could be saved and versioned. Security used Windows AD to secure connection to the database and who could be in an admin role.

Order Dashboard

Working with a developer and a business analyst we developed a web based dashboard that could be used to track orders from the time they were entered into the website and/or ERP system and update their release, picked, and shipped status. Across several departments there was trouble knowing exactly what orders were coming down the pipe, where the order/items were in the plant, and if all of the items of an order were actually completed.

One of the biggest improvements was in packing and shipping department. Workers were doing a manual process of checking every active order's papers to see if it matched an existing order or if it was the first item of an order. By adding a option to scan paper work's bar codes into the website and to update the status of items workers no longer needed to check every order to see if it needed to be packed. Instead they could monitor a page on the dashboard and see what orders were ready to packed because all of the items had been scanned in.

The frontend was developed with React and Typescript, the backend and API in Asp.Net Core (version 1.x), and we used Entity Frameworks as an ORM. Supplemental back ground programs were coded to help aggregate data from the website and ERP and update the status of orders as orders flowed through external systems.

Overall the web dashboard was a big success and we saw major efficiency gains almost immediately with relatively low effort on the developer side.

Refactor Critical Service

This was a large project. An application was written as a Windows Service to monitor new orders every 10 minutes on the website and if there were new orders process and submit them to the ERP system. The program would also update Magento. However, the source code was old, original developers were no longer there, had some minor and persistent bugs. The application was quickly turning into a legacy system and was hardening to changes, both bug fixes and new features. For previous developers fixing a bug in this application was always playing the classic game of one fix causing more problems else where.

I took on the project of documenting the whole application's flow and understanding some of the complexity under the hood. Compiling all my notes in Markdown we created a nice searchable reference using MkDocs. After this source of (readable) truth was done I took the process of first refactoring the code base. This also included adding automated unit tests and specific integration tests to make sure as much as possible things didn't break when changed.

After refactoring was completed we had a program that had:

  • simplified code
  • documentation inside and out of the source code
  • robust error handling more and having critical errors actually stop order processing
  • no more processing duplicate orders because it started a new thread on the 15 minute mark
  • checking all remote dependencies (databases and APIs) before processing orders leaving them half processed and corrupt
  • automated tests
  • automated deployment scripts
  • no more fear of making changes

The last one was the biggest, and a great lesson I learned. No longer were developers or management scared that touching the code of one our most critical programs would make it break or cause more work. Having any kind of fear or unknown in a programming process makes it so that developers (including myself) be very slow because they feel they need to be very cautious, and may even avoid or even ignore problems in a system. The code should be simple and easy to make changes to, things should be documented so everyone knows what they can do with a system.

cXML in PHP on Magento

This was my last major project at Suttle. One of our customers did purchase orders via Coupa which supported using Punchout via cXML with vendors. The customer wanted to have their users be able to Punchout into the custom B2B website we hosted on Magento. This was a more complex project as it involved doing an SSO style login with the initial Punchout request and having to track the state of the Punchout session till they checked out.

The outcomes of this project were:

  • learned a deeper understanding of Magento 1.x modules and payment modules.
  • extended PHP's XML class to be more like the LINQ XML library in C# for creating very dynamic XML documents.
  • creating a secure API with encryption, secrets, onetime use login links, and using CIDR for IP whitelisting.
  • learning, researching, and testing cXML standards.