Every experienced developer will eventually tell you the same thing – that the really hard task is not to develop some random piece of software, but to develop it in a way that it is long-lasting, extendable and still maintainable over several years. That it is stable yet easy to change. That is stays “soft”, as one wise developer once told me.
With CDVDBurn 3, there were some special additional challenges along the way. The codebase started its existence in 1996, nearly 25 years ago. It was a somewhat rushed port from a lump of BBC BASIC (the original CDBurn prototype) into a procedurally structured piece of Ada 95 code. The “toolkit” for the WIMP stuff is a very simple thin binding with procedures and functions barely above SWI level.
While I am still happy that I chose Ada to develop CDBurn and now CDVDBurn 3, it poses additional challenges. The compiler – based on GCC 2.7.2.1 – is firmly in the 26bit camp and is one of those applcations that are not entirely happy running under Aemulor. And the code it produces has some restictions – you can only use very basic Ada features if you want the code to run on ARMv5 (IYONIX), ARMv7 (Cortex-A7/8/9/15) or even ARMv8 (e.g. Cortex-A72). Forget representation clauses. Forget tagged types. Forget significant parts of the runtime.
So restarting development of some codebase that is nearing its 25th birthday and that hasn’t been touched seriously in more than 10 years poses various challenges. Simple ones like “where am I going to compile this” (I moved from the Risc PC to Virtual-RPC and now to RPCEmu for all 26bit computing a long time ago, and the Ada development environment was still intact). Harder ones like “which is the latest sources that I built those three betas in 2017 from when S-ATA support for Titanium was added”. Decisions like “should the way the sources go into VCS be changed”. Or “should I start refactoring significant parts of the code, or only those parts that I am likely to change”. And of course working out how to test that code in an efficient manner on many platforms in parallel – if your average test (“write that DVD”) takes 15 minutes, you better had a few machines and drives available along with a good idea how to collect the test results.
The good news is that I still know my way around inside the code, although memory gets a bit light on the details. Amusingly, mostly on details I changed later on, while the initial details from 1996/1997 are still remembered well. So most of the time I am reading old code instead of writing new code, but that’s the nature of software development if you are in the “product” business.
The most difficult part is to remember and strictly follow the “minimum viable product” principle. Every developer likes to start new stuff, coding cool new features. But the most important thing for CDVDBurn 3 is currently to “finish”. Round the rough edges. Make more drives work. Finish previously half-baked features, or make them temporarily inaccessible if they are not ready for prime time yet.