| Code by Kevin | |||||
|
Subscribe to RSS Feed 2010 2009 2008 2007 2006 Categories Business Software General |
home :: business
Sun, 25 Apr 2010 Sometimes, good enough isn't good enough. A few months ago I suggested that perfection wasn't the ideal goal in software; instead I championed "good enough," a strategy that lets you get a product out the door that does most of what needs to be done. "Good enough" is indeed useful for shipping products, but I've come to the conclusion that perfection isn't such a bad goal after all--if you define "perfection" as a long-term goal that you strive for over multiple product releases. Even if you don't reach perfection, you still improve. The reason I'm re-considering the goal of "good enough" is that I'm still quite unhappy with some of the additions I've made to my programming toolkit--specifically, integration of Tcl/Tk with drag-and-drop on the Mac, and accessing the Services menu from Tcl/Tk applications. You can drag files and text to my Tk applications, and they provide a service that can be accessed from the Services menu. But that's a one-way street; currently, you can't drag items from a Tk application to other applications, and you can't access the Services menu from my Tk programs. This feels incomplete to me. So, over the past month or so, I've been working on improvements in these areas. I've gotten a working implementation of Tk applications as a "drag source" committed to TkDND's source code archive, and I've completely rewritten my Tcl Services package to properly integrate with Cocoa's Services API, both in sending data to Tk applications and accessing the Services menu from Tk applications; in the case of the Tcl Services package, it's a rare instance where a complete re-write makes sense. In fact, after a bit more stress-testing of the Tcl Services package in my own programs, I plan to add it to my growing list of Tcl extensions that provide integration of Tcl/Tk with various aspects of the Cocoa API. I still don't feel compelled to revisit AppleScript support and printing support in my programs; there, the current implementation is truly "good enough," in that it satisfies all my current and projected use cases, and where a re-write would represent a huge amount of work with only a marginal improvement in the functionality offered by my current packages. Look for these new improvements in new releases of my apps in the near future. Fri, 26 Mar 2010I was trying to think today of the last time I received a complaint about the user interfaces of my programs. The last time I can remember was last August, when NameFind received some pretty harsh criticism during a MacZot promotion. This was right before I began the big push to migrate my applications to Tk-Cocoa, to improve the UI style of the applications, and to improve their integration with Mac-specific technologies. The only integration issue I'm still dealing with is a fuller implementation of drag-and-drop, which I'm working on as part of an update to NameFind. I think those changes have paid off quite nicely. I still get complaints about the price of my applications, I still get complaints about crashes because of third-party extensions on Snow Leopard, and I still get complaints about specific features and functionality--but I don't get complaints about look-and-feel, platform-integration issues. Even if my programs are not perfect in this regard, they're good enough. So what now? For the past couple of years, at least, I've focused more on platform integration than on features in my programs. In other words, I've focused on improving and refining the user experience rather than offering lots of new functionality. This isn't a bad strategy. But I think now the time has come to shift the balance back toward development of application features, rather than improving the platform I use to develop my programs. While those platform improvements can be rolled into every one of my programs, they can't be applied in an across-the-board way to the problems that each program is designed to solve. I've already started moving in this direction. Updates to QuickWho and Manpower included some common features--AppleScript and Services support, most prominently--but also some differences, including price adjustments to different levels. By contrast, my update of PacketStream had more application-specific changes, no price change, and no integration with AppleScript or Services, because such features don't really make sense in this application's domain. NameFind, next on the update list, will get some application-specific changes, and also one big remaining platform feature that I'm working on at the same time: drag-and-drop. And the last two the last two current applications on the update cycle, PortAuthority and Phynchronicity, will likely get more application-specific changes. At that point, I'll be ready to work on some entirely new applications, which I've been planning for a couple of years but postponed because of my need to work on the platform level, rather than the application level. It's my hope that as I'm moving my application focus to a different level, I'll be moving my sales to a different level as well. Wed, 24 Feb 2010Readers of this blog will notice that I've lowered prices on two of my products recently. You should not, however, assume that I'm going to lower prices across the board as I release new products. In the past I've tended to charge the same prices for all of my programs; once I set a price point for one product, the rest went to that price point as well. But I've found this actually isn't the smartest way to set prices, since it's more rooted in a desire to be consistent than in finding the right pricing balance between my product and the market. Some products, of course, are selling quite well at their current price point, and I see no reason to lower those particular prices.
I've added a user forum section to the Code by Kevin website. This is a place for users of my products to post questions and suggestions about these products, the website, and other related subjects. I hope that users of my software will find the forum site a useful resource. The forum is here: http://www.codebykevin.com/forum/. Enjoy. Sun, 31 Jan 2010
The perfect is the enemy of revenue
Even though I've made a great deal of progress over the past year in enhancing the native integration of my programs on the Mac, I'm not entirely satisfied. My programs can now support text and files dragged to them, but you can't drag text from them to other applications. They can now be called from AppleScript, and they support the Services menu, but you can't access the Services menu from within my programs. And while my programs can now print with nice, "sheet"-style dialogs, they don't print using Cocoa API's. The question before me: is it better to release software that doesn't support these nice features in their entirety, or would it have been better for me to wait until the features worked perfectly? This is actually a dilemma that all software developers wrestle with. Marissa Mayer, Google's vice president of search and user experience, favors an incremental release process and continuous improvement. Apple, by contrast, favors "insanely great" products that are little gems of perfection. Many indie developers in the Mac community tend to embrace the Apple view of things. In the words of Brent Simmons, "You make beautiful hardware and software--you create an experience so new and compelling that people lust for these things." In practice, and also in philosophy, I tend to come down more on the other side--releasing even if it ain't perfect. This doesn't mean I ship programs that fail to work as advertised, that are glaringly buggy, or that lack any useful features. Some proponents of "release early, release often" see no problem with releasing stuff that crashes--hey, it's a chance to identify bugs! However, I do embrace Voltaire's maxim that "the perfect is the enemy of the good." In software terms, this translates to, "the perfect is the enemy of the released product." There's no opportunity for a perfect product to make money if it's not in released form. In terms of my products, this means that I'd rather partially implement the easy part of a useful feature than delay release indefinitely for a complete, perfect implementation. This has been my approach with drag-and-drop, AppleScript support, Services, and printing. The parts that I implemented were the relatively easy parts--and even those aren't easy. Drag-and-drop took several weeks, and a good deal of collaboration with the original creator of the TkDND extension, to implement dragging to a Tk window. Dragging text out of a Tk window is much, much harder because of technical conflicts between Tk and the underlying Cocoa foundation. I had no idea how long it might take to work through these conflicts, or even if I had the skill to do so. So I decided to move ahead with what I had. AppleScript support is another incomplete, difficult feature to implement. My Python programs actually have the hooks in place to provide extensive AppleScript support--implementing AppleScript commands that other applications can call--through the excellent appscript Python library. However, my Tcl applications can't provide the same level of support because the standard Tcl library for AppleScript support, TclAE, will need an extensive rewrite to support 64-bit--a rewrite I currently lack the skills to undertake. Instead, if I want to offer AppleScript support, I'll have to use Tcl's built-in "do script" AppleScript command--which means I'll have to implement raw Tcl commands that other applications can call via AppleScript. Functional, but hardly perfect. Services is yet another feature where the implementation isn't as perfect as I'd like. For technical reasons similar to the issues with drag-and-drop, my Tcl and Python programs can't access the Services menu from within the application itself. And they can only export Services functionality because I discovered a handy tool called ThisService, which allows you to create Services from scripting languages. I'm using the AppleScript support my programs are implementing to add the Services functionality as well. (I tried to create a Cocoa extension that would hook into the Mac's Services functionality, but was not successful--again, technical conflicts between Cocoa and Tcl that I could not work through.) While I feel my solution using the ThisService tool and AppleScript was elegant and actually quite clever, it's certainly not perfect. Finally, printing. It would be nice to support native printing. Yet the Mac's built-in command-line interface to printing is so adequate for my needs that it's hard to muster too much worry about the lack of Cocoa-native printing in my programs. My thinking about these issues is guided by more than just my desire to earn revenue by shipping products. It's also guided by the Unix philosophy of programming, which I've written about before. The key idea I'm taking away from the Unix philosophy is "keep it simple, stupid." If I can adequately implement a feature that is effective if imperfect, it's better to go that route than wait indefinitely for perfection. It's hard to say, at this point, if I'll ever perfectly implement drag-and-drop, AppleScript, Services, or printing in my programs. In 2010, my goal is to release commercial products, not open-source libraries. That means building on what I have; it's good enough. Waiting for perfection means waiting for revenue. Tue, 12 Jan 2010
Postmortem on 2009, and looking forward in 2010
At the end of 2008, I posted a blog entry on what I learned that year. I didn't have time to do anything similar at the end of 2009, so I'm carrying it over into 2010. Which is appropriate, given that I am now more interested in looking forward than looking back. 2009 was mostly a transitional year, in which most of the lessons of 2008 provided irrelevant. In 2008 I talked a lot about the importance of marketing. Regardless of my marketing strategy, the Great Recession kept sales down, down, down. I also complained about the difficulty of learning Cocoa and swore I'd never do it. But most of my technological work in 2009 was spent in learning various aspects of Cocoa and applying it to Tk, which itself was ported to Cocoa by Daniel Steffen. And finally, I said I'd add a lot of new products; instead I revived one I previously discontinued, and released incremental updates of everything else. (The single biggest upgrade of all my apps was moving them from Tk-Carbon to Tk-Cocoa and 64-bit capability, as well as UI freshening.) I now enter 2010 a much stronger developer than I was a year ago: I can delve into lower-level technologies when necessary (Cocoa), while still taking advantage of the rapid development features of my primary programming languages. My toolbox is much richer than it was a year ago, and with drag-and-drop, native icons, custom dock icons, sheet windows, and AppleScript and Services support, my programs will be much better Mac citizens: these are real improvements in usability, functionality, and the user experience. Now that I've greatly broadened my development skills, however, it's now time to begin applying it to my programs in a substantial way. The first task, of course, is to integrate these new features into my programs in appropriate ways. The next task is to explore opportunities for new applications, opportunities that my new skills now make available. I have lots of ideas, and lots of interests: the challenge will be to translate those ideas into products that users find compelling enough to pay for. I want to improve my sales in 2010 as much as I improved my development skills in 20009. I think I'm finally in a position to do that. Sales really surged in the last two months of 2009, to the point where sales finished at the same level as 2008--a pleasant surprise, given how slowly the year started. There's still a lot of room for improvement, but like a last-place football team that wins its last four games, I've gained some momentum. I attribute the sales spike to moving my applications to Cocoa: some of the user feedback I've gotten suggests this has made a big difference. As far as marketing, my product mix, and pricing, I've gathered some data about what works and what doesn't, and will keep working on that as the year goes on. Bottom line: despite the difficulties of the past year, I feel more optimistic about my software business than ever before. I'll be working hard to bring cool and useful products to the table in 2010. Sat, 17 Oct 2009After launching Cocoa-based versions of all my applications last week, my server was hammered by download traffic. This was the largest release I'd ever done, and the download size of all the applications was larger than before (a consequence of adding universal 64-bit support). As a result, I received numerous complaints about slow downloads or, worse, inaccessible downloads. Too much traffic is a good problem to have, but paradoxically, there's a danger that I might lose customers. To quote Yogi Berra on a fashionable restaurant: "Nobody goes there anymore. It's too crowded." That problem has been solved by moving my download links to Amazon S3, a cloud-based Internet storage service managed by Amazon. S3 is an inexpensive solution for Internet-based storage and downloads, and other Mac indie developers have recommended it highly. As a result, traffic on my server is back to normal, and downloads should proceed at a snappier pace. If you've been trying to download one of my apps but found it impossible, try again--you won't be disappointed. Wed, 26 Aug 2009I'm a great admirer of Gus Mueller, the main developer at Flying Meat Software. He's one of the leading indie Mac developers out there: his desktop wiki VoodooPad and his image editor Acorn are leaders in their categories. A few years ago he posted a blog entry that outlined his path to indie success, and it has served as an inspiration for many indie Mac developers, myself included. Given my admiration for him, I was a bit taken aback by the curmudgeonly tone of his latest blog entry. A bit of context: Gus's blog entry is based in turn on an Inc. article by Joel Spolsky of Fog Creek Software about how his software company took off: founded right at the moment of the dot-com crash of 2000, Fog Creek struggled financially, laid off employees, found some unexpected success with its bug tracking product FogBugz, tried all sorts of marketing gimmicks to improve sales, then finally settled in to simply improving the product itself, after which sales took off. There's wisdom here. All the marketing glitz in the world won't help if your product is terrible, or doesn't meet user needs. Marketing helps, but it isn't a substitute for having a great product to sell. Gus notes that his experience has been similar: improving his own products has been the biggest factor in the growth of his business. And he suggests that if other indie developers aren't succeeding, they should take a look at their own products: Learn to be your best critic, and you'll learn to ship software that's worth paying for. If no one is buying your app then you've either got a dud and you need to focus on something else, or you need to improve your app so it's worth paying for. And some apps, no matter how flashy or awesome or genuinely useful, will never make money. His assumptions here are bit surprising: that if someone's application isn't selling, it must be because they aren't self-critical enough. That might be true; the developer might be impervious to feedback, and even have a reputation for being hostile to user input. But it might also be that the product is in a highly competitive market niche. It might also be that there's little demand for the product. It might also be that the product is in the wrong place at the wrong time. Business success is an inexact process. Quite simply, it's a gamble. If you look at some of Joel Spolsky's other articles, you'll see that luck played a big role in his success. One of his products, FogBugz, took off; another one, CityDesk, did not. Although Gus notes that "some apps...will never make money," I think he underestimates how much luck plays a role. Applying these lessons to my own software business, I reach the following conclusions:
Having said this, taking Gus's advice and serving as my own toughest critic, I also have to acknowledge: my apps don't sell as much as I'd like. I'm not a full-time indie developer, like Gus. And (bad) luck isn't solely to blame here. Or, to pose the question, "Why don't my apps sell," I could paraphrase Gus: "Maybe they just suck?" Well, some people seem to think so. NameFind got a harsh reception at MacZot the other day; at least one user disparaged my professionalism as well as noting specific criticisms of the app itself. (Even amid all the flaming, I extracted at least two suggestions that I will use for further improvement of NameFind, so thanks.) Most of that user's complaints stem from the fact that NameFind isn't written in Objective-C and Interface Builder; it doesn't hook very deeply into Cocoa. (Parts of it do, but not the whole thing.) That's an unavoidable limitation of my software since I don't develop directly in Cocoa but rather with a toolkit that uses Cocoa for basic UI elements that it organizes using its own API. I have to take my lumps there with whatever "suck" factor might apply. (Some users care more about this than others.) So I concede a certain amount of lost sales because Cocoa's not part of the equation. I don't believe that's the totality of it, however. Some of my products target niches with established competitors. I probably don't market as much as I should. And, at the end of the day, not every product is going to take off. (Gus himself has discontinued one or two slow sellers over the years.) Bottom line, it's darn hard to be a success as an indie developer. For every established indie Cocoa developer like Gus, there are probably a dozen indie Cocoa developers whose businesses haven't taken off, for whatever reason. I'll bet dollars-to-donuts that most of those developers are tough self-critics, strive to create the best products possible, and provide user support to the best of their ability. (In short, there are probably more Cocoa developers whose business looks like mine than those whose business looks like Gus's.) Getting back to the title of this blog entry: I think my priorities are in the right place. It's no guarantee of anything. Sun, 14 Jun 2009I've done a bit more tweaking to the Code by Kevin website, and now I'd like to highlight those changes:
After all these changes, I've pleased with the new look and usability of the site. Now it's back to product development, incorporating the latest and greatest from Tk-Cocoa. I'm just waiting for a few more bug fixes and patches to go into TK-Cocoa in the next couple of weeks, and then Tk-Cocoa will move from the "development" branch of Tcl/Tk to the main line of the codebase. At that point, I'll be able to quickly get out a few new products, and I'll also post a detailed blog entry about the improvements that Tk-Cocoa is allowing for my software. Tue, 09 Jun 2009After getting some feedback on the Code by Kevin website at the Joel on Software business fourm, I've made some pretty significant changes to the site's design. I hope it's simpler and easier to navigate. I welcome any feedback! |
||||