Marc Charbonneau’s Blog

From rentzsch.com:

Programmers desire to rewrite because they know that after starting with a clean sheet of paper and building it all again, at the end they’ll understand the whole. Programmers write code to learn. Software has this double-edged sword where you can’t just wave your hands instead of implementing a particular function. It all has to be crystal. Programmers know this. They know when they’re done, they’ll have a complete understanding. It’s a noble desire.

I agree with a lot of what he’s saying. I’ve re-written a few of my own projects for different reasons, but a big part of it usually is just because I’ve forgotten my original intentions of how everything should fit together.

Tara Hunt posted a great article on Vitamin today about the role of community in software development. Although written for the web 2.0 app crowd, the same philosophy applies to any platform.

Principle #2. Design to delight

There are plenty of great articles on Vitamin that help you with this, but a really good rule of thumb to stick with is that details should not be overlooked. In fact, scaling back on the features (especially upon first launch) and concentrating on making each step of the process delightful (i.e. the language on the error pages, the ease of the signup process, and so on) is essential.

There is a great deal of competition in the online application space right now. We certainly can’t compete on price (since most everything is free), so we need to compete on experience. Take a look at every application that you can’t live without and go through each step. What you will most likely discover is that the designers have sacrificed features for detail.

Exactly.

John Gruber talked about software pricing a few times this week, which is a subject I’ve been thinking of lately as well. Finding the “sweet spot” is always a tricky issue, and pricing your application too low can hurt just as much as pricing it too high. The assumption is that if your application costs less than the competition, potential customers might just assume your application is of lower quality, and that extra $10 spent on the competitor’s product is buying them a better application. I’ve actually heard one developer say he wouldn’t even consider purchasing an application under $10; if the seller doesn’t think it’s worth that much, he just assumed the software itself was useless or buggy. You can apply this line of thinking to sales as well; putting your application on MacZot for 60% off may or may not get you a few more sales, but what message is it sending in the long run? This has become more and more of an issue in the past few months, with websites like MacHeist and others giving away free applications by the dozen ((The catch here is that most of these free apps are a one time only deal, and if you want future upgrades and bug fixes, you’ll have to shell out for a real license. It’s more “unlimited shareware” than a real free license.)).

Speaking purely as a greedy consumer, I love free software and I love getting deals. If I think there’s a chance I can get a free application or a 50% discount, I’m probably not going to purchase it right away. Instead, I’ll wait until a sale comes up, decide I can’t live without it, or (more likely) the “new” factor wears off and I stop using that application altogether. Naturally you want to avoid giving your customers this impression, but does that mean you should avoid sales and discounts altogether?

Personally, I believe sales can be effective if done right, and I’ve heard similar opinions on mailing lists and blogs. Here are two ideas that come to mind.

First, instead of a “40% off” sale once every six months, offer an incentive to buy that isn’t really worth waiting for if you like the software. For example, a bundle discount when purchased with another product, or a “buy one get one free” license that the buyer can give away to a friend. If you customer waits until the sale is over to make his purchase, it’s not a big deal; they’re still paying the same amount in the end.

Second, if you are going to offer a price break make it part of your regular pricing. I have a great example of this. When I first tried Menuet, it showed me a little nag screen that included a $3 or $4 discount because I was using Synergy, a competing product. I liked Menuet, and I figured with the discount there was no better time to buy it, so I purchased a license. Since then I’ve seen a similar discount on banner ads at Phill Ryu’s blog and a few other places. If for some reason I did miss out on the original discount, it wouldn’t really discourage me from purchasing Menuet in the future. Every time I see an advertisement or a reminder of Menuet, I see the same enticement. There’s very little sense that I “missed” my chance to get a deal.

Have any experience on the subject? Post your thoughts in the comments.

I’m a huge fan of “pre-built” Linux servers, which let you jump right in to the fun of *nix software without worrying about installation or configuration. One I recently came across is Buildix, a Linux version control server running Subversion, Trac and Cruise Control. Although I haven’t really heard of many people using Cruise Control, Subversion and Trac are pretty much the de-facto standard for managing open source OSX projects.

Subversion is easy enough to set up on a fresh Linux install if you have some background knowledge, but in my experience Trac can be a pain. Buildix seems like a good solution for anyone who needs a source control server, but isn’t too experienced in Linux server administration.

I read an interesting article from Steve Yegge today about agile development methodologies, and how things are done at Google. It’s interesting stuff, and tells a lot about why Google is a great place to work besides the usual “it’s that place place with the food and the swimming pools.”

Editing the default modes in SubEthaEdit is very easy, if you ever find one lacking. Hold down the alt-option key, click the Modes menu item, and select Show In Finder. SubEthaEdit modes are actually bundles, and the enclosed files can be edited to change the mode’s behavior. In my case, it was opening up ModeSettings.xml for the PHP mode, and setting it as the default mode for .php5 files.