Transcending Frontiers

Smashing Magazine recently published a great article on choosing a domain name for your site, product or company. It’s a problem that many of our customers face, so if you’re in the market for a new domain, or are interested in how your domain stacks up against their recommendations, be sure to check it out.

Programming isn’t a science, it’s more of a craft to me. A craft implies a combination of some creativity and some practicality. You can make a wardrobe that does the job, or you can get a craftsman to do the job and you’ll end up with something that is not only functional, but great to look at. Craftsmen build the furniture you buy from antique stores.

Software can certainly be the same. Software can work, or it can work well. It can be inspiring and fun to work on, or it can be terrible and boring. It generally comes down to the skill and work ethic of the person that is writing it in the first place. I want to build an antique, not an $11 chair from Ikea.

Corey Haines has been doing a series of videos about all matters software related, but he seems to be mainly passionate about Pair Programming. I like how he sometimes delves into the psychology of people in an industry that is populated by so many with unusual profiles.

He operates a blog called On Being a Journeyman Software Craftsman and it contains a bunch of videos and short blurbs about things he’s learned while on his trip. I’d check it out and you might learn a bit about some of the cooler ideas out there in the software world.

I’ve written about Rails Rumble previously, the 48 hour event where teams turn an idea into a web application using Ruby on Rails. I was surprised to see the completeness of some of the applications that were developed this year as well as the utility of the ideas they implemented.

One of the more interesting articles I’ve seen in relation to Rails Rumble analysed the prevalence of various plug-ins and gems that teams utilised.

After a quick look there are a few points that specifically interest me :

• jQuery is the most used Javascript library, even though it isn’t the default included with Rails. I think this says a lot about where jQuery fits in the client side coding space these days. Under further scrutiny it seems clear that jQuery had an even larger base of use than shown in that graph, as explained here.
• 1 in 3 teams used a skeleton application. All of those teams used Bort. That’s a pretty overwhelming statistic for two reasons. Firstly it means you should be looking at using skeleton applications if you aren’t already. Secondly anything that you develop that could be used in other applications should possibly be a gem or plug-in. Reuse doesn’t seem to be something you just talk about anymore.
• Over 50% of people wrote tests as part of their application, and the majority of people used a Behaviour Driven Development framework such as Shoulda or rSpec (they got rSpec!). Keep in mind that even on a tight schedule most people using Rails are writing tests!
• Over a third of applications offered OpenID support for authentication. Given I don’t even remember where I signed up for OpenID this surprises me. Maybe it’s time to join this bandwagon?

I think the article gives a good indicator where you should look to implement certain parts of your application. Generally speaking, if a lot of passionate developers are using a particular library or piece of code then you’d be wise to make the same choice.

It’s taken almost five years, but the final verdict is in and SCO owes Novell $2.5M for the pain and suffering it caused with its claims that the Linux kernel was tainted with source code that it owned.

To be honest, I’d forgotten all about this, but I guess it’s a good thing that it’s all wrapped up. Poor SCO, that buy-out offer from IBM never came, did it?

This week I took some time to review Jason Fried’s (of 37signals fame) presentation at the Business of Software Conference (run by Joel Spolsky and Neil Davidson). Having just read Getting Real, I was looking forward to a condensed and revised presentation following up on these ideas.

The presentation covered some material from the book, as well as delving into a few other concepts. It took a few days to get through the hour long presentation, but was worth the watch.

Some of the information I picked up and will be thinking about:

• Keeping momentum - Projects always start off enthusiastically and taper off drastically as time goes on. Breaking projects into much smaller chunks (a couple of days to a week) so you can keep up momentum is beneficial.
• Vocabulary - Drop a few words from your vocabulary because they cause things to go wrong. Can’t, need, easy are a few examples. We “can’t” launch like this. Why not? Do you actually “need” to introduce this new feature? Is it really that important? Telling someone that something is “easy” is a no-no. Don’t describe other peoples work with this word (”Just add this for me, it’s easy”).
• Passive collaboration - Alone time is extremely important to getting things done. Anyone will tell you they are most productive early in the morning, or late at night when there is no interruptions. Find a 2 hour block, switch off communication and shut your door. Communicate passively (IM, Email) rather than face to face, or in meetings. Just because you have something you want to share, it may not be (and probably isn’t) more important than what the person you are interrupting was already in the middle of.
• Now and 10 years - When thinking about product features and design use this rule. What’s important now and still will be in 10 years (speed, ease of use). Think about improving areas that will still be relevant in 10 years.
• Lower end of market - Most mainstream established products are too difficult for a new user to use well. Companies like Microsoft and Intuit have had their products out there for decades and it’s hard to compete with that. They keep adding new features so people will upgrade each year. They used to fill a simple need, but have moved past that and cram anything and everything into their applications. Move your product into that empty space. Solve someone’s need and solve it well.
• Teach/share - Don’t horde your thoughts and ideas. People and companies who share, flourish. Blog, release code, write about what you are doing. If you do this, people will remember you.
• Solve simple problems - Everyone wants to be the one who solves the hard problem. Give up on hard problems. There’s far too many simple problems that need solving and solving well.
• Curate your product - Treat your product like a museum. Every feature request, every change you make, look at the bigger picture. A curator doesn’t add artwork to the museum just because someone wants them to. Make sure your product will remain intact.