Just Code It: Avoiding Analysis Paralysis
Just Code It: Avoiding Analysis Paralysis
After Facebook’s IPO announcement, Mark Zuckerberg released a photo of his work desk and one thing in particular stood out to me. It was a sign that read, “Stay focused. Keep Shipping.” As a developer, I know that having a philosophy like this is critical because we need a way to stay on track. My mantra is simply, “Just code it.”
Early in my career as a developer, I worked for a start up and sought ways to improve my sense of architecture and design for software. The more experienced guys I worked with were very intelligent people, and they taught me a lot about the value of creating good design patterns. However, they tended to overanalyze which led to a slow down in productivity, which then turned into a general sense of frustration stemming from our lack of progress.
I still didn’t have the answer though, and remained focused on developing various web systems at home, with an end goal of creating a system that was “well coded.”
For all of my efforts, none of these systems, websites, or ideas manifested into anything that was used much by anyone. Later in my career, something struck me. There were a few sites that a particular company had acquired for a fair amount of money.
The shock to me wasn’t in the amount of money, but rather in the fact that the code base wasn’t “perfect.” Users didn’t really care about that kind of stuff, and more importantly, the business that had acquired them didn’t seem to mind either. What was important was that these sites had a good deal of traffic, a sizeable user base and sense of community, as well as the fact that (drum roll please….) they’d found a way to make money.
My view of programming began to change from that point and, in looking back at my career, I realize that I’ve rarely ever seen “the perfect code base.” That doesn’t mean that I don’t value an excellent code base or strive for that when I program. But what you have to realize is that most code bases are kludged together by numerous people with tons of opinions, not enough time, sometimes no requirements and constant change.
If you look at Facebook, for instance, their motto is to “break things and fix things.” The reason behind this being that you break things to learn about a problem, and then fix things really fast once you figure out what that problem is.
However, if you never push something into production, there isn’t anyway to know whether or not something will succeed. In that sense, programming is a science experiment. You start with a hypothesis (your business idea) and you attempt to test it rigorously. If it fails, then you revise your hypothesis and assumptions. But if you don’t ever start with a hypothesis, you’ll never know whether that idea can succeed.
Basically, if you’re only talking about your ideas or always worrying about perfecting all the details before you make a move, then you’re not out doing anything to build and test your ideas, so you aren’t making any money. To build a great product and make money, you have to just get your best work out there and see if it flies. ?
I’m not saying that writing a solid code base isn’t important, it’s just that what has really stood out to me in my work is that it’s important to avoid analysis paralysis. This can sometimes happen when you go for the “perfect code base.” You’re always worried about boundary cases, or maybe having numerous layers of abstraction as opposed to getting the use cases worked out. This over analysis in the beginning stages can cause you to lose focus of the big picture – which should be getting the job done.
Creating a product that is out and launched into the hands of people for them to actually use is the most important thing for a developer (at least to me). The worst thing in the world is the feeling that you’ve spent a ton of time on something that no one uses. And the second worst feeling in the world is spending too much time thinking about a problem and worrying about it while others are getting things done around you.
Bottom line is that we should all spend a little less time thinking about how to make something perfect, and just push out our best work to see how it goes and move from there. Just code it.
by Keith Watanabe, Engineering
image source: www.isgdatabasedevelopment.com/