The growing pains of NGEDIT

Sorry for the delay – I finally have spent several days with the flu, which isn’t the best premise to do anything useful.

When I released ViEmu, the past July 26th, I talked to a friend and told him “step one.” It is quite true: that was only the first step. One month later, I have released a new version incorporating suggestions from customers, I have had a few reviews (mostly positive, although some point to some limitations, and others simply wonder about the whole idea), and have had a few sales. The same way as myself, even if vi command line support is not present yet, some people have found using the vi/vim input model within VS a big win. My site is nowhere to be seen on Google results for obvious searches like “visual studio vi emulation” (although it once was something like #12, it has disappeared into oblivion), but I have an adwords campaign set up to handle that, and it indeed is #1 in similar searches on MSN or Yahoo.

I’m very happy to have a product actually released and customers using it. I have already learnt a lot about setting up the sales & marketing, deployment issues, receiving and acting upon customer feedback, and, overall, about the whole development-release-sales cycle. I’ve even learnt how to prepare a Microsoft Installer (.msi) file to perform automatic upgrades (for which the most similar analogy I can think of is drilling a whole on your skull.)

Now I have to think what the next steps are. I now have two “babies” to take care of: ViEmu and NGEDIT.

The next step for ViEmu is clear: adding “ex” commands support (the vi command line which allows gems such as :v/./.,/./-1join to compress empty lines, and similar useful tasks.)

As an aside, it would be good on one hand to “back-port” the vi/vim emulation to NGEDIT. The emulation in ViEmu is implemented in C++ (originally ported from the NGEDIT Scripting Language), and is now much more complete that the original.

And as a second aside, some refactoring of NGEDIT is in order, now that I can see the code with more critical eyes (thanks to the perspective gained in two months of not touching the codebase.) I’ve actually already started with this, which is also a good way to get familiar again with the code of NGEDIT (it’s already an almost 50k+ lines of code small beast.)

But these last two are minor tasks which shouldn’t take too long. The vi/ex command line support is more work, but I will surely work it out in the following weeks/months: I need to do a regular expression engine (which I plan to share between both products), and a parser for the ex commands, which shouldn’t be too bad. (Note: following with my tradition of technical postings, I’ll probably explain how I implement regular expression support – no, I won’t use any off-the-shelf libraries, in part because of the functionality I want to provide, but also probably due to my severe case of the Not-Invented-Here syndrome.)

The main area that needed a full reevaluation was how to tackle the development of NGEDIT itself. I’ve actually thought a new development and release strategy/roadmap, but let me first expose the preliminaries.

I have some ideas for what I think will be “killer” features for a text editor. I may be wrong, but please bear with me and assume that’s the case. The reason I decided to develop a text editor was the thought of these features, as the text editor market is already quite saturated.

Blindly as I do think about the value of the new features, I initially thought that other editor developers would be ripping them off as soon as NGEDIT is out. Maybe it is unwarranted precaution, but I decided to first develop a quite complete text editor, which would be mostly up to par with current editors (probably not Visual SlickEdit, which is probably the most feature-loaded editor there is, but definitely with other popular text editors such as UltraEdit.) This way, I wouldn’t lose my edge with the new stuff.

It turned out that the whole set of features that a modern text editor has is a heckuva lot of work to develop. I initially thought this part would be less work, but it turns out that all of the development work in NGEDIT has only started to get it into what other editors offer. Actually, I haven’t even started designing or implemented the actual innovative features of NGEDIT (and they do require quite a lot of research!)

Now comes the experience of ViEmu. The kind of “echo” that ViEmu has received has been a bit less than I expected. Probably releasing in August is not the best moment, equally probably I should wait a bit more than a month before evaluating the result, and probably it will take a bit of time and probably some more versions released until it becomes more widely known. But I have found out that, even if the internet is a great resonance chamber which creates a great echo of remarkable products, it behaves as a dense and difficult-to-travel information mesh to those products that are not remarkable, or which target a too small group.

I can’t help but think that ViEmu is targetting those who are “vi lovers”, probably much less than 5% of the developers, which themselves are probably less than 5% of the general software-buying public. 5% times 5% is about 0,25% of the potential software buying audience (and, yes, this is a bit of a faux argument, as you can never target 100% of the audience, but yet my point about how ViEmu is a very niche product is still valid.)

NGEDIT is a general purpose text editor, which already targets a much wider audience than ViEmu. This makes it a better starting point in order to generate a profitable business. But then, one thing is easy to see: even if I develop an editor with the 14,273 or so features other text editors have, that won’t make it remarkable. I could spend one year implementing everything down to spell checking, FTP file access, and emulation of some obscure and forgotten editor’s command set, and even then I would still have a slow start.

The point about usability is important, and will help it become a successful product, but yet that’s not something that creates its own phenomenon.

Fortunately, I have the “killer” features to try to create a remarkable product. But then, does it make sense to spend a bunch of time to have just a “standard” product before I even start with them?

On the other hand, I’ve realized one thing: not only vi emulation is something that (at most) 5% of the users of a text editor miss, even regular expressions are something that is not used daily (or at all!) by many programmers.

And as a final element, my motivation starts to decline if my work consist in coding known-feature-after-known-feature. And given that I have created a quite powerful underlying technology framework, the codebase looks a bit like a Gruyere cheese full of holes that are designed-in but not filled in yet, such as double-byte character set support, filling in the template code for a lot of template-based-generalized elements, completing the scripting framework, plug-in support, etc… All these promise a lot of not-too-creative code-churning hours.

Meanwhile, I’m really eager to start researching, designing and developing the new features.

So, I’ve figured out there is a much more sensible strategy to NGEDIT. Put it the short way, I will be focusing in the innovative features, and leaving the “completeness” in comparison to other editors as an aside. I have two or three basic tasks to perform before actually starting with them, partly due to a few early wrong decisions which require a bit of code refactoring, but basically I think I will be able to start with them this week.

I’ve changed my immediate focus from the-complete-text-editor to a-nice-little-editor-with-nifty-stuff. I am currently using it myself, as I make changes, and focusing in making a better tool for me than vim or Visual Studio with ViEmu. If I can achieve that, I have the confidence it will be likewise for other people (even if other people don’t focus on vi-like editing, of course, the new features have nothing to do with that.)

I also know, from other projects and even other disciplines, that when you focus on immediate use, many other issues become apparent and pieces start to fall in place, and even completeness comes along.

Regarding the point of staying ahead of other text editors, or at least not too far behind, I think I have probably overestimated the risk. Even if it is successful, NGEDIT will take some time to catch on, which is usually measured in months, and I will be able to employ that time in getting the checklist features that are missing from NGEDIT (although probably not yet C++ Intellisense, but that’s not so common either.)

I’m using NGEDIT as a I go along. Developing a text editor is good in that you can use and test it for its own development. On the other hand, it is a bit of a mess. Even if you get a bit organized, and prepare deployment releases and don’t use the bleeding-edge last build (as I had to do for ViEmu in an even more complex interaction involving the IDE), it is still a bit of a mess. So, what I am doing is to develop the regular expression library with NGEDIT, which I start from Visual Studio itself, and the whole process is a bit less messy. And ViEmu then also benefits from this, even if it does require a bit of mental task-switching.

So: I’m focusing on bringing NGEDIT 1.0 as a very innovative editor, if not as feature-complete as existing editors, and I’m really pleased that I’ve taken this decission, which I think makes sense both development- and business-wise.

And only time will tell if the strategy was right, but then this is a bet!

This entry was posted on Monday, August 29th, 2005 at 11:31 pm and is filed under ngdev. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.