Developers' Blog

“Dude. Where the heck is MYStuff 2.0? You said, like, months ago that you were working on it.”

While not a literal email from any of the current MYStuff users, it’s a paraphrase of a number of emails as of late. So I thought I’d take a few minutes and give everyone an update.

As I stated over a year ago, MYStuff 2 is a ground-up rewrite that I started in September. It’s more than just re-writing all the existing features and making them better. I’m adding tons of new features, too. From the database backend to the user interface to all the new stuff, MYStuff 2 has been a major undertaking, and some of the features have proven to be quite ambitious. Further, all this new code has to be tested and debugged as well, and since it’s a ground-up rewrite all the program code is new. (Well, not all of it. I was able to re-purpose about 10% of the existing codebase.)

Half of me is jumping up and down with excitement about the new version and is screaming in my left ear, “It’s close enough! Wrap it up! Ship it now! Ship it now!” while the other half of me is screaming in the right ear, “It’s not done! Make sure it’s polished! Don’t cut out any features! Give the users a good value! Make it seamless!”

So I’ve been left with a decision: strip out planned features and release “soon” and dribble out the missing features as I finish them, or stick with the intended feature set for 2.0 and ship “soon-ish”.

After much hand-wringing, I’ve decided to go with the latter option.

And I’ll give you an example of one of the features that’s been slowing me down: barcode scanning.

I’ve had people asking for it since MYStuff 1.0 was in beta. Unfortunately, it’s not a trivial feature to implement. There are other programs out there that have it, but few have pulled it off successfully. I have a little test program running that scans barcodes just fine and dandy, but it’s problematic: It generates false readings about 20% of the time, and that’s assuming you have the lighting good enough to get it to recognize the barcode at all. If the lighting is good and you have everything set just so it doesn’t do a bad job, but do you want a piece of software with a feature that’s just “okay” and doesn’t work well enough for you to use all the time? I didn’t think so. At the same time, if all I gave you for an upgrade was a new paint job and no new features worth mentioning, would you be excited about it? Again, I didn’t think so.

Long story short, I’ve been working hard at making MYStuff 2 (and MYStuff 2 Pro) an upgrade worth getting excited about. Rest assured that it is under very active development at the moment, and that it will be getting into beta “soon” with an expected ship date of “soon-ish”. Have patience. I promise it will be worth the wait.

Sorry, comments are closed for this item.

There are times I refer to Minder Softworks as “we”, and in reality, that fits. No man is an island, and neither am I: my wife is an essential part of Minder Softworks. Among her many contributions, she helps me make important decisions, helps me stay focused when I want to go racing off chasing something shiny, and on occasion she helps me think through a perplexing code problem. (She’s a coder too, by trade, though she codes for “that other platform.”) So while she’s not involved in the day-to-day operations, she’s very much a part of Minder Softworks. That said, the only person working on code is me. I’m also the only person answering tech support emails, maintaining the website, doing all the accounting work, and doing everything else that needs done to keep the business running.

What does this have to do with anything? Well, it has to do with resources, and the proper utilization thereof.

As any dedicated businessman, I make it a point to do three things:

  1. Listen to my customers
  2. Evaluate my competition
  3. Work hard to deliver an exceptional product

In the almost-three-years we’ve been in business, I’ve never once had someone email me asking me to make my applications better looking. Not once. They always email asking for features. And in that same time period I’ve seen lots and lots of applications rise up in the Mac market (some competitors, some not) that put the sizzle before the steak.

Imagine you go to a steakhouse and order a 12oz New York strip, cooked medium. After about half a beer, the waitress comes over with one of those cast-iron plates with wood bottoms, a sizzling steak on top of it, and a caution to “be careful, the plate is hot.” The steak looks beautiful, a nice brown with a perfect char. The sizzle sounds wonderful. And with a huge grin you grab your steak knife and cut into it… and it’s bleeding. It’s so rare you can hear it moo. The waitress looks busy, so you decide to take a bite and see if you can suffer through it… and it’s way over salted. After 15 minutes you finally flag down the waitress, who rudely takes your steak to the back. Twenty minutes later, you get a new steak that’s well done. You suffer through it (after all, you’re hungry), pay $35 for having a crappy meal, and swear to never go back.

Was the sizzle worth it? In my book, no. I want a hassle-free and enjoyable steak-eating experience. I want my steak the way I ordered it, and I want it to taste good. And I could care less if it comes on a sizzling plate if it’s not cooked to my expectations.

The same situation is happening in the Mac software market: many applications look nice. Until you try to use them and you find them lacking in features, or incorporating some sort of weird “workflow” model that you have to learn how to use. Many of these applications are part of what’s become known as The Delicious Generation.

With the limited resources I have, I have to choose how best to spend my time. If I’m going to spend two days on something, I can choose:

  • to implement a much-requested feature, or
  • to make it look pretty

Is it possible to do both? Yes. But it takes twice as long, or twice as many people.

There’s nothing wrong with making something look good, and I want my applications to be visually appealing and easy-to-use, but unless my customers want it, I’ll focus my efforts on putting the steak before the sizzle. Why? Because companies that put the sizzle first don’t last very long, and eventually their applications wind up like this. We’d much prefer to establish a long-term relationship with our customers, rather than disappear after a short-lived flash in the pan.

So, I’m here today making my customers a promise: I will always strive to deliver applications that are simple to use and feature rich before I spend time making something look good only for the sake of it looking good. I will never put meaningless aesthetics over usability or features. Ever. You have my word.

Sorry, comments are closed for this item.