User:Novem Linguae/Essays/Rewriting PageTriage is a bad idea

Definitions

A software rewrite means throwing out the old code and rewriting it from scratch. This is usually a bad idea, but when done, should be done with the strangler fig pattern so that it is incremental.

A software refactor means taking existing code and slowly changing it so that it is better.

Thoughts

I hear the idea that mw:Extension:PageTriage (the software used by new page patrollers) needs a "complete rewrite" often. I think this is a bad idea. Here's why:

• Duplicated effort – We already have a bunch of the features we need. Why would we spend developer time programming these again? Why would we spend new page patroller and developer time re-discovering and re-fixing bugs? Why not just add on to the existing software?
• Project might never get finished – It's hard enough to get the WMF to assign developers to work on PageTriage. Can we trust them to take on such a big project and finish it?
• Expensive – It's hard enough to get the WMF to assign developers to work on PageTriage. Why would we x2/x3/x4 the number of dev hours needed? This makes the PageTriage project too big to be attractive. Knocking out several feature tickets is probably less hours than rewriting the extension, and delivers a tangible result.
• We don't need mobile friendly – The front end would likely be replaced with something more 2022-ish, with lots of padding/margin, big buttons, and mobile friendly. This is not what we need prioritized. Our patrollers are mainly on desktop. The existing front end is fine.
• PageTriage is compatible – There is a rumor going around that "PageTriage is incompatible with modern versions of MediaWiki". This is simply not true. PageTriage alpha is 100% compatible with MediaWiki core alpha. No features are disabled due to some kind of time drift between coding styles, APIs, etc.
• The technical debt is fixable – Sure there is technical debt (old code that needs updating to a more modern style). But this is not a compelling enough reason to rewrite the extension from scratch. It is reason to slowly update the code.
• Very risky – Rewrites from scratch are a well-known anti-pattern in the software industry. See, for example, Things You Should Never Do, Part 1. Or Lessons from 6 software rewrite stories. Or the book Modernizing Legacy Applications in PHP, pages 5–7.

My list of phab tickets to prioritize is located at the PageTriage kanban board. Priority technical debt has its own column. These can be knocked out without rewriting the entire extension.

Discussion welcome on the talk page.

If you're a dev and you see some things that stink about the PageTriage code, please let us know in this Phab ticket about PageTriage's technical debt.

What did we end up doing?

The top part of this essay was written in October 2022. It is now January 2024, and we can now look back on what happened with the benefit of hindsight.

On the back end (PHP), we ended up keeping things mostly the same. Some of the changes include Novem moving some maintenance code from files to classes, Susana adding some integration tests, and Kosta breaking up a big class into smaller classes using the Record/Lookup/Manager pattern.

On the front end (JavaScript), we ended up doing a very heavy refactor. DannyS712 and Jason ended up converting Special:NewPagesFeed from Backbone.js/Underscore.js/JQuery UI to Vue.js. This was a lot of work, but not quite a rewrite from scratch – code was copy/pasted and then modified to work with the new framework. Sohom later converted this to Codex.

Susana is now working on using the strangler fig pattern to incrementally replace each flyout menu in the Page Curation toolbar with Vue.js, one flyout menu at a time. Volunteers may take over this task as we get more comfortable with Vue.js.