In management circles, there is a running joke that the last five per cent of a project takes 95 per cent of the entire completion time. If you’re a software developer, this funny paradox may ring some bells because it is in fact well rooted in experience. Your project proceeds quickly until it reaches a point where it is almost finished, save for a few little things that make it unsuitable for release. These “few little things” can turn the final phase of the project into a nightmare that will drag for months, if not years.
I learned my own lesson when I was working on my first AmigaOS4 application, the WordNet dictionary, back in 2009. I had only recently rediscovered the Amiga passion after nine years of solely using a PC, and I was very excited about developing for a community where every new piece of software seemed to make a difference. I had a rough version of the program going in about two weeks, with GUI and all – and then I spent two more months polishing WordNet and getting it to release state! One of the reasons was that I had to learn some OS4 specifics as well as brush up on things I had forgotten. But in all honesty, it was my poor planning that caused most delay. The notion of the minimum viable product completely escaped me at the time, and I kept adding feature after feature until I was overtaken by fatigue and frustration.
It may appear that I fell into a similar trap with the Rave project, especially if you remember that in my previous blog post I was hoping to be able to release the program before the end of March. But the reason was different this time, and I can honestly say that the release would have happened if only things didn’t get the better of me again.
While stress-testing Rave in early spring I realized a design flaw in the program’s project management system that made it difficult to reliably and safely abort an operation in progress. As re-designing the inner workings of Rave would take a considerable amount of time (which I didn’t have), I thought I’d release the program as it was and improve it later. However, towards the end of March the school I work for informed me that I’d be supervising a group of students during their internship in Germany, which was supposed to take place in May. The idea of spending a whole week free of parenting pressures clicked with me in an instant, because it smelled like an opportunity to have a closer look at the problem.
The internship was in Chemnitz, a city in Saxony formerly known as Karl-Marx-Stadt. It soon became obvious that my students’ training was organized with the proverbial German thoroughness and efficiency, which rendered me virtually useless as a supervisor because everything had been taken care of. So I had even more time on my hands than I had expected, and (with the exception of an occasional sightseeing stroll) I spent most of the week in my room chasing bits and bytes on my trusty laptop.
The ability to concentrate on Rave for several hours a day made a world of difference, compared to my weary late-night sessions at home. I remember a forum post in which a well-meaning Amiga user tried to motivate developers by telling them to try and sit down to programming every day, even if for five minutes only. But this is not how it works, unfortunately. In reality a programmer can do little work in an hour, let alone five minutes – especially when working on a large project. In this regard the week in Chemnitz turned out to be a heaven sent. Diving in with full focus allowed me to completely rewrite the project management system including the plugin API and the I/O module; something that otherwise might take months to achieve. The result is a simpler design that is more reliable and requires less communication between the individual program components.
Among other things, it is now easier to create a plugin because the main program and the plugin master module have newly been entrusted with certain common chores. The plugin architecture surely needs more work: currently only processing plugins are supported, i.e. ones that take audio data and modify it. This is suitable for applying effects, but I’d also like to introduce plugins that generate sound, or simply analyze the data and display information about it. It’s going to take quite some time before the architecture becomes good enough, but when it does I’ll open it up so that other people can develop plugins for Rave if they feel like it.
And of course: the problem that started it all is now gone, so as I’ve already told people who follow me on Facebook or Ko-fi, any operation in progress – that includes loading, saving and processing – can now be safely aborted by pressing the Escape key. I actually think that Rave handles aborting better than SoundForge Audio Studio 16, which is my go-to editor on the PC. When you abort an operation in SoundForge, the program displays a confirmation requester but the operation continues uninterrupted. So if you take your time and don’t click on the “OK” button right away, the operation may have already finished in the meantime. I don’t find this very useful (or logical), to be honest. In Rave, the operation waits until you deal with the requester, and then it either continues or stops. This, I believe, is the expected behaviour, and it’s one of the benefits of my rewrite.
Most importantly, the program is now ready to hit the world. During the past year there were moments when I seriously doubted I’d ever be able to say it, but: I’m happy to report that the last five per cent of the project have been completed, and that the initial version of the Rave editor can finally be downloaded from OS4depot. Saying it feels so great that I’m tempted to say it again, which is plain silly but you can imagine how happy I am now that the weight is off my chest. It feels like dropping a stone the size of the Karl Marx head in Chemnitz!