Working From the Ground Up

Problem

My company was a bulletin board company like Craigslist, only in other countries instead of the United States. They started the business out by building all of these websites.

Our demographic was developing countries, way before smartphones and mobile apps were a common thing. The process was much more complicated than anybody had expected. This experience was when I really started to internalize some of the problems typically associated with long-running projects.

Actions taken

The project ended up taking much longer than expected. During the project, the business had decided to acquire another company, which added an additional layer to the situation. A bunch of new developers came in along with it. Because of this sudden influx of new developers, product owners, and designers, the project turned into a total recreation of the product.

Previously, the company had considered outsourcing the project to a local firm. After the acquisition, however, we had a ton of new talent already on staff. We talked about building an Android app and one for iOS, as well. We rewrote the entire business stack.

This was far from our intention when we first got started, but that’s what it ended up becoming. It was really, really complicated. Initially, we thought that we could turn the project around within a single quarter. Ten months later, and we were finally there.

Some weeks, we had to work fifteen-hour days, including weekends. It was brutal. During this entire time, the business was putting one hundred percent of its resources into developing this new thing. During this entire time, there has been no new work happening with the rest of the company. Everything else was on pause.

The longer that this went on, the further that they had gotten from their original goals. That created this pressure cooker, but, eventually, it finished, but only after a great amount of suffering and extreme dedication. This was on the part of the developers, everybody involved.

The result? We ended up decommissioning all of the old stuff. We did a hot migration from the old system to the new system. We launched the new website and the new apps, the new architecture and everything. It was like the flip of a switch. The new architecture is still in place, even today.

Lessons learned

• It is imperative for a business to have these things established and accounted for. If businesses want to build apps or websites, they need to have some sort of consideration for the future. This includes future technical choices, design decisions, and everything else. Sometimes, you may design yourself into a corner that you can’t get yourself out of. This story is one example of that. We literally just had to start over from scratch. You will not be able to overcome the weight of those previous choices.
• Leading the technical team through this whole process involved dealing with all of the technical issues that led to this situation. I then specifically designed them out of the future system. There was no way that I ever wanted anybody to ever have to go through this again.
• We wanted to build a version of this project that would last for years because the business wanted to last for years. It was our responsibility as engineers to take those things into consideration. The Product team needed something that could be built upon and managed over time. As the business grows, the software that you develop should grow with it. Before this project, our software was more of a constraint on the business.