…so busy, in fact, that I’ve decided to take a blogging hiatus.

I’ve written a post a day for nearly two years straight, missing only a handful of days. I like that pace, and I plan to resume it, but not until I’ve got the bulk of Project M finished. That may be a few weeks or a few months, I won’t know until I’m a lot closer to that point.

I’ll still post on occasion if I find something interesting, but I haven’t had a lot of time to keep up with the news recently. (In fact, I’ve got nearly two months’ worth of news backed up to scan through… my blog entries have been relying on a cache of articles that I’d previously bookmarked as comment-worthy, which is nearly exhausted.)

For those keeping score at home, Project M is going quite well, but ridiculously slowly. In my previous projects, I sometimes took design shortcuts that I later regretted, and rarely tested things as well as I should have. This time, I’ve committed to designing the bones of the program right, from the ground up,¹ and writing automated testing suites for any components where they make sense. And any code that I come up with that looks usefully reusable is getting put into a library of cross-platform classes and functions, with at least a minimum of documentation, which will make it much easier for me to write new programs and much easier to get others (or myself, after time away from it) productive on the code in a minimum amount of time.

It’s a lot of extra time and effort up front, but it also means far fewer bugs later, and that I shouldn’t have to go back to redesign and rewrite large portions of code in order to add new features. That means less time later that I’ll have to spend on older programs, and more time I’m free to work on new ideas, which should directly improve the bottom line in the long run.

Software developers rarely get the opportunity to think long-term and do code right. Management always wants things done yesterday, and it doesn’t matter how much of a nightmare the code is behind the scenes because neither they nor the customer will ever see it. There are cases where that’s necessary, but I believe that investing extra in the design step will pay off big in the long run. We’ll see.

¹ For instance, I’ve spent the last several weeks coming up with a correct and easy-to-use design for handling Unicode strings in various encodings. One that makes it all but impossible to confuse, for example, variables holding ASCII strings and ones holding UTF-8-encoded strings, even though the two use the same underlying storage type. And makes it trivial to convert as needed between ASCII, UTF-8 for Linux and for storing Unicode in single-byte strings, the UTF-16 used for Windows Unicode, and UTF-32/UCS-4 for single-symbol-per-character string manipulation. That kind of design work fascinates me, and the classes I’ve come up with are a true joy to use.