High Order Blog

Last week Ars Technica posted an interesting article about whether or not it’s feasible for small iPhone developers to support the “push notification” service Apple plans to include in version 3.0 of the iPhone OS.

I can speak to this not only because we’re a small company (tiny, really) building iPhone applications, but because at least one, maybe two, and probably more of our applications could be improved by adding “background notifications,” regardless of whether the implementation takes the form of processing done on our server and a small notification pushed to the phone, as Apple proposes, or processing done in the background on the client.

First, let me say that I can understand the reasons why Apple is hesitant to open up the phone to background processing. My own iPhone currently has about 5 or 6 “pages” of applications. The vast majority are ones I’ve downloaded, run once or twice, and have never run again, a pattern which seems to be representative. Furthermore, the quality of those apps varies dramatically.

Many of these apps would run in the background if they could. Would I want them to? I’m not sure. While it would be possible for developers to write background processes that are well-behaved, and therefore don’t needlessly suck up CPU cycles and battery life, I’m not convinced that would be the common case.

The cost to the user of a misbehaving background app is pretty high. Worse, troubleshooting the problem isn’t exactly straightforward. All the user knows is that his phone seems sluggish, or that his battery life doesn’t seem to be what it was. Is it the phone or an app? If it’s an app, which one out of the 30 or 40 that have been installed is the problem?

I can definitely understand why Apple wants to sidestep this whole issue.

All that said, I think the utility of Build Watch would be increased dramatically if notifications of failed builds could be pushed to users in the background. Let’s consider what would be required for Build Watch to leverage push notifications.

First, we’d have to replicate most of the business logic that’s implemented in the app within a web application. This would include storing the list of servers for each user, the show/hide status of each project (since we don’t want to be sending notifications for projects they don’t care about), and the most recent build status for each project, so we know when that status changes. This would all have to be new code, since we’re not going to be running Objective-C on our web servers. The iPhone and web applications would then have to be maintained in parallel as new features are added and bugs are fixed. (Maybe this duplication means that the architecture of iPhone apps leveraging background notifications will fundamentally shift over time. All important state and business logic will live on the server, and the native iPhone client will reduce to just a pretty front-end.)

Some functionality won’t work at all. For example, it’s currently possible to hide and unhide projects even when the phone doesn’t have an Internet connection. This is just configuration stored locally, so the current implementation is simple. Getting this working in conjunction with push notifications requires us either to forbid the behavior altogether, which is a clumsy compromise, or devise some mechanism for syncing the user’s offline changes with the server’s state. The latter can only be performed the next time the user opens the app while connected to the Internet. In the meantime, perhaps confusingly, they’ll continue to receive updates for projects they don’t care about and/or miss updates for projects they do care about.

More critically, consider people whose build servers are protected behind corporate firewalls. I suspect the majority of our users fall into this category. A web service pushing notifications doesn’t work at all for these users. One might argue that they’re not any worse off than they are now, but push notifications as a general purpose solution has no answer for this problem. Background processes, on the other hand, would work quite nicely.

Next we have to consider cost. Build Watch currently costs $2.99, and that’s a price point we like and will likely follow for future apps that are similar in scope. That’s about the price of a small latte. If we want to support background notifications, we can no longer just code up the app, release, and move on. We now have server processes we have to continue to develop, pay for, and maintain, with no obvious path for earning continuing revenue from the user.

All this must be overcome just so our little app can download a few kilobytes of RSS data and alert the user if necessary. Seems a little disproportionate, doesn’t it?

This becomes an even bigger problem for small shops like us as background notifications become a user expectation. Will users even bother checking out our apps if we don’t support this behavior?

I’m not terribly concerned with the scaling issue pointed out in the Ars article. Granted, we’re not building Twitter clients, but even if we were I’d consider scaling problems to be a good one to have. Several hundred thousand paying customers sounds just fine to me. I’m much more concerned about its limited usefulness for a large class of applications that could benefit tremendously from background processing.

Since John and I started coding about two months ago, we’ve been looking around at various issue tracking systems. For Code Watch development, we used Lighthouse, which I quite like and want to share ‘why’.

Before I do that, however, let me get the following disclaimer out of the way: I think there’s something weird about issue tracking software. I rarely, if ever, hear anyone praise their issue tracking system — which isn’t the case with other types of software, like version control. And there are all kinds of issue tracking systems out there, which is somewhat unique. These trends probably result from the fact that issue tracking systems are meant to help people in a realm in which we all work very differently. Things like team and organization size and structure, project scope and culture vary considerably and these are just a few factors that determine how we work.

Given that, maybe there isn’t a ‘best’ system. Perhaps we ought to have a million different issue tracking systems to meet our diverging needs. Or perhaps we are the problem. Perhaps we tend to organize ourselves and communicate in dysfunctional ways, and we blame the software for our dysfunctions. I’m sure there’s some truth to both theories, but, regardless, I’ll explain what I want from my issue tracking system:

Not much. I’m a big believer in keeping things simple. Software teams should be as small as possible. That’s the most effective way of managing a project. Sure, issue tracking and project management systems can facilitate communication to a point, but there’s no software substitute for small focused teams. I don’t dispute the fact that some tasks involved with software development like testing and ‘project management’ are quite different from coding, and it’s tempting to hire specialists, create special teams and create software to help manage these entities. And I don’t dispute that these skill sets aren’t necessarily correlated. Furthermore, a great coder is worth his weight in gold despite any deficiencies in other software development skills. I just believe that those skills aren’t mutually exclusive, either. The fewer points of knowledge and dependencies the better. That’s my theory. Simple.

So, specifically now, what do I want from my issue tracking system? I want it to get out of the way. The easier question to answer is ‘what don’t I want’.  

I don’t want ‘workflows’. I don’t want to submit an issue that gets sent to one department for processing, which then sends it to another department upon completion, and so on. Assembly lines are cool, but creative human work doesn’t seem to resemble them.

I don’t want to set a task’s priority. If a team is small and focused, everyone knows how to best spend their time.

I don’t want to estimate how long a ticket will take to implement. I’m always way off. I spent multiple hours yesterday getting a table cell to display properly. In the same amount of time, I probably often times knock off 2 or 3 sizable features. And as far as aggregating time estimations (even with some fancy statistical considerations) to estimate a deadline? Forget about it. What about the five huge features you didn’t expect, the three that ended up not making any sense, and the massive refactoring two weeks into the project? How do you account for those? You should constantly re-evaluate scope and priorities. It’s safe to say ‘this is the focus for the next month and we’ll get at least this far, and nowhere near that far’, but that’s about it. Again, if you’re confident that everyone is working on the most important things, how much does it really matter? What tradeoff would you make?

Interestingly, most of my Lighthouse tickets are less than a couple days old.  There’s no way I could have anticipated those issues before we started development.  I could have anticipated some set of issues, but I would have deleted them over time and created new ones.

Lighthouse doesn’t support any of the above features, and I hope they never do. It really is ‘beautifully simple issue tracking’. Useful features like tags, milestones, powerful search, ticket status and ownership, attachments, extensibility, etc. are all there — and not much else. Check it out.

We’re hard at work on our next iPhone application: Code Watch. Like Build Watch, Code Watch is a tool for software developers. It’s a client for GitHub that lets developers track their activity, as well as keep up-to-date with their favorite GitHub projects and users.

We plan to keep our focus on developer-oriented iPhone applications for the time being. Part of our motivation is selfish: we want to build applications we’ll use ourselves. Since we’re spending the vast majority of our waking hours writing code, developer tools seem like a good starting point. We use both Build Watch and Code Watch every day, and we get a lot of value from them. We think other developers will, too.

Take a look at what we have in store for Code Watch. If there’s a feature you’d like to see implemented, let us know.