Tag Archives: development

Opinion

Growing Up in Public

What do Britney Spears and Yummy, my iPhone Delicious.com client, have in common? If you had asked me a few months ago I would have said nothing but I’d have been wrong. No, they both have had to grow up in public.

For a version 1.0 product, Yummy seemed solid to me. It was fast, coped will all my bookmarks and had the ability to add, edit and delete entries. I didn’t think that this would remain as a unique feature for as long as it has, but hey, that’s a bonus.

Within a few days I had exceeded what I had expected to sell and received positive feedback on the iTunes store. But not long after that I also received my first bug report.

This turned out to be an odd one. It crashed early on while starting up and downloading all the bookmarks for the first time. My first guess — incorrect as it turned out — was that it was running out of memory. It took some investigation with the help of a very kind end-user to discover that… Delicious allows technically invalid URLs. By that I mean both that they don’t follow web standards and, worse, that it’s not even possible to open them in Mobile Safari.

I don’t feel so bad about not spotting that one during testing, although I should have put in more error handling to spot various “impossible” events and make sure that it didn’t crash. The reason I mention it is to give an idea of the kind of things that happen in “real life.”

But my biggest mistake has been assuming that I am a typical user of Delicious. I thought a few hundred bookmarks was a lot but I now realise that I was wrong. I have some users with over a thousand bookmarks and have read about another with nearly ten times that ((I confess to being a little sceptical about some claims. At some points it becomes a bit of a pissing competition.)).

The exact number of bookmarks that you can store depends on a number of variables, such as the length of the URL, title and notes, the number of tags, the iPhone operating system ((Upgrading from version 2.0 to 2.1 tipped at least one user over the edge, and many developers do not get previews of new versions.)) and a bunch of other details outside my control. Looking at the reviews on iTunes I believe a few people had more than whatever that limit is. Unfortunately the error handling was lacking, resulting in Yummy crashing rather than an inconvenient but understandable error message ((I’ve not got to the bottom of this one yet. It seems that, sometimes, you can only spot a bad memory allocation by noting that an otherwise mandatory field is missing.)).

Version 1.0.2 was actually a big release in terms of the amount of code changed, if not in terms of visible functionality (which is why it was such a small change in the version number). Under the hood, though, I dramatically increased the number of bookmarks that Yummy could handle. However it was starting to become clear that the internal architecture was holding me back. Further increasing the number of usable bookmarks would be hard, if not impossible, without seriously degrading performance and some new features that I wanted to add would end up in a nasty tangle of unmaintainable code.

I decided to take a step back and fix the structure of the code. For much of the time since the last formal release, Yummy has been, metaphorically speaking, in pieces on the floor. Most of those pieces have now been polished and reassembled, and it’s now working well enough that I have replaced the copy of 1.0.2 that I have been using day-to-day on my own iPhone with the development version.

This is a long way of saying that there is a new version coming. There will be a number of great new features but many of the big changes are behind the scenes. I sincerely hope that you don’t notice them.

Opinion

Advertising your iApp

My iPhone application, Yummy, has been on sale in iTunes for a couple of months now and, as a number of other developers have noted, after the initial launch sales figures take a significant nose dive very quickly. I’ve been trying to think of ways to increase visibility without taking too much time away from actually making enhancements to the software.

As luck would have it, I got a “free trial” of Google AdWords and thought I would give that a try. Results have been… well, not exactly what I was expecting.

The way AdWords works is that you give it a bunch of search terms and when someone enters those terms you go into an auction with other advertisers with the same terms. You can set a maximum bid and a maximum per day. I confess that these are not values that I have played around much with; I stuck with the defaults. You then get charged when someone clicks on your advert, not just when it’s put in front of someone.

It turns out that with my choice of words I was averaging £0.33 per click. If we assume that every click results in a sale then I would say that this is on the high side of acceptable. Yummy retails for £1.19 in the UK, with Apple getting 30% and the tax man another chunk.

However that’s not necessarily a good assumption. In fact, I have no real idea of how good or bad it is. Using Google Analytics and AdWords’ built-in statistics I can see how many people visited Yummy’s website and I can see how many people clicked the link to the App Store. What I can’t see is the number of people who clicked on the ad that ended up buying a copy.

But the cost of attracting customers and the inability to track the effectiveness of the campaign was nothing compared with my frustration in penning a suitable advert. I started with the following text:

Delicious on your iPhone
Search and edit your delicious.com
bookmarks in one app on your iPhone

Sure, I’m not going to make a living as a copywriter any time soon, but given the space constraints I didn’t think it was too bad.

However after a couple of days my campaign was suspended because I’d used a trademark in my text. Now I’m no expert on trademarks, but I really don’t see the problem here. I’m not trying to sell dodgy iPhones; I’m not passing myself off as Apple; and I’m not selling a competitor, indeed all Yummy users are already Apple customers.

Writing about an application that runs on an iPhone without mentioning Apple or iPhone is not easy. I ended up with:

Delicious.com on the move
Search, add, edit and delete your
Delicious bookmarks in one iApp

They have not suspend that yet, but I think it’s a substantially less compelling advert.

So overall, it was certainly worth a try — I had nothing to lose — but for the price-point of Yummy I don’t think it’s worth paying for AdWords once my trial funds expire.

Languages

C++

Introduction

I don’t want to start off on the wrong foot again, but I’m afraid I might have to. If you read my discussion of the C programming language you may imagine that I’d like C++. After all, C++ fixes some of C’s idiosyncrasies, adds object orientation and a whole host of new features.

You’d be wrong though. In many ways I consider C++ to be a step backwards from its parent and this piece will hopefully explain why.

The big things in life

Identifying the main thing wrong with C++ is easy when you start making a list of features. I don’t mean a list trying to identify things it does badly, but a genuine feature list, stuff like object orientation, exceptions, strong-ish typing, multiple inheritance… Well I’ve only just started, but there’s a huge list.

And that is the problem. C++ has tried to incorporate just about every interesting software engineering development that has been made over the last twenty-five years. In some ways that’s a very good thing: it allows programmers to build code in the most appropriate way which ever that way might be.

The problem is that there’s more than one way to skin any particular cat. While just about any approach is fine on a small program, one with a single developer, when you have a team writing code if there’s no consistency in approach you get the situation where no-one is able to understand the whole. There is no one head big enough.

While There’s More Than One Way To Do It is a great motto for Perl, as a language it has a very different objective. Most Perl programs are ‘hacks,’ small programs designed to solve a particular problem. C++ is a hard-core software engineering language; large teams of developers are common. The same approach used for small programs just doesn’t work for bigger systems. I can build a thousand line program at the keyboard, but a ten million line system? Anyone that thinks they can are deluding themselves. Even on the off-chance that they aren’t, other people need to understand it too. No-one is ever around for ever and no-one is indispensable (except in the case of bad management, but that’s a different story).

Counter Arguments

People often cite C++’s similarity to C as a major plus. If you’ve already learned C, then C++ is easy, right? Just a few extra commands, use “class” instead of “struct” and you’re well away. Except some of the worst C++ code I’ve ever seen has come from people who think like that. Using “//” to start your comments rather than “/*” doesn’t make you a C++ programmer!

There are, however, some benefits for C programmers using C++ compilers. They tend to be less forgiving of bad code, they often give better diagnostics and error messages. But so do Java and C#, only more so. And the jump from C to Java is probably easier than moving from C to C++.

Conclusion

If we think right back to to the beginning of the development of programming languages, we remember that they were designed to simplify things; they were designed so that you could think about the problem rather than what the machine would do.

For the audience that they were aimed at, many of the earlier languages did just that. Fortran allowed scientists to write programs (in fact it’s still being used). Cobol put a greater focus on the business than had ever been the case.

And this is where C++ falls down. Its audience is software engineers, people who write very large and complex applications. Yet its complexity actually hinders development. With a large team, “write-only” code, programs that no-one can understand once they have been constructed, become not just possible but almost guaranteed. There are so many ways of doing the same thing, so many ways to shoot yourself in the foot, that the odds of it being both bug-free and maintainable are almost zero.

C++ does have its plus points, though. It is an excellent language to show how smart you are. If you can understand the entire language and write huge, complex and error-free programs in your sleep, you are clearly much more clever than I am.

Myself, I prefer to fight the problem rather than the development language.

Software

Yummy: Ready for Sale

Ready for Sale

I nearly posted a rude one-liner on Twitter about it. I was sat here in front of my laptop, browsing iTunes and slightly miffed that I’d submitted my iPhone application a week ago and that there had been no sign of movement since then.

Then I received an email from Apple with the good news. So yes, as I type this I don’t see it, but apparently Yummy is now “ready for sale” and will be making its way to the App Store very shortly. (I assume it’s a gradual process and that some people may be able to see it now.)

How exciting is that?!

Update: Yummy is now on the AppStore (opens in iTunes).

Update (2023): The link to Yummy’s website has been updated to point to Wandle Software, which didn’t exist at the time of launch.

Opinion

Competitive Threat

As many readers know by now I am in the late stages of developing and releasing an iPhone application. This is the first time I’ve ever really been involved in the launch of a consumer product and while there’s nothing here that is likely to surprise any marketing guru’s, I’m finding it an interesting process.

I talked about pricing previously, but today I want to talk about the competition.

I downloaded the SDK ((Software Development Kit, the program you use to write other software.)) shortly after the original announcement. The first version was fairly primitive, with little to no support for the drag-and-drop style of development used for parts of Mac OS X programs. I played around a bit, compiled a few demo applications but didn’t really get very far. Too hard, I though.

The beta’s came and I started having ideas for programs that I might want. Initially I thought they were too easy for a professional developer and certainly something that other people would be working on.

Turns out that I was wrong. Not only were most of the applications available on launch day very simple — tip calculators, currency converters — but no-one had thought to implement my idea.

Partly as an “itch to scratch” and partly because I had no competition, I set to work. This time rather than doodling around I had a goal. Well, a vague goal. My first attempts were too ambitious for my limited experience of the SDK and didn’t go very far.

I really gained some traction when I switched to my current scheme. All was going well until a couple of weeks ago when I saw a headline announcing my first competitor.

My first reaction was panic.

My second reaction was also panic.

It was a big deal. I’d got used to having no competition, to dictating myself exactly what features it needed to have and to thinking entirely in abstract terms about pricing. Reality intruding was hard.

I eventually calmed down enough to download a copy. Fortunately reality wasn’t nearly as bad as the simple idea of a competitor. Although unfinished, my application was already more sophisticated. It worked in a slightly different way but mine had more features, more closely conformed to Apple’s user interface guidelines and provided better feedback to users.

It did mean that I had to refine my thinking about pricing. But most importantly I had to start considering when to release it. Should I trim a few features so I could release it early? Or keep going, be a bit later but have something unique? In the end I just decided to keep going. Another “me too” product wouldn’t have managed to overcome their first-mover advantage, but extra features might.

If there’s a lesson here it’s that making the best product you can is a better use of your time than examining the competition. Happy users is the key to success and improving your software is the best way to achieve that.

Software

Yummy: Prepare for Launch

Yummy in iTunes Connect

Today is a big day for me. A few minutes ago I uploaded my iPhone application up to Apple’s servers, the first step in making it available to users in iTunes and its App Store.

You possibly have two questions. First: what does it do? Secondly: when will it be available?

I know, I have been deliberately vague when talking about it online. This is partly because I didn’t want my thunder stealing by pre-announcing, but mainly because it’s only been in the last week or so that I’ve been sure that I was going to publish.

You’ll note that I’ve still not described what it does. All I’ll say is take a look at the icon ((Not sure what’s wrong with the colours. It looks great on the phone itself, which, presumably, is not colour managed.)) and think of the name. And, more importantly, keep an eye on Yummy’s website. I’ll be publishing a series of blogs to tell you what it does and some of the decisions I took to make it.

The second question — when — is pretty much out of my hands. Apple will now, as the screenshot above tells you, review it and, unless I’ve made any mistakes in the rather complex process, make it available for download. The length of the queue is not public, so it could be tomorrow or the end of September or, more likely, somewhere in between. Fingers crossed that it’s soon!

It’s taken a lot of effort to get to this point, and I’m keen to get it in the hands of users. Many thanks to B for putting up with me during this process and for making the great Yummy icon; my gratitude to A for trying to get beta versions installed (damn that 0xE800001 error); and to everyone else who has offered advice and feedback.

Update (2023): The link to Yummy’s website has been updated to point to Wandle Software, which didn’t exist at the time of launch.