Several years ago I used to play golf on a consistent basis. My friends and I would head out to the local course, and I would try to strategize every shot. However, my buddy Bill would walk up to the tee on every hole and yell, “Grip it and rip it,” before taking a monstrous backswing and tearing into his top-flite. It was rather amusing while at the same time annoying. It wasn’t just his golfing strategy, but how he operated in every-day life.
I mention this story not to tell you about golf, but it’s more to tell you a parable, I think. You see, as a software developer – a term used loosely these days – I took the same approach. The approach of meticulously trying to figure out what the final product should be and how I can get there. Throughout this process, I’d find myself thinking deep into the architecture, coding pattern, etc. Consequently, not actually coding the project until I realize the looming deadline is near (like tomorrow). However, I came to the conclusion that my bud, Bill, may have had the right approach all along. Maybe sometimes you just have to roll up your sleeves, grip your keyboard and rip into the code; let the application build organically. I’ve come across a few reasons why this method was necessary, and I believe this information can help you on your projects moving forward.
Reasons For Grip It & Rip It Coding
Client Doesn’t Have a Clue
Yes, you read that correctly. There is a subset of potential customers out there that have money to spend on software development but don’t have a clue as to what they want or how they want it. Essentially, they are wanting you (as the expert) to take a handful of fecal matter (known as features), throw it against the wall (known as the end user), and see what sticks (which features their customers will actually use). Sounds rather exciting if you ask me, but I digress. It is very difficult to come up with a plan for these types of projects. It’s the equivalent to telling your waiter, “Surprise Me,” while placing your order at a restaurant.
The key is to gather enough information so you can start on the project. Get into the application’s fundamental goal. Once you have that, you can start prototyping the concept for your client.
For example, a client requested an application that allows users to sign-in to a registration form via mobile devices. Upon registering, the user’s address information would populate a marker on an interactive map to be displayed on the convention floor. The purpose was to display the location of interested customers for convention goers to see in real-time. The client didn’t know what it should look like, how the user would interact with the form, or how the application would display the map.
To begin, I opened up my TextMate and began to build a Google Map container with a simple form that would submit the address to the Google Map API and return the longitude and latitude to which a marker populated at the location. It was as prototypical as it could be; no bells, knobs, and whistles. This was enough for the client to begin providing more detailed feedback as to what they wanted. But, once we know what the client truly wants, what technologies do we use to build it? This leads to my next reason for ripping into the code.
You Don’t Have a Clue
Seriously! Unless you’ve predetermined a specific coding language or stack, the reality is you probably don’t have a clue as to how to get to your end game. If you do, then you’re special like Rain Man. The fun part of development is figuring out how you get to your end game using a multitude of available tools, libraries, frameworks, etc. You can determine what to use just coding out the project using the completed requirements provided by the client.
I accomplished the conclusion of the project by ripping into the code and organically figuring out what would work and what wouldn’t. But there is one more reason you should just start coding.
You Have Too Much of a Clue
Sorry, I was too lazy to come up with a more catchy subtitle. The reality is some of you have more experience in different areas and you know exactly what you need to do to complete a project. You think about the architecture and map it out in your head. You know the stack you want to use, and you put together the list of libraries that you need. If you’re like me, you’ve probably completed the project in your head and already have that feeling of accomplishment, but in reality, you haven’t started. Yes, it’s that feeling of, “I got this!” that paralyzes your progress.
The truth of the matter is there’s a term for people like you and me, and it’s called “Analysis Paralysis.” You’ve planned out everything, but unfortunately, what’s in your head has to make it into your text editor. If you feel yourself over-thinking to the point of overwhelming, just open up your editor and begin coding. Once you begin dumping what’s in your head onto a working document, you’ll be surprised as to how less complicated the project may be. You may not need those libraries you thought about.
Recently, I worked on a project that required a .NET integration from an open source PHP application. I was thinking in my head about all of the pieces I needed in order to perform the integration. In .NET, there’s an MVC Framework configuration that allows you to quickly put together a product with minimal effort. My experience as an API developer pointed me to using this MVC configuration; However, I ran into a game changer. While building the API, I found that the framework has a configuration called Web API 2. This configuration, by default, has a very similar infrastructure to that of Symfony (PHP framework) with entity relationships behind an MVC pattern. Using this configuration saved me a significant amount of time and proved to be a better option to what I initially envisioned. The reality is, doing the work led me to the right path to completing the work. So just do it.
Starting is one of the hardest steps in developing software even when you have paying clients. What we do is complex, and requires us to think in complex ways. But, this gift that we possess gives us the power to create things that only others can imagine. If you find yourself in one of the three scenarios just remember that the key is to “Do It,” and don’t be afraid to “Grip It and Rip It.”