Technovangelism

When developing a software project in a short amount of time (less than 6 months), demonstrating often that you are providing value to your customer is essential. Of course it is important for long-lasting projects, but if you only have three months to complete your project, you cannot afford to miss a demo.

I have learned this over the last two major software projects I have completed. On both projects, the team did not just “demo often,” but we demoed every week. (When you only work 2 hours a day, that is a bigger feat than it might seem.) We were not following the extreme programming methodology or specifically trying to program quickly, we simply found that we could provide enough value in one week’s time that it was worth presenting to the customer. These constant demos had some other beneficial side effects like keeping the build in an extremely stable state. Some people use an automated test suite for that kind of security, but having to demo the code once a week forced us to do more manual user testing that uncovers usability issues that an automated test suite is incapable of discovering.

Agile methodologies preach having shippable code at the end of each iteration/sprint, but how often is that the true outcome? When you demo your code to customers, you are essentially shipping your code. The customer has a chance to look at and try out the code and provide some instant feedback. In the most recent project, we actually did ship the code to the customer each week and they performed their own user testing on site. The amount of benefit gleaned from these each week was incredible and no doubt increased the success of the project. From now on, all projects I am apart of will have regularly scheduled demos in front of the customer or stakeholder. They are that important.

Meta programming is one of the most difficult, but rewarding styles of programming I have ever tried. It comes as second to nature to a language like ruby, but to me, it requires an incredible amount of mental strength to accomplish some of the simplest tasks. My first non-tutorial attempt was for a rails plugin auto_html. I added some of the easiest meta programming one can do; write out new methods as strings and have them transformed into regular methods. From auto_html_for.rb:

  suffixed = raw_attr.to_s + AutoHtmlFor.options[:htmlized_attribute_suffix]
  setter = %|
    def #{suffixed}=(val)
      @#{suffixed} = val
    end
  |
  getter = %|
    def #{suffixed}
      if @#{suffixed}.nil?
        self.auto_html_prepare
      end
      @#{suffixed}
    end
  |
  class_eval getter
  class_eval setter

Everything between %| and | is one string, and then class_eval evaluates that string and adds a new method to the class it is working in. Now that it is all finished, it looks so simple, but it took some effort to get right. What got accomplished with this code block though, is remarkably powerful, but only the tip of the iceberg when it comes to meta programming.

If you need to flex some serious brain muscle, start up irb and start getting meta.

When working in a community that is constantly changing with new features coming out every week, there are a lot of different plugins, mini-frameowrks, and other packages that are worth using in your projects. One can spend more time researching new tools to use than doing actual work. One always hopes the time spent finding tools and frameworks to make development faster will make up for the time lost from not developing.

My latest research involved the testing frameworks for Rails. Although there are plenty of them out there, I focused on RSpec and Shoulda. Besides Test::Unit, they are the two biggest players in the Rails testing world. I could have spent weeks trying to figure out which best fit my needs, but I enforced some time-boxing on myself and refused to spend more than four hours on this. With so few hours to determine which framework is for me, I really focused on the parts that are most important to me. Within those few hours, I finally decided on Shoulda. RSpec may or may not have more momentum behind it, but Shoulda fits the way I think and is (hopefully) the best solution right now.

When evaluating frameworks or plugins for yourself, always remember to time-box. Choosing the right one is certainly important, but spending the right amount of time choosing is just as important. You have to have time before you can start saving it.

In the original implementation of my forum site, times were all displayed as absolute times. The server sits in the Central Time Zone and at least 90% of the users, including me, are in the same time zone. I never found this a problem, until I spent a few months outside Central Time. My first reaction was to let users set their own time zone and then adjust the times automatically for them. Before implementing this, I found this post from http://blog.stackoverflow.com and decided to rethink my plan. Relative times would provide a simple solution to my problem and would help users in the future as more and more move out of the Central Time Zone.

Everything was working great until a few months in, when old posts were marked as made “about 3 months ago.” By itself, this was not a problem, but edited posts are tagged as edited and would read “about 3 months ago and edited about 3 months ago.” Users are only allowed a 30 minute window to edit posts after they are made, so old, edited posts will always read like they were posted and edited at the same time. Fixing this now requires even more relative time. By marking posts as made “about 3 months ago and edited 4 minutes later” I can still provide the important information that a user is looking for, and not have to worry about time zones.

In my latest attempt to fight burnout, I began experimenting with iPhone development. Joining the developer program was no sweat and there are plenty of articles and tutorials online to help you get coding. But the biggest problem when learning a new language or framework is knowing what to code. Building a Hello World application is great and all, but it hardly teaches you anything you want to learn.

My process for solving this perpetual dilemma is to build something that I actually need or want. For my iPhone project, I chose a Power Hour application. Before deciding this was the right project, I had searched for one in the App Store and was unsuccessful. This either means Apple is against such an app (unlikely), or no one has though of it yet. Either way, it is a simple enough that I can code it within a day, and it will teach me far more about iPhone development than a brief tutorial. Unfortunately, getting the app to my iPod Touch requires it to be put in the App Store which requires a $99 fee. Perhaps others would be willing to pay $0.99 for such an app and could cover the cost for me?

Before the iPhone app was started, I wrote a version in javascript as I had an emergency need for one. Feel free to enjoy an hour of it.

Thanks to #30:30:30, my motivation for blogging has increased significantly. The first few (ok, maybe first 15) posts were difficult and I had trouble convincing myself to actually write them. Lately writing has been significantly easier and I am enjoying it and finding some value in it. Now that I am writing consistently I have seen my subscribers climb a little (from 0 to the single digits) thanks to FeedBurner. I have yet to really promote my blog myself; Nate and Nick are doing a good job of that. But if my blog ever does get past three readers, a FeedBurner chicklet might be in order.

What impact does a FeedBurner chicklet have on a blog and its subscribers? If I put a chicklet on this site, I’m guessing it would cause more laughter than new subscribers, but maybe someday it could be of value. What is the threshold for a chicklet to help gain subscribers? Is a blog with 100 readers less enticing than a blog with 10000 readers? 1000 readers? A blog with many readers convinces me that not only has it been around for a while, but it will continue to exist and be updated. Unless the author really enjoys blogging, which he absolutely should, not having many readers is a good excuse to put off writing your next post until tomorrow.

Having been interested in starting a business of my own, I have been been paying close attention to software that could provide any sort of value to a startup. In my months of watching, I have found lots of software, some of which will hopefully help me in the future. Tonight I want to highlight Integrity.

Integrity is a continuous integration server designed for Rails and Git. By setting a post-receive hook in your git repository, every time a member of your team checks in code, your repository can signal Integrity to pull the latest changes and run all the tests in your Rails project. If you have never used a continuous integration server, the value might be easy to miss. Once you have used one and receive notifications of failed builds as soon as possible, it quickly becomes apparent how much time a server like this can save you. If you break the build, no matter how embarrassing it is, life is much better if you can fix the build right away, rather than every one find out that is is broken the hard way.

As I approach the end of a development project, I am becoming more and more aware of worthless documentation. Our dev team made an agreement with our client about the documentation that would be provided when we transition the project. Because of this, I have been examining all of the different documentation being provided and doing my best to strip out the cruft. The latest goldmine of not so helpful comments I have found is version control logs, especially when combined with fix messages on your bug tracking system.

The problem, as I keep saying, is finding any actual value in them. After looking through my team’s latest commits, I spent more time viewing the actual differences in the source than the messages provided alongside. After a few minutes of this, I began to look for the ideal commit message, and finally decided that one does not exist. All of your commits should be tied to a bug/issue/feature in your tracking software, and your messages are better made there. By only writing messages in your tracking software, you will never duplicate the same message in your source control logs. Even better, there are probably more people involved in your development process than just developers and other “code touchers” (one who checks out the code from source control). The non code touchers are very unlikely to see commit messages, and could potentially lose out of some important information tucked away in subversion.

Several sources cite the importance of private offices for developers. But those are referring to full-time, professional programmers who are spending around eight hours a day in those offices. They do not ever speak to different situations in which developers might be working for only two hours a day. According to the same sources, two hours is hardly enough to ever enter “flow,” let alone do something with it. With flow being such an important reason to have a private office, if you can never reasonably enter flow in the first place, is a private office worth it?

A significant amount of my development experience comes from working on a team of five programmers who meet together for a total of ten hours a week and due to space limitations, all work in the same room. Because we typically work no more than two hours a day, I am willing to argue that private offices would not benefit us. I won’t go as far as to say an open area is beneficial, but I don’t think it is doing any damage to the team. The developers quickly learn how to focus and block out noise so that conversations between two members don’t become conversations between everyone. Private offices could disrupt communication between individuals because walking to another developer’s office takes time. Granted, it is not very much time, but when you have only two hours per day, saving a few extra minutes can be critical, especially over the span of weeks and months.

While I tend to agree with the authorities on private offices, I am not so sure they are always the right solution. When I enter the full-time workforce, I will expect an office, but for now I am satisfied with my small, open room.

After working for months on several different projects, I have learned it is far too easy to get burnt out. On any given day, I spend between 4 and 8 hours coding, and I don’t have a full-time job. I love coding. It is my hobby, my passion, and will be my career for as long as possible, but there are still days when I have had enough. It saddens me that there is ever a day when I simply do not feel like coding. Instead of coding, I am able to do productive things, but they are never as fun; one can be subscribed to only so many feeds.

Inspiration to the rescue. I listened to a talk today from Geoffrey Dagley, a developer at Relevance, Inc. He develops in Rails, uses git and github as source control, follows Agile methodologies with Mingle, does behavior driven development, has a continuous integration server (RunCodeRun), and contributes to open source projects. All of the coolest possible things you can do in the Rails world.

I, unfortunately, only have the time to do a few of these right now, but thanks to Geoff’s talk, I am more inspired to keep working. Listening to someone talk about how much he enjoys doing all of the same things you are doing, is an easy way to fight off the burnout. Heck, another speaker of two like Geoff, and I might just go to RailsConf after all.