High Order Blog

All our code is belong to you. That’s right, starting today we’re making the source code for three of our four projects publicly available. Those projects are Build Watch, Code Watch and Bug Watch (never released) and are meant to comprise a nice little suite of development utilities for the iPhone. You can find the code for those projects and others on our GitHub page.  In case you’re unfamiliar with these projects, here’s a little information on each:

Bug Watch is a Lighthouse client for the iPhone and iPod touch. (Lighthouse is our preferred issue tracking system.) We were close to releasing this app some time ago when we got distracted by writing a Twitter push notification server. We planned to come back and finish it when we found some time. Still waiting for that to happen. Here’s a screenshot:

Code Watch is a GitHub iPhone app. This app was available on the iPhone App Store as a free download called ‘Code Watch Open Source’ and as a paid version that provided access to private repos, just called ‘Code Watch’. For now, we’ve dropped the lite version and made the ‘pro’ version a free download.

Build Watch, High Order Bit’s first project, is a simple client for various continuous integration servers (CruiseControl and Hudson). There are many types of continuous integration servers and even more customized configurations. We hope opening up the source code will allow people to implement support for their setup with minimal effort while being able to leverage the full range of Build Watch features.

All of these projects are licensed under the MIT License, which basically means you can do whatever you want with the code. Unfortunately, we don’t anticipate having a ton of time to further contribute to these projects, so we’re hoping they’ll attract some new developers. If that’s you, we’d love to hear from you and answer any questions you might have.

Code Watch, our GitHub client for iPhone, is now available for sale on the App Store! Code Watch lets you stay on top of your GitHub projects by giving you easy access to your public and private repositories, news feed, followed users, and favorite public repos right from your phone. Learn more about the features Code Watch supports on our product page.

We’ve also built a free version of Code Watch designed for open source developers called Code Watch Open Source. It has all the same functionality as Code Watch for your public repositories and news feed. It’s perfect for developers with open source projects hosted on GitHub.

Check ‘em out and let us know what you think. Feature requests, bug reports, and other general feedback is always welcome.

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.