September 4th, 2009

My thoughts on transparency in software development got me thinking about a particular application that I use on a daily basis, Coda. I think it is safe to say that most Coda users, of which I consulted six for this post, are not just Coda users, they are Coda plus other software users. Why? Because Coda doesn’t do everything that Web developers need it to do. It may never do everything and that’s ok with Panic.

Textmate users, on the other hand, are a slightly different breed. The application has been around a little longer, has a richer plugin architecture, and those two facts help to fill in more of the holes in a Web developers workflow. That being said, many people wish they could switch to Coda full time. With each update Panic makes to Coda this becomes more a reality.

I was thinking about getting into specific features that Coda does not have that Textmate does – but that isn’t the point of this post. I’ve since polled the developers that I’ve spoken with and created the list based on their priority and sent it to Panic to do with whatever they’d like. Now, back to the point.

But how do Web developers know which application is right for them? How do they know which application, or applications, to invest in? In the case of Coda – should they buy the two or three applications that they need to complete their workflow or should they wait for Coda to support it? In many cases developers own both Textmate and Coda and flip back and forth between the two of them.

If you remember the example in Thoughts on transparency in software development, the “I want to print a photo that I received in email” example, someone would have invested in three separate applications only to have those features included in one application later on. Not necessarily a waste of money, since you were able to view and print images for the time the email application did not support those features, but it would have been nice to know it was coming.

In a recent email interview with Panic co-founders Steven Frank and Cabel Sasser we discussed this issue and also managed to peer inside the minds of the Portland based software development company. The veil over Panic may be lifted in the near future (or at the very least sewn with a different thread count), the speed at which updates to their products are published may quicken, and customer’s of Panic may be able to make wise decisions based on having information instead of simply guessing. But all of that will come with time. For now, lets focus on just a few simple questions to see where Coda is at currently.

I asked both Cabel and Steven a few questions about Coda and they were nice enough to answer. For the record, I sent these questions to Panic’s co-founders on the very last day of July. It is now September 4th and Coda is currently at version 1.6.5, not 1.6.4.

1. Coda is currently at version 1.6.4. It is over two years old. Being a veteran of launching software applications how has Coda done in the eyes of Panic?

Steven: We’re very happy with Coda’s performance in the market. It’s funny, Transmit hasn’t had a big “feature” update in 4 years, and we hardly ever hear anything about that. Coda is different. We get asked every day when the next version is coming. I take that as a sign of great enthusiasm. People like what it can do, and just like us, they see the potential for it to do more. I know that, personally, the software I’m most vocal about is the software I use and like the most — it’s about making something good even better. We’re very actively developing both of these apps.

2. Software companies that have smaller applications generally put out more releases more often than a company like Panic with an application like Coda. It has taken over two years to get to 1.6.4. Would you rather the pace that you’re currently operating at or would you like to give the users of Coda more updates more often?

Steven: Because Coda is such a young product (1.x) we are getting a lot of both feature requests and bug reports. It’s hard to balance the two, because obviously you want to fix bugs in the existing functionality, but you also want to keep new, fresh ideas coming into the product.

I think with Coda, we’re definitely seeing that people would like more frequent smaller releases, rather than fewer big releases, which is not something that has always been the case for us. It’s not how we’ve traditionally operated, so I think it’s taking some time to turn the ship.

We also haven’t been the greatest at communicating with users, in my opinion. Historically, we’ve followed Apple’s example of not pre-announcing anything before its time. Cabel and I have been talking at length lately about whether this continues to make sense and to what degree. Obviously, we don’t want to lay out our entire roadmap for our competitors, but it’s clear that people increasingly demand more open lines of communication with the companies they do business with.

It is kind of funny though — you don’t see as much criticism when, say, DreamWeaver goes a few months without an update, and that product costs four times as much as Coda. I find it interesting that smaller companies are held to a higher standard at a lower price.

3. Coda is gorgeous. Apple has even copied from it. As a Viddler team member I remember Cabel’s presentation at C4[1], Jonathan ‘Wolf’ Rentzsch‘s most excellent Mac development conference, being a very popular video. Has there been any UI challenges that you’ve faced since 1.0 that you’ve had to tackle, overcome, and are subsequently happy with?

Cabel: There are two classic, long-standing Coda UI challenges that haunt us. The first one is tricky and wound up becoming a preference: if the sidebar items should be double clicked, or single clicked. “iApps” have single-click sidebars, but our sidebar is special in that it’s basically a miniature Finder — and in the Finder, you single click to select, and double click to open. The second is that some of our tools are alternate views of the same document (Edit, Preview, CSS) and some are tools layered on top of your document (Books, Terminal). The fact that you can switch to Terminal and have a live, active document “underneath” terminal has never been very clear.

These are the two biggies we’re always thinking about!

As for things that we’ve added since 1.0 that we’ve been happy about, I was happy with our solution to “Find Within Files”, added in Coda 1.5. We tried a lot of approaches to wedging in an extra “find in files” interface into the existing find bar, until I realized that we could extend the find bar over the files list itself, and put file-specific options over there. As a result, it’s a huge new feature with minimal UI impact! That’s always a nice feeling.

4. What is the version number for the next version of Coda? Care to talk a little bit about: the amount of work that has gone into it, how many people work on Coda, and perhaps leak out something that is slated to be in it?

Steven: The next stop for Coda is 2.0. We are making improvements across the board, but are putting most of our effort into editor features, since that’s where people spend 80-90% of their time in a product like Coda. After we added Subversion support, code-folding was without question the next most requested feature, and I think it’s not much of a secret any more that we will have folding in 2.0.

Editor’s note: I’m very glad to know that code folding is included in the next major update of Coda.

I’m disappointed, however, that Steven decided not to answer how long it takes to work on a build of Coda and how many people Panic has contributing to its code base, design, QA, etc. I’d love to know more about this process at Panic and if anyone at Panic would be willing to put those details in the comments of this post, I think other people would be interested in that information also.

5. There is no way that Panic can possibly put everything into Coda that people want. Do you know of any features, or a feature, that you know will never, ever, ever be in Coda?

Steven: I don’t like the word “never”. But I think it’s fair to say that we are not particularly interested in evolving Coda too far in the direction of WYSIWYG editing. We want to focus on the hand-coding workflow. (Although, there’s always room for a plug-in to do something here. So, again, never say never.)

6. No matter how much you jam into the next version of Coda developers will always need to hop between Coda and other applications to do some of the things they need for their workflow. Coda may, at some point, take care of some these things but developers will never really know until it comes out. Is this something Panic thinks about? Cares about? Would like to do better at? Or, is this simply the nature of the software development business?

Steven: We try to cover everything we feel the majority of people are likely to need, and want to evolve our plug-in API to help fill in any gaps. We’ve already seen some amazing things done with the limited plug-in API that was introduced in 1.5. But if you look at any support forum on the net, all software is missing one crucial feature for somebody, even software that’s been around for decades. Trying to please absolutely everyone will drive a developer mad, and usually makes the product worse in the general case.

7. Have the new offices made Panic more productive? Care to share an exclusive photo of the team at Panic HQ?

Steven: The new office is great. We’re no longer elbow-to-elbow and have a wonderful creative atmosphere to foster growth. And our internet connection is much faster!

Editor’s note: Although Steven and Cabel didn’t give up an exclusive photo I found this photo of their offices on Flickr. Elbow room indeed.

I’m very happy that Panic is considering new ideas on how they can be more transparent than they currently are about forthcoming updates to their products. No matter how they choose to solve this issue it will be a step in the right direction.

Steven brought out an excellent point in his answer to question #6 when he said it is funny that companies like Panic are held to a higher standard than companies like Adobe in the matter of corporate transparency. Although it is true I think there is solid reasoning why people wish companies like Panic would lead the way in this regard. Because they feel as though they know Panic. Do you know the names of the, no doubt incredibly talented, people that work on Dreamweaver? Have you ever sent an email to Adobe with 6 questions about transparency and the next version of Dreamweaver and receive a response? Probably not. I believe smaller companies like Panic are held to a higher standard because people hope that these sized companies are listening and can change much more rapidly than a corporate giant.

Thanks to both Cabel and Steven for answering the questions and for all of their team’s hard work on their products.

Thanks to Jon Christopher, Andrew Smith, Chris Coleman, Jake Dahn, and everyone else that contributed to this interview.