Microsoft at the moment is holding their annual Ignite Conference for enterprise customers but one of the most under-reported announce is the decision by Microsoft to go back to OneNote ‘Classic’ rather than develop OneNote ‘Modern’ further (I’m speculating that they’re replacing the ‘Modern’ version it rather than developing the ‘Classic’ and ‘Modern’ in parallel given that I couldn’t see then maintaining both of them if the end result is the return of OneNote ‘Classic’). It has been an on going project by Microsoft to gradually replace OneNote ‘Classic’ with OneNote ‘Modern’ for the last 7 years and even with all the time and effort they keep slipping further behind not to mention widespread criticism that the ‘Modern’ version just isn’t up to standard. With Ignite they’ve formally announced that they’ve bought back OneNote ‘Classic’ but no word yet on what will happen to OneNote ‘Modern’. (link) (link) (link)

It’s important because, as I noted in a tweet earlier today where I alluded to Joel on Software (an ex-Microsoft employee who talks about subjects pertaining to software development – everything from code to managing a team), it appears that Microsoft have realised that throwing out working code and starting from scratch might sound appealing until you have to deal with the reality of writing new code and then spending time having to debug it. It is the precarious balance between legacy code being well tested code vs. legacy going being an impediment to future development. Joel wrote a multipart serious address that issue (link) and touches on companies who threw out old code for the sake of ‘starting with something new’ and what the consequences of that was – Mozilla and Borland Paradox (he names some others). The benefit of when others mistakes is the ability for you to learn from them and not to repeat it – something that Microsoft should have remembered but now we’re here one has to deal with the situation as it exists not how we’d like it to exist.

The other consideration is the work being done with WinUI 3.x and the ability to ‘mix and mingle’ win32 and WinUI 3.x elements so it is possible to gradually move a large project like OneNote forward in a careful and considered way without having to re-write from the ground up. That was one of the biggest mistakes with OneNote ‘Modern’ – in the desire to want to use it as a show piece for the future of Windows the end result was something that never really got to feature parity with the old win32 application. That being said, it was a mistake that was learned from and I’m sure that we’ll eventually start seeing parts of the UWP application being merged where possible, new components written using WinUI 3.x (once mature) and gradually do a piece by piece migration.

Reminds me of very much the same approach that DXC.technology is taking when migrating its customers off the legacy Hogan system to their new Celeriti platform. The ability to complete a project in a piece meal way ensures that if there are issues it can be contained and rectified when compared to ‘rip out and replace’ where there are so many variables that you end up like what happened with many of the high profile projects – Kiwibank and it’s ill-fated ‘rip and replace’ of Ultracs with a SAP based system being the most recent example.