Here’s a quick status update of what I’m working on and thinking about with Bike.
First the holidays slowed me down… which is good, but it means I don’t have any cool new features that I’ll be releasing soon.
I’ve been working on accessibility, but ran into some problems. Many of the accessibility API’s use UTF16 offsets while Bike uses Line/Char for addressing text positions. It’s expensive to translate between these two addressing systems with my current outline data structure, which is just an array of rows.
The right design is to use a tree structure which will make those sorts of translations fast and clean. And generally a tree structure to index outline content will help in a lot of areas… but it also means changing Bikes internals from the current “simplest possibly thing that could work” to the “right design”.
Of course the problem with the “right design” is you want to get it all “right”, and that can be difficult and take forever to finish. On the other hand if you do get the right design it makes everything faster and cleaner. Hard to know which side of “forever to finish” vrs “faster and cleaner” you are on.
That’s where I am now.
Going forward:
I will likely continue to play with different data structure designs this week.
There are a few bugs (Korean text input and find results count) that I will try to fix in a small point release also sometime this week.
Will reevaluate on Friday and decide if I should go forward improving internals or if I should put that work on hold (along with accessibility) and work on other easier to implement features.
Here’s one vote for improving internals. While there are plenty of additional features I would like to see, I’m happily/heavily using Bike with its existing feature set, and I think the “right design” is the most important thing at this still-early point in Bike’s life.
I am also of the opinion that the right design is critical and I am surprised that it needs revisiting so early but it is better to do it now than later.
In Jesse’s defense, my experience working with software projects is that it’s not at all unusual for experience with the product to be necessary before major decision questions reveal themselves. All too often the pressure to continue to develop new features keeps them from ever being addressed.
I don’t think any defence is needed – the quality of software, particularly software which is exploring new spaces, is a function of the amplitude of its implement-and-refactor cycle.
( perhaps less familiar in some other fields of work ? )
As always work goes slower than I expect, but I’m also making progress. I created a bunch of one-off test projects. I think I’ve built all the parts that I need, but they are in different one-off projects and need to be integrated into a unified single project. And then that needs to be integrated into Bike.
I do expect to keep working on this, but it’s likely more than a week out. I’ll keep working on it, but also need to not get too distracted and bug fix the current Bike release. If there’s not a bug fix release of Bike in preview mid next week please yell at me and tell me to get to real work!
I broke my rules and have still been spending a lot of time on better Bike internals.
I think, finally, the underlying data structure is “done” and performing well, but I haven’t integrated any of it with Bike yet. Before I get into integration I am going to take a break from this and work on more visible features for a bit.
