This is not really about Selena's email but it's so nerdy I still want to
talk about what tech debt is and what it isn't.

The word tech debt at the beginning meant a very specific thing: When an
engineer takes a shortcut to deliver a feature faster. Daniel has a pretty
good essay on tech debt:

But the term slowly became so overused that engineers used it to refer to
any invisible work they couldn't tie into a feature. At this point, people
refer to tech debt as the general maintenance practically. And that led to
non-tech people to slowly disregard maintenance work because everything is
tech debt now.

What tech debt is not (this is not a MECE list):

   - Keep the lights on: OS upgrades, security updates, hw maintenance,
   incidents, ...
   - Bitrot: The code stays the same but the underlying technology changes,
   the usage pattern changes, requirements changes, etc.
   - Over-engineering: This is way more common than you think. Building an
   overly complex palace that no one can maintain anymore because no one
   understands it and everyone is afraid to remove anything. This is sorta the
   opposite of tech debt, people spent more resources than they should and
   it's still hurting us.
   - Plain bad engineering: People make mistakes, typos are easily fixable
   while architectural mistakes are not, sometimes we know it because of
   hindsight, sometimes it was obvious from the beginning.
   - Limiting architecture: Many architectural decisions come in the form
   of trade-offs, a classic example is performance vs. security. If someone
   wants something and it's not possible due to architectural limitations, it
   doesn't necessarily mean a bad thing. We sacrificed something in favor of
   the other.
   - Code hygiene: Improvements on readability and maintainability of the
   - Scale/Performance/Security considerations: I have seen that people see
   a prototype and want it in Wikipedia right now. I understand it but any
   solution on such a large scale comes with all sorts of edge cases and
   hidden costs. People bash MediaWiki for being too complex and messy but
   anything you build at the scale of Wikipedia is going to be complex and
   messy. If a solution takes years, sometimes that's the only option.

What I want to say is that while we do have a tech debt problem in
Wikimedia, we also have a lot of bitrot problems too, or any other "slowing
down development" kind of problem. Some cases it's fixable, in some cases
it is not. What is needed is more resources on maintenance which is
happening and is making me extremely happy. Whether we call that paying
back tech debt or not.

Am Fr., 14. Apr. 2023 um 23:44 Uhr schrieb Brian Wolff <>:

> Perhaps i am hyperfocused on technical debt in the sense of improving the
> abstractions used in mediawiki. The phrasing around sustainability
> especially leads me in that direction. However, technical debt is certainly
> a broad concept and can mean a lot of things.
> The common thread in the examples you cited seem to be things that have
> fallen through the ownership cracks. I'm not sure its the case that
> engineers aren't incentivized to fix these, so much as there are no natural
> engineers to be incentivized due to team structure (scribunto is an
> exception but i would disagree with that task's inclusion for reasons that
> get off topic). On the other hand, perhaps a different incentivization
> structure would encourage people to branch out more.
> I think it is especially telling that 3 (or 4 even) of these tasks are
> multimedia related, given that wmf hasn't had a multimedia team in a very
> long time [SDC does not count], and definitely not one focused on the
> backend. There are quite a few multimedia related areas in desperate need
> of love (it is 2023 and video uploads are limited to 4gb with the flakiest
> upload process known to man).
> It was also pointed out to me on irc, that many critical workflows in the
> community depend on toolforge tools that have very limited volunteer
> maintainership. A sort of situation. Just because
> they're not "production" we often pretend they don't exist. Regardless of
> how we label them, in the end it doesn't make a difference to the end user,
> and the fragility of that ecosystem is a form of technical debt that is
> often overlooked.
> So i guess it all depends on what is meant by "technical debt"
> --
> Brian
> On Friday, April 14, 2023, Andre Klapper <> wrote:
>> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
>> > > "I think there are lots of promising opportunities to incentivise
>> > > people to pay off technical debt and make our existing stack more
>> > > sustainable. Right now there are no incentives for engineers in
>> > > this regard."
>> >
>> > Interesting. Personally to me, it can sometimes feel like we never
>> > stop talking about technical debt. While I think paying off technical
>> > debt is important, at times I feel like we've swung in the opposite
>> > direction where we are essentially rewriting things for the sake of
>> > rewriting things.
>> "Technical debt" spontaneously brings the following items to my little
>> mind. They should not be about rewriting but rather "maintenance":
>>  * librsvg for SVG rendering is a five year old version:
>> /
>>  * Graph extension on old Vega version 2.6.3: see subtasks of
>>  * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
>>    in 2012):
>>  * 3D extension on a five year old three.js library in
>>  * Removing the OpenStackManager extension from
>>  * Removing WVUI from MediaWiki
>>    core:
>>  * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
>>  * Undeploy VipsScaler from Wikimedia wikis:
>>  * (a non-public task)
>> This is not a complete list. Plus there are also separate "waiting for
>> someone to make a decision" and "improving communicating & documenting
>> already-made decisions" categories which would be different lists.
>> Of course there might be valid reasons not to look into some of this
>> technical debt (other higher priorities, high risk, complexity, etc).
>> Cheers,
>> andre
>> --
>> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
>> _______________________________________________
>> Wikitech-l mailing list --
>> To unsubscribe send an email to
> _______________________________________________
> Wikitech-l mailing list --
> To unsubscribe send an email to

Amir (he/him)
Wikimedia-l mailing list --, guidelines at: and
Public archives at
To unsubscribe send an email to

Reply via email to