Developing Chronotron is one of my hobbies. I started this project about 20 years ago as a companion tool to improve my guitar playing abilities. The software has improved a lot since then, though I wish I could say the same of my musical abilities (sigh).

While I don’t spend the entirety of my spare time developing Chronotron, the approach to maintaining, fixing and improving the app is a disciplined one. As a matter of fact, it is because I can’t spend so much time on it that being methodical is a must.

In this post I’ll give you a sneak peek at the Chronotron development process.

The Inputs

Requirements come in a variety of forms, my own usage being still one of the key drivers. I open Chronotron almost daily to play videos, sometimes just for the pleasure of watching Joe Satriani play note by note, or seeing Eric Clapton become left-handed.

It goes without saying that user feedback is the main input for the app regular maintenance cycle. I often add features based on suggestions that you submit either through the app Contact menu, the online form at chronotron.com or Store reviews. There’s also a good deal of inspiration coming from friends who are frequent DAW users, like when choosing the balance control pan law.

One source that deserves special attention is the app telemetry data in the Microsoft Store because it can reveal issues related to a specific app release or OS updates, like it already happened in Release 98.

And that’s about it when it comes to requirements.

Then What?

All these ideas end up in a really, really, long wish list. I call it a to-do list, even though not everything in there will get eventually done.

One of my regular routines is to prioritize the items in the list in a cost/benefit balancing act. The items at the top of the list are the ones shortlisted for the next Chronotron release. User interface (UI, for short) features are easier to implement than DSP algorithms and are more visible to users right away. This is why UI enhancements and bugfixes tend to happen more frequently than anything else.

Once I know which features and fixes will actually make it into the app, the next step is to annotate the parts of the source code relevant to the changes, converting feature-to-do’s into code-to-write’s as I go. This step is crucial to my own sanity. Because a feature may take days or weeks to get implemented, a few hours or even minutes at a time, I couldn’t do it without keeping track of where I am so I can pick up where I left.

I coined the term time-lapsed software development to name this approach. You may have heard that agile software development is done in sprints. In comparison, Chronotron development feels like hurdling.

Another regular task is to reorganize the code to make sure that new features can be added without too much hassle. In technical jargon this is called refactoring. This task is also time-lapsed and guided by code annotations, just like regular app features and fixes (in fact, sometimes you see Chronotron releases with no new features at all, but only “under the hood” changes).

And when the code is written, it needs to be tested.

Testing

A widespread view is that developers aren’t great testers, especially when testing their own code. Indeed, the me-developer isn’t a great tester; however, being a one-man shop, I have no choice but trying my best.

The me-user looks at the app with a critical eye: Is it good enough for my workflow? What would I say if I had to write a user review? Does it perform well on my hardware? My testing routine involves going through most of the Chronotron functions on a couple of devices, including a Windows on ARM one.

That being said, software used to be well tested at a time when you couldn’t afford to ship new floppy disks to your clients every week. In the post-software-stability world we live in, the end users are the testers. Software – even complex systems like Windows – is rushed to the masses and then fixed on the go.

Store apps are software as a service, just like Windows 10. Updates are pushed to you whenever the developer feels like implementing new features and fixing bugs. This is great in many ways, but the inconvenient truth is that the typical Windows 10 configuration has way too many moving parts to be dependable. App updates – or even updates to the tools used to build the apps – can render them unusable. Windows updates can break apps, too, and there’s no easy way for the average Joe to roll back. In short, users at the mercy of the developers and the world is upside down.

As a customer I don’t like that, but I perfectly understand why it happens. Permanent Internet connectivity is widespread and users want features ASAP. Testing is expensive. Mechanisms such as staggered releases exist, but they are there as a mitigation rather to address the actual problem.

Is Chronotron any different? You tell me. I guess the truth is somewhere in the middle.

And when an app is tested successfully – whatever that means –, it gets deployed to the Store.

The Output

You would think that releasing the app to the Store is the easiest part, but it’s not.

The first step is to mark a new app version in the code base so I can track down the changes introduced at each release. For example, if a customer asked why a feature worked in version X but no longer in version Y, that’s how I could find out.

The second step is to create an app package to be submitted to the Store, plus all other required material for the certification process, like updating the app description if features were added, taking new screenshots if the new version looks different, and so on.

When Chronotron is submitted to the Store, Microsoft reviews all the material provided and certifies the app for publication. This process usually takes a couple of days.

While waiting for the certification process to complete, I write and publish the app release notes and occasionally author a blog post to celebrate the new release.

And that’s all!

Now that you know how it all works, what are your thoughts on app development? Let me know by leaving a comment below.