War Stories - How I saved a company taken hostage by a contractor

You don’t always know what you’re getting yourself into when you accept a job.

You don’t always know what you’re getting yourself into when you accept a job.

This is the story of my first two months at a startup I worked with — let’s call it Transaction Software, Inc. In short, it was a brutal mess.

I’ve written my recollections here. While it’s now been some time since the events occurred, much of the story here is based on notes and logs I had kept as the situation was unfolding.

I’ve changed the names to protect everyone involved. As a disclaimer, everything I write here is from my perspective, my understanding, and entirely my opinion only. To be completely fair, I may be missing pieces of the puzzle that could change my perspective.

Ready for my nightmare? Let’s begin…

The beginning of the strange journey

Elliot, the CEO of Transaction Software, Inc., was looking for a senior front-end developer. He somehow found me on a job board and reached out to me.

During my interview with the CTO, Bob. I dug into the company and its history. I found out about the team , the technology, the problem space, etc.

The engineering team consisted of 2 junior front-end developers and Bob. There were multiple projects in the works, but Bob and the engineering team were currently focused on an effort to upgrade an existing transaction platform written in Ruby on Rails by a previous team and give it a facelift. The projects were already late and running up against some upcoming final deadlines.

The new front-end was written in Ionic 2 / Angular 2, and my first task would be to wire it to the Ruby on Rails system, which I was told had fully-functioning JSON APIs. I would be leading the front-end development efforts as a senior front-end / full-stack developer, guiding the junior developers.

I believed that I had found a good place to work: the technologies were recent, the domain was interesting, and I believed Bob would be someone who could mentor me.

I was wrong.

The truth hits like a freight train

From the very first day it was clear that the amount of progress had been…misrepresented. There was still quite a long ways to go. The Ionic 2 / Angular 2 application I was hired to wire up to the backend turned out to be almost entirely a mock. Much of the data was entirely hard-coded and flows through the pages scripted in a smoke-and-mirrors way. I wasn’t just going to be wiring up the apps, I was essentially going to have to redesign and develop most of the pages and flow from the ground up.

The code quality of the front-ends themselves was very poor. There were 3000 line SCSS files copy-pasted throughout the app. There were repeated functions everywhere. The naming was inconsistent. There were no patterns or libraries. It was messy and unclear.

Questioning authority

The products we were building were intended to be used almost exclusively on the desktop, but for some reason we were building them using mobile technologies. I’m not one to pass up an opportunity to learn and get a “wide lens” of a project, so I asked Bob what the business reasoning behind using Ionic 2 was. Bob replied that he was running an “Ionic 2 / Angular 2 shop”, and that he didn’t want the other engineers confused when they also had to learn how to use Angular 2.

I pressed further —Bob’s reason didn’t make sense to me. Having to learn an entirely new mobile framework on top of an entirely new JS framework is a lot harder than having to just learn just Angular 2. Even the junior developers agreed — they had been struggling with Ionic 2 for quite some time and often spent significant amounts of time trying to do basic things with the framework.

Bob stated that we were using Angular 2 / Ionic 2 was there because the users would be using it on their phones. By creating an app we could provide offline queuing capabilities for the system in case connectivity was lost and that as a hybrid app it would prevent us from having to create both an iOS and an Android version.

Aha! A legitimate business reason…or so it seemed. I thought about the audience and the kind of system we were building — the business case of making it mobile just didn’t add up.

Our system needed always-on online connectivity to verify the validity of transactions and to provide immediate feedback on the result. Ours was not the kind of transaction we could queue and wait several hours to complete. The user had to know at the time of the transaction what the result was. There was no valid business case I could think of for offline queuing capabilities.

Our audience was also not primarily mobile app users. They were users at their desks on large-screen always-online computers, infrequent users, or users visiting the site for the first time and never visiting it again after completing their transaction. A vast majority of them would not be taking the time to download a mobile app to use our system.

So why were we making a mobile app?

The mobile focus leads to technical issues

Bob’s focus on creating a mobile app also influenced the architecture. The app was designed with the intention to load every transaction record on sign-in and store it in memory for offline support — searching, querying, reporting, calculations, etc. This data, along with all the other data in the app, was stored in a singleton reference that was then scattered throughout the entire codebase.

The problem —there‘s several, actually!

Problem 1 —the design was a giant ball of spaghetti

The first problem was the whole design was the question: how should we persist the transactions in an offline-queue capable way like Bob wanted? If we did pursue this direction, we would need some sort of mechanism to sync it sensibly — to keep track of changes, updates, successful and unsuccessful requests, errors, etc. To do so while dealing with a singleton modified and read from in every single file would be a nightmare.