Ionrock Dot Org

My Weblog

Business Logic, Boring Code and Personal Perspective

Today we had a code review of some code. We do this in hopes of exposing some code someone else is working and getting a better vision of what others apps do, their design patterns and specifics that would help us contribute if (when) the need arises. One theme I’ve noticed is that most comments that are offered have little to do with the business logic. Not many folks care about some algorithm or function. This is most likely because you are not going to gain a deep enough understanding within the course of an hour to have a strong opinion on some algorithm being used for a project. The result is that business logic is boring.

I wouldn’t say that it is intrinsically boring, but rather that unless you are invested it is boring. Art and music can both have similar effects. You hear a song or see a painting and think it is simple and anyone could do it. Yet, to those well versed in the genre or style can quickly attest that the artist has in fact introduced a new revolution within the scene.

It applies to other areas as well. Take the car you drive. If you are a car person you might really like charger over a camero, but to a mechanic, who has a deeper understanding of the engines, they are just two shades of the same thing. Hopefully this example is not completely lost behind my massive lack of knowledge in cars.

Going back to the code review though, it is interesting to see what portions of the code did prompt comments. It was almost always opinions on things like library choice and code patterns. More generally, I might categorize these as framework-type opinions. This is interesting because many projects at my job to use different frameworks that traditionally are dependent on the preference of the author. The result being that these code reviews often end up being an exercise in a personal perspective on code rather than an exploration into the business logic and the project’s meat.

If this sounds like something is broken, then I agree. If it doesn’t then let me tell you why it is an indicator that something is broken.

When a team of developers all use their personal perspective to code a few different things happen. The first is that emotions become tied to the code. Code is not emotional. It is logical through and through. The second thing that happens with personal perspectives is a lack of instinct. When you approach another project to fix something or run the tests and it is an exercise in teasing apart config files and debugging, then you’re coding with personal perspectives instead of a standard. Your goal should be to have a code base where anyone familiar with one application can automatically do things like run tests, start servers/daemons, add logging (print statements) and deploy to production any other application. This kind of familiarity and standard allows for instincts to develop. Instead of wrestling with understanding the meta data (testing, deployment, debugging), people working on the code can focus on the purpose of the application. They have a bug report and it is a matter of grepping the source, adding some logging to do some introspection and fixing the bug instead of understanding the different test runner or build script that is used to create a package.

I’m not saying that people should code like robots or anything else that sounds extreme and stale. Rather, I’m pointing out that your personal preferences should take a back seat to the goals of the code. If an application is going to be thrown away, then sure, rigging up your own test harness to do something is totally fine. The start up with two developers shouldn’t feel bad they haven’t settled on a test framework or deployment strategy that considers applications written outside of their core language. But if you are debugging code someone else wrote, then you have hit the point where you should have some standards that help move the code to a higher level among developers. We use langauges like Python and Ruby (and even Java) because it hides a lot of complexity that doesn’t help us get the job done, yet when we consider testing, deployment and debugging, our opinions matter most. Adding standards for the common development practices is like adding memory management and garbage collection, it lets you stop focusing on the lower level details so you put your focus higher up the conceptual ladder. The result is better code.

By the way, regarding my critique of our recent code review and it revealing a symptom of a problem, it is something we’re in the process of fixing. Hindsight is 20/20 and we realize we could have made some better decisions earlier on that would have helped avoid the discrepancies between projects, but we didn’t at the time. Fortunately, it is never too late to change and change is exactly what we’re doing!

Packaging vs. Freezing

I’m currently waiting through setting up an environment for a project and start thinking about how slow this process is. In some ways it doesn’t really matter. How often do you really set up a development environment? That said, if you can’t easily set up your development environment, what makes you think you are setting up your production environment in a way that is reliable?

The essence of any installation is taking a set of files and putting them on the file system in a way some executable can run. There can always be other aspects such as updating databases or running some indexing process, but generally, you put the files in the folders.

One strategy for release is to take your development structure and simply tar it up. The benefits of this model is that it is simple and relatively reliable. When you are deploying to a platform where all you get is a single directory, this can in fact be advantageous. The downside comes about when you lose your development system or whatever system it is you are using to build from. The work you put into making sure things run is gone and even though you can recreate it, there is no telling what really changed.

Another strategy is to create a package. In this situation the important thing is not the “package” but the “creation”.  In this scenario you have some sort of a tool that takes the source, compiles it (if necessary) and places all the files in a package that can be extracted on the file system. Unlike freezing, this process is more reliable and understood in terms of knowing what has to happen to go from source code to a package. The biggest hurdle is that you have know where everything goes, which can feel like a daunting task. You also may have to package up other dependencies, which can also be a large endeavor.

Personally, I’m a fan of packaging. Even though my experience is limited, I’ve come to the conclusion that the process of understanding where everything is going to go, documenting it in a processable format and creating a step for that process is the only way you really will be certain your environment can be trust worthy.

When I say “trust worthy” I’m not talking about security. What I’m really talking about is confidence. Businesses consistently pay more for items that could be bought more inexpensively, but they pay the extra cost for the confidence the good with function or be quickly replaced when they fail. Packaging allows you to build that confidence so you can be sure when something breaks or goes down, reproducing the environment is just a script away. When you can’t be sure you’ve build your environment correctly, then you really can’t be sure any of the software will work as expected.

Indie Music is For Friends

I made an observation today. A rather large indie blog claimed how much they enjoy the new Girls record. From what I heard, I like it too. What struck me though, was that their first record was kind of terrible. The songs were OK, but they weren’t very different or added anything new. This is just my opinion of course. I had planned on seeing them and then I saw live videos and promptly realized I would not be spending money to see them. Again, just my opinion.

Going back to my observation, I think that a lot of indie music is really about seeing your friends succeed. What I mean is that even though the first Girls record and their live performances were not very good, the indie community saw something in the band and worked to make them succeed. The result is a new record that seems really great and they don’t suck live anymore. I can’t say the music is that different or provides something new, but at the same time, it is really accessible.

When I was younger and getting in punk and independent music, the bands had a vision to do what they wanted to do. It had nothing to do with getting big or signing your life away. It was, idealistically at least, about making the music that came naturally. A great example is Nirvana. When you watch Live! Tonight! Sold Out!! you can see immediately that their goal was not to put on a perfect show or perform their record. The goal was to do what they do and that was to play loud, have fun and do it for themselves.

I don’t get that perspective from indie music today. I get the impression that bands start hearing they could be someone big and start thinking in terms of how to get there. The indie music blogs also get a kick about being someone that discovers a band that breaks out vs. being someone who exposes people to new music. Gorilla vs. Bear is a good example of this kind of blogging as they have a distinct style they like and push, which means most bands end up sounding similar. This is fine when you want to find another chillwave artist, but when you are sick of dreamy music and want something electronic or heavy, you have to find someone else to help you out.

I’m not saying this is a negative. When I was first discovering punk music, it was very difficult to find bands similar to what I like. I listened to the Minor Threat discography over and over, partially because I loved it, but it was also because it wasn’t trivial to find bands that had similar characteristics. If I had a Gorilla vs. Bear of 80s hard core and punk as a kid, life would have been grand.

At least for a little while.

The more I listened to punk music the more punk expanded. I had bought Sonic Youth as a kid, shunned it as alternative, then rediscovered and realized it as punk. Nirvana was the same story. I found hard core and stoner rock and noise, all of which helped shape my perspective of punk and independent music. When we toured with the Meat Puppets it sealed the deal in terms of recognizing punk is not about the sounds, but where those sounds come from.

To be clear, I’m not saying that indie music today is insincere or too polished or really anything else that might allude to it lacking integrity. I am saying that the focus has changed. The gates are open and people see that success is a step through the door. It has become really easy to write songs without thinking some part sounds too “radio” or “main stream” because no one will say a band sold out. While it is really great that fans and press still support bands who do take steps to support themselves, it makes me wonder if that also lowered the standard bands have when writing. There is not a requirement to do something innovative or take risks. Taking risks might also be more difficult since the field of music has been saturated with artists for quite some time.

No matter the motives of artists, what really matters are that people are moved by music. Fortunately, music traditionally is not appreciated in a vacuum. Music helps to mark moments in time in a person’s life, which means that any song can be great to someone. My goal as a musician is to write the music we feel. We practice and work hard as a band to make great music and we want people to hear it, and most importantly, be moved by it.