Category: Case Studies

---

Placeholder

---

Placeholder

---

Creek Enterprise is in construction space: they manage multiple construction projects, and each such project can have hundreds of subcontractors submitting estimates and invoices.

To manage invoices and the work done by the subcontractors, Creek uses “Subcontractor Management Tool”, or SMT. The previous version of it was written 8 years ago, and while robust and reliable, it was getting obsolete and in need of a redesign.

My team was approached to do the redesign and rewrite of the existing tool. We chose a different stack – went from Python and SQL to Ruby and MongoDB. We chose to implement the frontend in jQuery, rather than React for this client. We deployed on CenturyLink cloud using lean custom deploy scripts. AWS S3 was used in this stack for object storage.

The project took several months and was completed successfully. It’s in maintenance mode, and my team does rolling feature augmentation and bug fixes.

Since the SMT is performing well in the company, there are plans to license it out to Creek’s peers and companies that need a similar-functioning tool. The architecture of the tool is modular enough that it will make licensing, and even on-premise installation (for audit and security reasons) a breeze.

---

Overview

I consulted for Sturfee in 2016.

Sturfee is an engineering-heavy small startup team developing products in AI space. As data scientists and scientists, the team was is knowledgable about AI and ML, however they lack experience in software development, and knowledge of best practices. Sturfee reached out to me to setup process for building their software, managing environments, codebases and versions, and implement an agile development cycle.

The Problem

• Multiple environments, multiple versions, multiple branches of multiple codebases
• Microservice architecture necessitates a higher degree of infrastructure management than monolithic applications
• Junior team members not following naming conventions
• Hard-coded environmental variable in the codebase

The Stack

• Angular Frontend
• Go microservices
• Node microservices
• Python microservices
• All hosted on AWS

The Solution

It was critical to separate configuration from the codebase. I saw that some variables, such as database names and port numbers, were actually hard-coded into production code, sometimes with if-then statements that got clumsy and unmaintainable extremely rapidly. I modularized the configuration, moved it to separate data containers (json files files),  removed these files from code repositories, and started managing these config files with infra orchestration tool (chef).

I introduced naming conventions and semantic versioning. Version number of every codebase became semantic and readable: just by looking at the branch name (correlated to the version), one is able to see what branch is the latest, and belongs to which proposed release. My methodology is losely based on git flow and semver, however see <this-article> for the complete description of git versioning that I recommend.

• Opscode Chef
• Jenkins
• Semantic Versioning
• Custom build scripts that allow push-button, repeatable & accountable deploy process
• Branching strategy that involved a stable master branch and rolling release branches, plus feature braches that get merged into release branches (that are tracked by the master branch, which is presumably the latest stable).

See the Sturfee Build Pipeline whitepaper for additional information on this project.

---

Wasya Co was retained by Creek Enterprise for development of their next-generation Subcontractor Management Tool (SMT).

Creek Enterprise is an engineering and construction services company. They operate nationally, mostly in the Midwest, building infrastructure and providing other engineering services for their clients. They are headquartered in Tecumseh, MI.

Managing subcontractors to do construction is a challenging task. Each site can have dosens of workers, dosens of jobs, numerous equipment to be tracked, materials, and personel to be accounted for. They have used a python-based solution for the last 10 years, which although adequate has become outdated, and in order for the company to maintain its competitive advantages, the decision was made to write a next-generation management tool. Wasya Co was contracted to do the work.

The team was always very agile, small and fast-moving. I acted as the principal full-stack engineer, and Zach was the designer and a business liason. There were two decisionmakers / stakeholders on the project, making business decisions. The project took about a year to compete.

By the end of the work, the new system has been implemented, with a number of features that were missing in the old system. The new system is flexible enough that new feature requests were easily accomodated and implemented. The deployment process was automated, making iterative development possible. Multiple performance metrics and analytics were implemented, giving the business a good view into both performance of the tool, and performance of projects and subcontractors the work of who the tool facilitates.

Currently, the main development is complete and the project is in maintenance mode: security updates, bugfixes, and occasional feature requests are being done.