has_many :thoughts

My Dad asked me to help him buy a new (Windows) computer for work today and I agreed to walk him through it on the phone. “Just get the best you can afford.” is usually my mantra to folks who ask for help speccing a PC.

Little did I know the gauntlet that lay before us.

Dell’s website demanded we choose options for each one of 44 different questions as a part of “building” a new laptop.

The process was truly laughable. While there’s something to be said for having a variety of options to get just what you want, this was just ridiculous. It’s no wonder the Mac is considered the non-technologists computer (and hell, now it’s the computer of geeks too)—Apple’s website has just 13 simple options all on one screen.

Most of the “options” were just upsells for all manner of add-ons from PDF writing capability (free with OS X, or an open source download but that’s another story…) all the way to “Would you like Dell to plant a tree for you when you buy this computer?” ($4).

Many of the options were nonsensical and difficult choices even for a seasoned veteran like myself. Here’s one of my favorite selections:

When will people learn that simple is often better? I’m reminded of the old “less software” approach of a well known company…

Sometimes the horrendous user interfaces I come across on the web really astound me. I stumbled across this on an eCommerce site:

 0-12 $13.00
13-24 $2.80
...etc.

I took this screen shot from a 22 page PDF manual on how to use this particular website. Perhaps if the user interface was more carefully crafted, one wouldn’t need a manual on how to use the site.

I recently found myself having a debate I’ve had many times with clients. Should one retain us to build them custom software? Or should one buy something off the shelf?

I always say there are places for both solutions. And sometimes a solution involves both. But there are some important distinctions that some people need reminding:

In one corner you have off the shelf software: a cheap (well, cheapER) solution that gives you a lot of features for a little money but locks you into exactly the features they offer you and nothing more. It’s quick and and it’s inexpensive but it’s canned and standardized.

In the other corner you have custom development, a custom answer to your needs that has whatever features you can dream up and have the budget for. It costs more and will take longer to get in place but there are no limits to the kind of processes you can outline and features you can support.

Example: Let’s say you want to have a “build your own custom chocolate box” feature:

• Custom software: No problem. We discuss it, design it to the clients liking, budget it, and build it.
• Boxed software: Such a feature probably does not exist. One needs to come up with some kind of work around to get done what’s desired. Or one has to beg the software vendor to add such a feature which they may eventually do if they have enough clients who are willing to pay for it. But if they don’t, they won’t.

“Italy doesn’t have this much spaghetti code.”—Steve, on the state of one of our ASP applications.

The more Rails we do, the more I realize just how disorganized some most of our ASP applications are.

Some of it was inexperience on the part of both management (me) and our developers. But too often I think we caved when clients said they needed something done right away and on the cheap. We need to be firmer with clients and explain to them that, very often, there’s the right way to do things and the cheap way to do things.

We should tell clients, as Andy says:

“A project’s key factors are Time, Cost, and Quality. You can control any two.”

AKA: Want it faster and on a tight budget? Quality is going to go down. Want it done fast and high quality? Costs are going to skyrocket.

So far, the switch to Rails has helped force us to be more organized and deliberate with our code. But more importantly, it allows us to react more easily to clients’ ever changing requirements and scope.

If you haven’t looked at this week’s RubyQuiz yet, beware. Spoilers ahead.

This week’s quiz was dead simple. But I think that’s the point of this one. The most interesting thing about RubyQuiz for me is looking at how other people solved the same problem (no matter how simple) and learning about other ways to do things.

Here’s my solution:

(1..100).each do |n|
  ret = ""
  ret += "Fizz" if n.divmod(3).last == 0
  ret += "Buzz" if n.divmod(5).last == 0
  ret = n if ret == ""
  puts ret
end

The challenge presented this week is one that is well suited for a quick in-interview coding session for potential hires. Having prospective employees write code was a new idea to me that I read about in Joel on Software. And although I didn’t have candidates in the last round of hiring write code, I did review some psudo-code on the whiteboard with them and I think the next candidates will actually sit down at a machine and tap something out for us in our presence.

Since when do clients settle for a week of downtime during software upgrades?

The YMCA I go to every morning has had signs up for two weeks now saying “GO LIVE IS COMING SOON”. It went on to explain that they were upgrading their member management software and that their system would be down between June 1st and June 7th.

Say what?

I had to re-read it. Yes, indeed, their computer systems would be down for 7 days. During which time they cannot process memberships, accept new registrations, or even swipe someone’s member card.

To me, that seems totally ludicrous. Rarely do I have a client that will even accept downtime counted in the hours during an upgrade. We strive for upgrade processes that are so seamless that downtime is limited to minutes. (And we still do them in the dead of night in case something does go wrong.) It seems unlikely that any change in software would require a week to switch to.

What are they doing – rekeying all records into a new database?