"Keeping it Simple" Posts
Posted in Keeping it Simple 
Comments
CBQ
Here are 4 reasons for prototyping applications first. By prototyping, I mean an emphasis on building working applications rapidly:
1. It is much easier to edit an existing application that to try to dream one up with nothing visual and interactive to work with.
2. Too much planning leads to over-complication. Sometimes you can be too smart for you own good. “What if the user wants to do X or Y.” Don’t guess, find out.
3. A working application that can be tweaked beats a theoretical application that is perfect (and either sucks when it’s “done” or never sees the light of day)
4. A Prototype forces you to focus on the core functionality, that makes or breaks your idea. Trust us, the logo is not your killer feature.
Credit is due to our good friend Mike Landman of Ripple for Reasons #1 and #3.
Posted in Keeping it Simple Comments
kevin
Recently I bought Madden ’09 for Xbox 360. I enjoy the game well enough (though seeing how I finished 11-5 with the Detroit Lions I now question its authenticity…) but can’t profess to have nearly as much fun with Madden as I did with 1991’s Tecmo Super Bowl
for the original Nintendo. The reason is a matter of simplicity.
Madden encourages the player to take the reigns of an NFL franchise or player, and often gets lost in the details by requiring too many off-the-field decisions and too complicated in-game button combinations. Of course the graphics are amazing, and online league play opens up a world of possibility never-before-seen in sports gaming, but when it comes down to actually gameplay, an element of pick-up-and-play gets lost in the complexity.
Tecmo is fun, plain and simple. No trades, no draft combines, no adaptive A.I., no bobbled catches, no user activated celebrations, no booth commentary or virtual trainers.
Just two buttons on the controller, eight plays to choose from on offense and one formation on defense, a trick move that’s unstoppable if executed correctly, and perhaps the most addictive gameplay this side of Tetris.
The contrasts between the two games remind me of something that’s often forgotten while developing software – the end goal. It’s easy to get wrapped up in feature-itis, in making applications too complex for their own good. But software that’s easy to use and sticks to its principle function is almost always the most productive.
Posted in Keeping it Simple, Ruby on Rails Comments
CBQ
If you’re just getting started with testing (and general test-first or test-driven development) in your Ruby and Ruby on Rails applications, you have a couple of choices.
You can go with Ruby’s Unit::Test, built right in to Ruby, and built-in to Rails with unit, functional, and integration test suites setup for you.
Or, you could setup Rspec with Mocha, and implement a form of testing called Behavior Driven Development or BDD.
Both approaches serve the same goal: better, tested code, easier code to maintain, and in general, just better practices.
My advice is to start with unit tests, and then move to Rspec later.
Read more... 
Posted in Keeping it Simple, Ruby on Rails Comments
James
As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I'm a big follower of that philosophy.
However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I've run across recently.
First, let's talk about filtering spam. I'm sure this raise some eyebrows, but I believe spam filtering is a human's job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it's a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That's right, I'm doing it all by hand and I much prefer it to any other system I've tried.
My complaint here isn't against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.
My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don't really account for my need to make corrections at all. I'm glad we make things so easy on the computer, but that means we're inconveniencing me. That can't be right. If I must be involved anyway, I want my role to be as simple as possible.
When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that's fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.
Let's talk about another example. In one of the applications Highgroove is currently working on the "Create" step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn't be a great experience. It's just one of those edge cases where it's really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.
How did we address this? With a good old fashioned phone call.
The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It's low hassle for all parties involved and gives the application that extra personal touch.
What will we do if the application grows so huge that this process becomes a bottleneck? Well, that's a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.
Don't let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can't handle too well don't underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.
