3 Lessons Learned from the Death of My Company – Medium

It happened on an cold, rainy afternoon in late autumn of 2010. I will never forget that day. The decision I made that day left a deep mark on my soul that will surely never fade away completely. It was the right decision, but a bit too late for "right decisions." Damage done.

In the late 2000's, just before startups became "cool", a friend and I had an idea for a neighborhood-based social network. We were sure it would be a huge hit and make a lasting social impact, especially in America's neighborhoods. We decided to invest in the idea and devote ourselves to development. Ben, my partner, handled the business side of everything. I handled the tech and development. Ben and I were a great team.

Go Speed Racer, Go!

Over the course of 12 months, we developed an amazing amount of functionality. Ben and I were generating ideas left and right. A team of developers and I set out to turn ideas into code. We spent a lot of time on news aggregation systems that would go out to different sources and collect local news. We created a system that allowed neighbors to band together and petition government officials. We created a crime mapping solution to alert neighbors when bad people were doing bad things. We spent time on messaging, chat, groups, profiles, coupons, advertisements, and an impressive list of features, all meant to make people fall in love with our product. Demos were impressive, especially when an idea came up during a demo and a developer had it implemented before the demo was over! We were making progress like a speeding freight train. Amazing times.

We started to get some attention from outside investors and large tech companies like Microsoft, AOL, and Yahoo. That brush with "fate" stoked our fire and made us walk a little taller. We added some more features to the product and did some more demos. We also added some "shareholders" to the company to help us get to the next level. Feeling great.

Quicksand Rising

And then we started slowing down. New features took longer to implement. New developers took longer to spin up. The bug list was growing faster than we could patch. Code that went in super fast took 10 times longer to modify, breaking countless disparate parts of the system along the way. It was like trying to run in quicksand. Our once nimble team had been reduced to a pack of sad sloths. After 6 months of death march, we made the decision to start over with a new code base and new technology.

And just like that, we were fast again! That's how it felt to the developers, at least. We were given the chance to "get it right this time." But 6 months into our new shiny code base, we started to feel the quicksand rising again. What was it we were doing here again? What are we trying to build? Who is this for, anyways? We had lost our way.

The idea that once woke me up early in the morning and fueled my 18-hour coding binges got lost somewhere along the way. My passion for my company and what we were building had been replaced with a feeling of helplessness, anxiety, and despair. So, on a cold, rainy afternoon in late autumn of 2010, I finally threw up my hands and stopped coding. Development stopped, meetings stopped, momentum bottomed out, and our company drowned mid-river.

In 2010, according to the Standish Group's 2011 Chaos Report, "37% of all projects [succeeded] (delivered on time, on budget, with required features and functions)." I didn't realize it at the time, but I and my company had just become a permanent part of the 63% that fail.

Lessons Learned

Release Something — Did I ever say anything about our users? Nope, because we had none. We just kept on cranking out feature after feature without regard for the people who could be using our product. Don't get me wrong. We were definitely focused on our users, working hard to develop and perfect our functionality so that the product would absolutely delight the neighborhood-dwellers of the United States. We kept telling ourselves that the 30 some odd features we had weren't enough. Therefore, we must keep developing. In our quest for the proverbial kitchen sink, we never released. If we had known what we know now, we would have developed the most compelling/valuable features first and then released them for use. Then, we would have listened to the feedback from our users to make sure we were building the right pieces and solving the right problems. Even if it was incomplete, it would have made the difference between life and death for our company if we had just released something.

Fast Code is not Good Code — At the beginning of each phase of development, we were hauling tail! Coding and producing at a rapid pace is a rush that's hard to describe for non-programmers. But even non-technical folks enjoy seeing features flying out the door at breakneck speeds. The truth is, though, that fast code is not necessarily good code. Our fast code, over time, ended up paralyzing our development team. That's not fast at all! Knowing what I know now, we would have used proven engineering techniques and practices to ensure high quality across the board and over time. We would have worked in tight collaboration with one another and with the business. We would have sacrificed our hubris and accepted strong code instead of speed. We would have listened to experts like Robert Martin and Kent Beck when they tell us that a clean, maintainable code base makes us faster in the end and protects the project from failure. Fast code is great for prototypes and throw away ad campaigns on Facebook, but it's can be dangerous for anything else. Fast code is not always good code and can lead to the demise of your project (or your company).

Developers Should Not Be SME's—For this next one, I take full responsibility. I never intentionally made myself into a subject matter expert for our project. It just happened. Yes, programmers are experts. But when a programmer is an expert over a section of code, a piece of functionality or a system, he becomes so important that he is irreplaceable. My knowledge of the entire system made me too important to lose. That feeling of importance is hard to resist. I can say that I never maliciously accepted so much importance, but I can also say I didn't turn it away. There were several times when I felt like I wanted to get away from the project, especially as things started to slow down and I felt frustrated. But I realized that, if I left, the project would come to an end. And when I finally left, it did. If I could go back in time, I would've shared my knowledge with other developers. I would have encouraged techniques like pair programming to prevent myself from becoming a silo of knowledge. Still, I might have left the project, but at least my departure wouldn't have meant the downfall of the company.

This Time We'll Get It Right!

My favorite line from "Batman Begins" is when Thomas Wayne asked his son, "Why do we fall, Bruce?" Bruce answered, "So we can learn to pick ourselves up." I like success just like you. But life comes with this guarantee: WE WILL FALL. We will not always be successful, and we may even hurt ourselves or others on the way to failure. But you and I will not stay down. We will get up, brush ourselves off, and forge ahead with the determination to get it right the next time. I hope the lessons I learned from my own failures can serve to help you lead your own software development projects to long-term success.

And if you need a development team who has already learned from their mistakes and is poised to build a high-quality, successful software project, you should check out my most recent venture, Acklen Avenue!