What Is A Grip It and Rip It Mentality
Several years ago, I used to play golf consistently. 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 daily.
I think I mention this story not to tell you about golf but it’s more to tell you a parable. As a software developer – a term used loosely these days – I took the same approach—meticulously figuring out the final product and how to get there.
Throughout this process, I’d deeply consider the architecture, coding pattern, etc. Consequently, I do not code the project until I realize the deadline is near (like tomorrow). However, I concluded that my bud, Bill, may have had the right approach. Sometimes, you must 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 progress your projects.
Reasons For Grip It & Rip It Coding
The 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 want 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 use).
Sounds rather exciting if you ask me, but I digress. It is challenging to devise a plan for these types of projects. It’s the equivalent of 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 reveal 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. I 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 possible: no bells, knobs, and whistles.
This was enough for the client to provide more detailed feedback on 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 unique, like Rain Man. The fun part of development is figuring out how you get to your end game using many available tools, libraries, frameworks, etc. You can determine what to use just by coding out the project using the completed requirements provided by the client.
Returning to the mentioned project, I started with PHP, my preferred language. I needed to save the data in a database, provide access to the data from multiple platforms and display data in real-time on an interactive map. I had experience building APIs in PHP but digging further into the code, however I realized that real-time interactivity wouldn’t work well in PHP.
This discovery led me to look into NodeJS. However, Node alone doesn’t provide a RESTful-API-like infrastructure or real-time communication to the browser. Therefore, adding ExpressJS and SocketIO helped get my Node closer to that goal.
Additionally, I needed Node to communicate with MySQL, which there’s a library for that. But, piecemealing all of this together seemed to be a bit daunting and allowed for more points of failure. Enter SailsJS. SailsJS is a Node framework that will enable you to build a complete RESTful API in Node with all the components, including RESTful routes, SocketIO, and built-in ORM for database communication. It’s lightweight and allows for extremely rapid development using JavaScript.
Considering SailsJS (Node) as a backend, it only made sense to use JavaScript on the front end, especially since we needed to incorporate SocketIO. Ultimately, we went with AngularJS as it contained libraries for interfacing with Google Maps.
I accomplished the project’s conclusion by ripping into the code and organically figuring out what would work and what wouldn’t. But there is one more reason you should start coding.
You Have Too Much of a Clue
Sorry, I was too lazy to develop 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 can just go ahead and assemble the library list 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, that feeling of “I got this!” paralyzes your progress.
The truth is there’s a term for people like you and me, and it’s called “Analysis Paralysis.” You’ve planned everything, but unfortunately, what’s in your head must make it into your text editor. If you feel over-thinking to the point of overwhelming, open up your editor and begin coding. Once you start dumping what’s in your head onto a working document, you’ll be surprised at how less complicated the project may be. You may not need those libraries you thought about.
I recently worked on a project requiring a .NET integration from an open-source PHP application. I was thinking in my head about all of the pieces I needed to perform the integration. In .NET, an MVC Framework configuration allows you to assemble a product with minimal effort quickly. 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 Symfony (PHP framework) with entity relationships behind an MVC pattern. Using this configuration saved me significant time and proved to be a better option than I initially envisioned. In reality, doing the work led me to the right path to completing the work. So do it.
Do It
Starting is one of the most complex steps in developing software, even when you have to pay clients. What we do is difficult 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, remember that the key is to “Do It,” and don’t be afraid to “Grip It and Rip It.”
This blog was initially posted on Orlando Dev’s Website by our CEO Rey Ortega and can be found here.