March 30, 2011

Software design is about iteration, not perfection

Kevin Hallmark @ 1:07 pm —

Over the years, I’ve learned some fundamental things about software development. Writing perfect code with a perfect design is a fools errand. Perfection used to paralyze me. These are some principles I use to help me make coding decisions.

1. Don’t rewrite your application. Ever.

This explains it better than I ever could.

2. DRY – Don’t repeat yourself

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

While it can apply to data sources as well, I am applying this to  code itself. Every single line of code you write is a potential bug. You should strive to write the least amount of code possible so you can depend on “known working” code.

If I need to get a record from the database, I can either write the select/execute call every single place I need it. This works for one off calls, but if I need to get that more than once or twice, a function is a better choice. I won’t have to worry about making a mistake each time I write the code. This is a contrived, but relevant, example.

3. YAGNI – You Ain’t Gonna Need It

“Always implement things when you actually need them, never when you just foresee that you need them.”

Simply put, if you don’t need it today or tomorrow (soon), don’t write for it. Maybe put a little underlying support code in, but don’t implement it until you have to. It takes time to add code, debug it and document it, time that might be better spent on more pressing features. If you add the feature too early, you need to support that bloat. If you need to refactor, you are refactoring more code. You have to make sure it doesn’t break.

After all that effort, you might even find that you don’t need the feature (ever), or you need something slightly different. The way you implemented it might be mutually exclusive with what you actually need. Adding it before it is needed might actually make you unable to implement a feature you need, or may lead to an incomplete implementation.

A good example is scaling. Why would you write software to scale your servers when you aren’t even using the power of one? Why write some awesome abstraction when it’s not going to be used by anything?

4. Three simple steps:

  1. Make it work
  2. Make it fast
  3. Make it pretty

I used to worry about the perfect application. I wanted everything to be the creme de la creme design. Unfortunately, I found that I never actually wrote the application. I got stuck in the design and never built out all the features I needed.

In a time crunch, you need the code to work. It doesn’t matter if it’s fast or pretty, if it doesn’t work it’s worthless. Usually, I can make it fast enough with iteration one, but as a system grows you’ll need to make things faster. As each pain point in speed becomes apparent, whack it out. Eventually, you’ll discover where you need to optimize. Finally, making it pretty by identifying code duplication and eliminating it where needed.

These principles have helped me write better software. I hope they help you too.

August 16, 2010

Some lessons about Ruby Plugins

Kevin Hallmark @ 11:25 am —

So I have been having trouble getting plugins working with my Ruby app. I followed the directions here: and it was working pretty well.

However, I came across two “gotcha’s” that gave me a little trouble.

  1. You have to include init.rb
    This fact was not readily apparent to me, I thought ruby would just take care of it. In my case, I had to add the init.rb into the app. This is probably obvious to you Ruby veterans, but not me as a n00b.
  2. You have to include your plugin’s file into init.rb
    Again, this seems like a no brainer. It’s not. You have to add each file you want your plugin to us to some file included by init.rb.

Obligatory plug for the peepcode above. If you’re just learning about plugins and Ruby, that peepcode is worth every penny

May 12, 2010

Google launched a new design, and I hate it

khallmark @ 10:15 am —

Update 2:

Apparently, you can get the old interface back with a little hack.


You can complain here:

For uniformity, let’s complain using the same options. Select the option from my screenshot below.

Dear Google,

The new left navigation is horrible. Don’t get me wrong, I like the functionality the left rail exposes. I like being able to easily filter my results by content type, date, etc… but I don’t want those features in a left rail.

Simply put, the left rail undermines what originally made Google great: simplicity. Google has always been visually simple, allowing me to easily scan search results. The new left rail is just a distraction. It takes some of the most valuable screen real estate and fills it with something that is not always needed.

The most important information on the page is my search results, not the sorting, filtering, or ordering therein. When I use Google, I want to access search results 100% of the time. The algorithm is so good, most of the time I don’t even need to refine my results because the answer is right there. I want to filter my results significantly less often.

The search filtering might be better suited to a right rail: there when I need it, ignorable when I don’t.

The new left rail also removes an important visual cue from the page: the browser left edge. My brain naturally tracks to the left edge of the browser window, much like reading a book. Now, instead of shiny clean search results, I get the left bar. While there is still a line for visually tracking the edge of search results, its soft coloring doesn’t give you a strong visual cue for the left edge of the content area; the contrast between the browser edge and the page is still a stronger cue. I end up scanning to the left edge of the browser, bringing my attention back to this evil left rail.

I understand that you want to advance your search engine, exposing more features to your customers. I’m all for it. However, those changes should not come at the expense of a tried and true product. You should let long-term customers retain their current configuration, if they desire. Give users the new look by default, but let account holders turn it off.

Remember “New Coke”? Instead of replacing their tried and true product, they could have released it alongside their flagship product. Don’t repeat the mistakes of your predecessors!

Please don’t make me hack it away.



May 9, 2008

The Password Anti-Pattern

Kevin Hallmark @ 11:55 am —

My friend at work sent me this interesting article about the password anti-pattern and I thought I would share it with you.

It’s called the password anti-pattern and it’s on Jeremy Keith’s blog.

Basically, new application frameworks like the Facebook api have created some unpleasant trends. The most significant trend is asking a user to enter their login and password to a site in order to access the user data. Jeremy contends that in doing so, we’re causing user’s to give away their login and password without thinking about it.

I urge everyone to not implement this feature into their applications. While your application may not be malicious, and your favorite application might not be malicious, someone else’s could be. We need to prevent the egregious breach of good security practice from becoming common place. As Jeremy mentions, there are alternatives out there. Google and Flick both have API’s that allow a user to authenticate without having them send you their login credentials. If you have control of the web services you are consuming with your application, you should consider implementing the same kind thing. In the long run, it will take longer. I think the advantages will outweigh the disadvantages in the end.

I pledge not to implement a feature like that on any site, even if it costs me a contract. Short term monetary gain is not worth perpetuating poor design to all internet users.