I’ve just shipped MenuTemperature 1.5. At this point, many people have probably moved on to different apps. To say that the release is late is an understatement. Originally called 1.1, I had wanted it out by July, then August. Now it’s almost November.
A lot of the work on this release wasn’t even done by me, but by Sam Rushing (thank you). As I’ve argued yesterday, it feels a little like giving a child away, letting someone else parent it, then receiving it back. You still love the result, but somehow, it just isn’t the same. I think it’s important that I get away from that kind of thinking. Not in a “it’s just a piece of software” way, but in one where everyone can contribute.
With MYSTcommunity, I often felt similarly. Should I let other administrators make many decisions on their own? Or should I always have the ultimate say? Which is right? And which benefits the members more? Clearly, the members benefit more when the founder isn’t egocentric and knows when to step down. So eventually I did, and observed the project at more distance, only to return with regained strength. I think that was great. It could have made me feel disposable, not unique — any other person could be an admin. But that’s not really true: many others could be (hardly anybody), and each one of them would have done it slightly differently. Perhaps better, perhaps worse, but certainly not quite how I would have done it — and not necessarily in a way I would have approved of.
In other words, I don’t like everything MYSTcommunity has become, and I don’t like everything MenuTemperature 1.5, but learning to deal with that is an important lesson of life, and a good one.
Dealing with Rushing’s code and retrofitting it was not a reason for the delay. I didn’t do that. I don’t agree with everything he has done, but I won’t do his code the disrespect of changing it around just for the sake of changing it around. That would be the very egomaniac behaviour I described yesterday, and negatively so. Eventually, Rushing and I were done working on it; my last actual code changes were around September 9. What delayed it was a wrong decision of mine.
I try to make my version numbering as simple yet logical as possible. I don’t use 0.* versions, because I find that they are usually a give-away that the developing team as far too vague ideas of what 1.0 should be like. And, more to the point, I try to never add notable features in point releases (x.y.* ones). This is not just beneficial for users — they’ll immediately see that an update focuses on bugfixes or other minor changes, rather than actually introducing soething new — ; it also has major project coordination advantages.
One became very visible once I had released 1.0: I was contacted by someone with a French localization. And then, after 1.0.5, I was contacted by someone else with a Traditional Chinese one. But if 1.0.0, 1.0.3, 1.0.5 and everything in between had had ever-so-slight differences in their feature set, it would have been necessary to revise, or perhaps completely re-do those localizations. That doesn’t just mean unnecessary work for the translators: it also means, as I have now found out, that you have an even harder time shipping an app when you intend to.
Because, once 1.5 entered beta stage, it was feature-complete — localizations could already be made; changes would only be under-the-hood, in areas not intended to be visible to users. So I contacted the French localizer, who assured me there would be a translation soon.
I don’t want to do him any discredit; he’s a very nice guy, and I genuinely and greatly appreciate the translation work he’s done. He’s probably just busy, or perhaps he forgot — it doesn’t really matter. The point is something completely different: I made the mistake of relying on someone else before shipping. That’s great when you have regular, frequent contact with them, but I don’t. I can contact Rushing several times a week, or amon-re, who does the occasional testing for me, or several others. But my localizers, for MenuTemperature as well as DashPrefs, are people I don’t know; they do their stuff, e-mail me, I respond back to thank them, and that’s pretty much it.
Bottom line: not only should you not rely on a deadline you’ve made yourself, because you won’t meet it anyway (cf. yesterday’s posting). You also should not rely, at all, on too unpredictable factors, and in this case, localizers who aren’t organized in a team and who you barely have any contact with are far too unpredictable.
So the end result, and I don’t really like it, is that 1.5 is shipping with fewer localizations than 1.0.6, which I’ve also released today. 1.0.6 does German, English, French, Dutch and Traditional Chinese. But 1.5, while having many more features only does German, English and Dutch.
When a release whose main rationale are new features lacks a feature its predecessor had, that’s quite ironic, and sad. It also means that some people using 1.0.x in French or Traditional Chinese will update to 1.5 only to find out that it doesn’t come in their language any more, and the downgrade is nowhere near as simple and automated as the upgrade.
Make no mistake: shipping an app is hard. No matter how prepared you are, you will make mistakes. And while writing this, yet another occurred to me.
) well on its way to become the new identity of ML. The logo is unique, recognizable, somewhat scalable and rather cute. It’s also reminiscent of Myst’s original icon (which, aside perhaps from a few slight tweaks, has been reused in Uru, too), and she and I agree on which of her four proposed color themes is the best (I’m deliberately not saying here since I’d rather have some additional, unbiased input!).
).