Category Archives: Software

StoryBox 1.1.92 Released

For the second time this week, I’ve released a build, only to have someone report an annoying bug right after I released it.

I have heard rumors for a couple weeks of an annoying issue where, on start up, people would get a cascade of error messages, mostly after a first install (mostly on upgrades, I think). No one had reported real information until today, though. Report it, I fix it.

The problem was that the theme info went missing for some reason. I put a band-aid on it. Now, with this fix, if you WERE going to run into this issue, it will default to the silver theme.

Unlike Monday, I added a couple of features to this build to ease the pain of a second install. You can now add documents by right clicking in the Storyboard and Outline views.

http://www.storyboxsoftware.com/download.htm

StoryBox 1.1.91 Released

This latest version of StoryBox adds a new “Act” document type to let those of you who like even more structure work more easily with more structure. There are is also a fix for those with European date styles and the statistics. I tried to fix the dates in the project when the project loads, but if your statistics don’t show up, send me the project in a bug report and I’ll fix it by hand.

I think I fixed the never shuts down bug, too. I know I fixed it in one case. I hope it translates to others.

http://www.storyboxsoftware.com/download.htm

Still In St. George

Today was the last day of David Farland’s Writers Death Camp, and at this point, my brain is a bit mushy, but I’m super excited to get home and really get back to a semi-normal existence. I learned a lot. My writing, and my understanding of my writing and writing stories in general improved significantly.

Because of my new understanding, StoryBox will be getting some features that I have decided are essential to continuing to improve my writing. These will include some outlining tools, editing tools and brainstorming tools, and plot construction tools. These tools will be added on, and for the most part, you won’t be required to change your current work flow if you like what StoryBox does now.

When I am done, no other writing software will have the combination of tools that StoryBox will have, and I think these tools will provide users of StoryBox an absolutely huge advantage over users of other pieces of writing software.

In St. George

I’m here in St George, Utah now after a flight to Las Vegas (there was some concern on some persons parts as to whether I’d get stuck there) and a nice drive. I’m as excited as can be for the Writer’s Death Camp to get started tomorrow. Six days of death? I can’t wait.

Updates for StoryBox will resume when I return.

Why I Don't Make Betas

I’ve been watching the results of the first Beta of another piece of software the last couple days by a developer we’ll call BetaMaker. I even tried it out. It has problems, like every other incomplete piece of software. The sheer number of problems is larger than I expected, and I’ve been trying to understand why that would be.

Ultimately, I think it stems from using large scale development methodology with a small scale team.

Everyone who has used software on a computer for any length of time these days understands what a beta is. It’s a version of the software that is incomplete and may have bugs. Usually, a beta build comes after an alpha build that is not made public. A beta build is often the first public release of a piece of software.

Beta’s work great for large teams making large pieces of software. They generally have testing resources that test each build on large numbers of configurations of computers over the course of the development cycle. Beta’s are generally supposed to be feature complete, and close to release, but may have bugs.

I’m a lone developer. I have a limited number of fingers, eyes, and brains (some might suggest that my brains are more limited than other parts). I also have a limited number of computers. In other words, I can’t replicate the testing that goes on in a large development team employing a typical development cycle.

Developers create bugs while they are writing software. They don’t see them for any number of reasons, including poor planning, incomplete understanding of the problem space, blindness, and fatigue, among others. Bugs are easiest to fix when they are caught close to the time that they are created. The code is fresh in the developers mind and there aren’t layers and layers of other code on top of what was just done.

Since I can’t code and test at the same time, and I have other limited resources, if I followed the alpha, beta, release style of development, when I reached beta, there would have likely been a large number of bugs lurking that are hard to find because they exist in code I hadn’t looked at in six months or more. This, I think, is what’s happening to BetaMaker.

To solve that problem, I do lots of incremental releases with a limited number of changes. You get new features on a regular basis and the bugs that slip out are quickly fixed when found. The best thing is that StoryBox has been relatively stable since about three months into development, unlike BetaMaker who spent two years building something without anyone seeing it, only to find themselves snowed under with issues.