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.

While we’ve dropped a few hints on our website and elsewhere, today we’re making it official: High Order Bit is building a Lighthouse client for the iPhone.  We still have some work to do, and the polished product might look significantly different from the screenshot below, but it will be available sometime this summer.  Until then, check out our other iPhone development products and let us know what other development utilities you’d like to see on the iPhone.

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.