Case Studies

I’ve been helping teams and companies succeed by building software for over 20 years. Through my coding and team leadership, I’ve helped many companies get out from a bad place into a much better one in terms of technical debt, business results, team member retention/non-burnout, and more.

Along the way I’ve …

• Re-architected a number of large web application into a microservice and API based architecture
• Lead teams through many successful projects
• Spoken at conferences around the world
• Paid back massive amounts of technical debt (plus interest)
• Built virtualized development environments using Docker
• Rebuilt a javascript based training tool to use websockets
• Modernized large applications
• I have experience with a number of APIs including SalesForce, Stripe, MailChimp, SendGrid, Twilio, PayPal, Vantiv/Litle and many more. I’ve both used existing libraries and written them from scratch.

Please take a look to the right for a selection of the technologies I’ve worked with over the years.

Code is great. Technologies are wonderful to know. Yet, it’s all about applying them to specific client problems, right?

Read on for more…

LCMS Rebuild

Project:

Replace a large custom legacy monolithic LCMS with a modern codebase.

Technical Story:

This code base is over 7 years old, with the business being in operation for 20 years, it had years of ‘throwing everything at the wall to see what sticks’, which lead to a messy architecture.

As a result, the application didn’t end up with a clean design, and while it started out as a model-view-controller architecture, it ended up as procedural spaghetti code. There were many layers of business rules, some classes were thousands of lines long; in some cases, over 10,000 lines long. The application was nearly untestable since the components were tightly coupled. Before starting this project, the unit test code coverage was under 20%.

The LCMS was using an old version of CakePHP that hadn’t been updated for years and as a result, PHP was stuck on version 5.6, so it was likely the whole application would need to be rewritten.

Before starting this project, we laid out a series of code standards and guidelines so we didn’t start going down the path of untestable spaghetti code again.

My role was rearchitect the application and lay the groundwork for each of the modules. We started with the billing module, which was built out as a Laravel microservice. The microservices communicate via APIs and share sessions using Redis.

Training Tool Refactor

Project:

Allows students to practice with a virtual client before sitting down in front of a person.

Within the game, you’re presented with a number of options. In order to diagnose the client, the game allows the user to interview collaborators, and perform assessments on the patient. At the end of the game you’re presented with a score on each section of the game to see if you interviewed the right collaborators, performed the correct assessments, and find the proper diagnosis.

Technical story:

The project was built in PHP, CSS, with a javascript heavy front-end. It lived within an web-based application in the client’s CMS.

When I started to work on the project, it had a lot of broken parts. It had evolved over the years, and had turned into spaghetti code. There wasn’t overarching vision put into aligning the long-term growth of the application with the business’s plans.

After fixing the most urgent bugs, I paid back a lot of technical debt in order to set the application on a path for long-term success. I rearchitected pieces of the application, from the database layer, the PHP application all the way up to the javascript front-end.

The next step was setting up the application for growth. When I came onto the project, the application had hundreds of users. In order for the application to be successful, the game needed to scale to thousands of users per day. With the original architecture, there was no way the game would scale.

Result:

There were a number of considerations:

• It was impossible to tell how many users were in a game at a time
• The game was sending AJAX requests to and from the game to update the score every few minutes, so if the game crashed, then the user lost all of the data since the previous save
• The game had been built with the scoring logic in the front-end code, and in order to make the game more secure, that logic needed to be moved to the back-end. It was even possible to view and change your score using the console meaning the game was inherently insecure.

I refactored the game to use websockets and moved scoring into the back-end. As the user made decisions within the game, the front-end code would send those decisions to the back-end for scoring. Every time a game was scored, the application would save the user’s progress, meaning if the browser crashed, or the user encountered a bug, at most, the user would lose the latest game decision.

After all of these projects, the next step was moving the game out of the client’s LCMS into its own platform. The game now lives on its own website and has had an increase in users by 2000%.